Makoto

It would depend how they were specifically written in ATP. If you'd like, I can have them manually converted to Basic Formatting by writing a regex filter for the tags and processing them for you that way. There would just be a one-time $60 fee for this service, as it's technically custom work. You can edit everything but the tag name itself. I can see about changing this behavior in the next release so you can change the tag name as well, it's just not something that's often needed.

Hey @AlexJ, Sorry I missed your questions! When migrating from ATP to Radical Tags, those converted tags are registered as advanced prefixes, as the "basic prefixes" option is something only introduced in Radical Tags. In ATP, all customizations are done using manual HTML, so they have to be ported over that way. If your prefixes just use basic color coding however, you can certainly convert them over to basic prefixes. You'll just need to delete and re-create the old ones in this case using the basic editor. You won't lose any formatting on older tags or anything when doing this, so no need to worry about anything like that. Regarding the tag/prefix not being an editable field, this is by design currently. If you want to create a prefix for another tag, you just need to create a new one instead of editing existing entries. Let me know if there's anything else I can do to help!

Currently, there is only an option to require prefixes, not tags. Are you needing to require users specify tags in general in specific forums? This is a feature I can look into adding! Sorry for trouble! It looks like IPS only retains the last 5 versions uploaded to the marketplace, so that IPS 4.4 release has fallen off the list. I'll send you a PM here shortly with a copy of the IPS 4.4 compatible build.

Hi @hjmaier, I'm afraid I can't reproduce this issue locally, so I'll need you to provide me with temporary AdminCP access on your forum in order to further diagnose this issue. Can you please send me a PM here to continue troubleshooting?

Generally, the recommendation would be to enable innodb_large_prefix in the MySQL server configuration, but if you're not able to do that you'll have to adjust the index sizes to accommodate. The problem is there are going to be several indexes that need updating, so doing them one by one would take a very long time. I believe I had a script that automated this once before but I'll have to try and dig it up again.

Hi @jfmakis, I'd be happy to help you out! You can find my providers profile here:

Never.

That's great for you, but to quote your own words, what works for you doesn't necessarily work for others. It doesn't matter what works for you. If this ever got an official implementation, this is the way it would work without any debate. Period. Sure, in that case just adding webp as a supported image format for manual upload would be all you need/want? Then you can manually compress and upload images however you want. That's fine. I support that. You're welcome.

No, but where in IPS exactly are you utilizing this? This is a very rare scenario, and there's nothing in IPS that produces dynamic images like this, so you must be using a third-party application for this, right? Which means it would be more the responsibility of the third-party application developer to implement WebP support anyways. You would have to store both the 10mb PNG and the 5mb webp file, so you're increasing your image storage consumption by 50% or more in this case, give or take depending how well your images are optimized on average. WebP is not supported on most Safari versions still. It has only recently gotten support. Many iOS users and so on still lack proper WebP support. You can't just not store/serve original PNG's/JPEG's. It's also still required to store original images when using the gallery application and so on, as Windows and so on have no native support for displaying WebP images. Users need to be able to download the original files for offline storage. Yes? That's exactly what Cloudflare does, it intelligently compresses images, better than IPS probably could. This is literally what they do. Optimization is their entire schtick. I'm aware this is IPS and not CloudFlare, but I'm merely offering a pragmatic view here in that there's not really a benefit in integrating this into core applications when better solutions that most of the internet already take advantage of exist. The number of users that explicitly don't want to take advantage of these solutions is comparatively small, and thus implementing this is not going to be a high priority for IPS.

Such as? Can you link me some examples? CloudFlare won't convert images to WebP if the filesize would be larger or there would otherwise be no benefit gained. You can check the reason an image hasn't been "polished" or converted by reading the headers CloudFlare sends with the request. I've never seen any issues using it myself. What do you mean by "optimize the compression" as well? You can configure the quality level for lossy compression, but otherwise there's nothing you can or need to really "optimize". My stance remains that CDN's are still a significantly better solution. No increased storage or processing requirements on your end, you take advantage of faster CDN networks when serving images, and these services take care of ensuring users are always served the correct supported file format. There's really not much of a good reason to not be using services like this in 2020.

You should be able to do this in the latest release! Do you not see the options present? You can technically do this using the advanced tag editor by just leaving the HTML empty, or adding style="display:none;" to the tags HTML element. But this is an interesting idea, I'll see about implementing it officially to the standard customization wizard as well!

Do you know what your server load average is during peak hours? What kind of server is this (what processor/how many cores or threads does it have)? Is your site feeling slow at all, or are you just worried because of the warning e-mails? It could be normal and a non-issue depending on how these alerts are configured. Aa long as your server load isn't exceeding your hardware specifications and site performance is good I wouldn't worry. Additionally, make sure you have opcache installed and enabled on PHP 7.4.

I'd again reiterate that it's not necessarily true. If someone only had experience using Windows, I'd not suggest they use Windows server just because they're familiar with it In this case, if you're familiar and comfortable with CentOS, it's a good choice as CentOS is a valid option. There are right and wrong tools for the job, it's not just about what you have experience with. My advice here was perfectly valid in that regard so don't try and dismiss it by saying this is the "only correct answer" 😉

That's true, excluding distros like Gentoo and Arch Linux 😉 Even as someone who used Arch Linux as a desktop OS for many years and is intimately familiar with it, I would not use it on a server system where uptime is of any importance, as I know bleeding edge updates, no matter how comfortable you may be with them, can introduce radical breaking changes that result in downtime. So, it's a mix of using what you're comfortable with and what is the best tool for the job. Debian, CentOS, RHEL are all examples of the right tools to use for server systems. CentOS is more often used in enterprise environments where stability is more important than having access to the latest software. Debian provides what I personally consider the best mix of being stable while still being reasonably up-to-date. One thing to note is that CentOS doesn't really have a good upgrade path for their release cycles, and the general suggestion is to just make a fresh installation if you want to upgrade. Debian on the other hand provides an easy straightforward upgrade path so you can keep up-to-date with each new release cycle. That's not saying it's impossible to upgrade CentOS, it's just generally done using unofficial/not well supported means. This is fine again if your main focus is stability and you don't mind running software that is a bit older for the sake of stability over any potential improvements newer software releases may have (barring any security issues, as security patches are backported on both Debian and CentOS). Both CentOS and Debian do support third-party repos which let you take advantage of more modern software releases, however. But you have to be careful not to go too overboard relying on these. --- tl;dr if you're comfortable and happy with CentOS, it's probably best to stick with it on your next server. If you want to try something new that has a shorter release cycle, Debian is also a very solid choice. Outside of these two, I wouldn't really recommend anything else. RHEL is generally only used in enterprise environments for their support. Ubuntu Server is.. okay I guess, but I rarely ever see it being used outside of temporary docker images and such.

My application linked above by @Paul E. does indeed handle this. In addition to being able to block registrations from disposable e-mail addresses, it supports detecting e-mail aliases from GSuite / GMail using the dot (foobar@gmail.com / foo.bar@gmail.com) syntax, as well as the plus alias syntax (foo@gmail.com / foo+bar@gmail.com). I foresaw this being a potential for abuse long ago and implemented these measures to protect against them before it became commonplace 😉

It mostly comes down to personal preference and how much you prioritize running up-to-date software over a potential increase in long-term stability The big two are CentOS and Debian. Personally, I use Debian as I find it to be a better balance between being modern enough while also being very stable and easy to work with. CentOS' release cycle is much slower, so much so that I've had to deal with software incompatibilities trying to manually compile things on said server systems. But if you don't mind using very old software packages, it's a decent choice. Gentoo / ArchLinux are not ideal for production server systems. These are bleeding edge distros where things can break at a moment's notice. They're more suited for desktop use by people who are very familiar with Linux and/or want to learn. But due to their bleeding edge nature, they are not stable.

You should be presented with an option to migrate tags over once you install Radical Tags if it detects Advanced Tags and Prefixes is present. I'm happy to help you with the migration process if you need it, just send me a message here!

Set the TTL on your domains A record to ~5 minutes now and give it 48-72 hours to propagate that change to clients before you migrate. This will help minimize the amount of time it takes for your users to see the change once you flip the switch over to the new server.

No, you shouldn't change that for now, I just wanted to confirm you were indeed having mail sent from your local server. This is unfortunately why your messages are likely being delivered to spam. Local mail servers are generally seen as a high potential for abuse even with a clean IP reputation, DKIM, SPF records and the whole shebang. That's why it's generally worth investing in a good mail solution like Amazon SES or GSuite nowadays. The process in getting these configured is a bit involved though. I don't know for sure if there are any limits placed on your grandfathered GSuite account or not, but in general I recommend having a separate GSuite account (it can be on the same administrative domain) used for delivering site related e-mail, so this would run you an extra $6/mo if you wanted to configure it. The reason I recommend this is otherwise you're going to get all those bounced e-mail messages and people accidentally replying to your site notifications to your main inbox, which you definitely don't want.

Are you only using this domain to receive e-mail via GSuite, or do you have IPS configured to deliver mail via GSuite Gmail through their SMTP relay? If you're delivering mail via Google, this would be your e-mail delivery configuration, If you're using the PHP mail method, you're not delivering mail via Google, and instead delivering it through your local server.

This sounds like it may be an IPS configuration issue then. When you login to your AdminCP, look for Email Settings Verify that your Outgoing email address is set to the correct address/domain.

It honestly might not matter whether your IP is on any blacklists or not. If you're delivering mail from your bare metal server, it's likely going to end up in spam. So your server guy may not be lying when he says there's nothing wrong with your server IP's reputation, but he is lying by blaming it on IPS. It has little to nothing to do with the software, unless the software itself is sending e-mail that is spammy, which IPS does not do. There are things you can do to try and help mitigate it, but it's unfortunately just the way it is. Setting up things like DKIM and SPF records help make your mailing domain more trustworthy. If your server admin doesn't recognize the challenges and issues that are pressed when trying to deliver mail from a self-hosted server, my personal opinion is he doesn't sound very competent. The best mailing solution I've personally found is integrating GSuite into IPS, which sadly isn't very straightforward to do. But it's literally delivering e-mail with Google. Considering the vast majority of people use GMail, and Google isn't likely to consider messages from other Google users to be spam, it naturally works out as a good solution. There are some caveats, but they're generally not relevant unless you're needing to send more than 10,000 messages per day. I don't know who your server admin is, how much your paying him, or so on, but I'd have to agree with Paul E. that it sounds like he has no vested interest in you. I'm on retainer for a few clients as both a system admin and programmer but I would never treat my clients this way.

Thank you very much for the kind words, I really appreciate it!

Hey @livegames.co.il! You can, sure! You'll just need to use the advanced editor and add in some custom HTML code to embed the image yourself, but I do utilize image icons myself on one of my communities and can provide an example HTML snippet you can use for this if needed! You do not have to renew to continue using the application, only for updates and continued support. If you do not renew after 6 months, the current version you have will still continue to function as normal.

Did you just recently migrate from ATP to Radical Tags? You may have some NULL / empty tag entries in your database if so. If you can send me a DM and set me up with ACP access I can take a look and get it resolved for you. You should also be able to click on prefixes to go to the tag search page without issue, if this is not working I'd try running the support tool first and see if this clears up any issues.