Support

There is no video file.

Generally speaking, please do not use videos to communicate your issue unless explicitly instructed to do so.

Please do use words to describe what is going on. If necessary, also provide a screenshot. These help us help you a sight more than a no-context video.

There is nothing in Admin Tools's Web Application Firewall or .htaccess Maker which would block JCE's "Insert image" button.

Moreover, the message you are receiving comes from Joomla itself, not Admin Tools. It's the standard "access denied" message it displays when the anti-CSRF token in a request is invalid. JCE does, indeed, pass the anti-CSRF token in the request it makes to fetch the popup's content, which is a URL like this:

https://www.example.com/index.php?option=com_jce&task=plugin.display&plugin=imagepro&60a0856990a67b73ce1be1b544e2bc60=1&context=363&profile_id=1

The bold and underlined part is Joomla's anti-CSRF token.

I suspect that your problem may have to do with caching. Disable Joomla's caching in Global Configuration, and disable the "System - Page Cache" plugin as well. If you are behind a CDN such as CloudFlare make sure to add an exception for all URLs which contain option=com_jce& in them to prevent it caching the wrong editor content (including error results).

You're welcome!

If you want to be 100% sure it's not anything I may have missed, and even though I did try reproducing your exact issue on two different sites of mine, you can try two more things.

First, you can try disabling the System - Admin Tools plugin (first, go to Admin Tools' Configure WAF and set Defend against plugin deactivation to No). If the problem is reproducible, Admin Tools' Web Application Firewall had no effect on it.

The other thing to try is to replace the contents of your .htaccess file with those of the htaccess.txt file shipped with Joomla. If the problem is still reproducible it's not a .htaccess issue either.

If you have done these and already know it's neither caching not a CDN the only thing that's left is server configuration, or a third party plugin doing something weird.

Thank you very much for your kind words! They really do mean a lot and made my day :) I do, indeed, love helping people. That's why I became a Free and Open Source Software developer. The hours suck, the pay sucks, but I get to help people without some legal cover-your-butt corporate policy getting in my way.

To disable the System - Admin Tools plugin we first need to turn off its self-defense mechanism. Go to Components, Admin Tools, Web Application Firewall, Configure WAF, and set "Defend against plugin deactivation" to No. Then, click on Save in the toolbar. You can now disable the plugin just fine. Please let me know if you can reproduce the same issue with the plugin disabled.

Also, are you using Joomla's Multi-factor Authentication for your user account?

That field is in the Auto-ban tab.

In the Auto-Ban tab scroll a bit further down than what you showed on your screenshot.

Set Add persistent offenders to the IP Disallow List to Yes

You will now see the Permanently disallow IP after this many automatic blocks field. Enter the value 3

Now set Add persistent offenders to the IP Disallow List to No

Click on Save

It should now save just fine and you can go back to change "Defend against plugin deactivation" to No

Correct, this is unrelated to Admin Tools. As I expected, this problem is related to the user session.

Something, somehow, is caching edit links with an old, expired anti-CSRF token. It's either some third party plugin, or something on your server. I can't know what, though.

I already told you, you already checked the standard Joomla caching, so that's a dead end. Is it possible that you are using a third party plugin (e.g. LSCache for Joomla), or a feature on your host to enable caching?

I have not heard of any such problems with either of those extensions, but do keep in mind that front-end editing is not very common practice either. Which is to say I cannot tell you that they have or have not anything to do with the problem.

Whenever I had a similar problem, it was either a misconfiguration of the session storage in Global Configuration, or some kind of caching I had forgotten about.

Beyond that, I start by making a copy of the site with Akeeba Backup on a different subdomain, or a different server, and see if the problem can be reproduced. If so, I will then start disabling plugins to see if it makes a difference. Walking things back usually helps isolate first the software, then the setting that was causing the problem. 

Can you please open a new, private ticket, and send me a share URL on Dropbox, OneDrive, or Google Drive where you have uploaded a copy of your site? Since it's reproducible on different servers I should be able to reproduce it as well. If I can reproduce it in a controlled environment, I should hopefully be able to at least figure out where it's coming from.

Your problem is that you have set your Home menu item's access to Guest.

This is wrong. It essentially tells Joomla! that only a non-logged in user (Guest) can access the homepage of your site. Considering that this menu item is used whenever a URL without an Itemid is used, like the ones used by JCE to open its various modals, it makes perfect sense that you get a Joomla! access control error.

The solution is simple:

• Log into your site's administrator
• Expand the Menus item
• Click on All Menu Items
• Find the Home menu item and click on it
• Change its Access to Public
• Click on Save & Close

I recommend that you do the same to all menu items currently set to have an access of Guest, as these are menu items you want everyone to access, regardless of whether they are logged in or not.

Remember the difference between Guest and Public:

• Guest is visible only if the user is not logged in. Non-logged in users can see it. Logged in users can NOT see it.
• Public is visible to everyone, regardless of whether they are logged in. Non-logged in users can see it. Logged in users can see it.

Thank you so much for your kind words! I love helping people. If I didn't, I wouldn't have become a Free and Open Source Software developer ;) 

This issue was really no bother at all. It only took me maybe 2 minutes to figure out what the problem is, once I could see your site's backend. I turned debug mode on. I saw the access error comes from Joomla's main application. I looked up the code referenced in the error message; it checks if you have access to the menu item (Itemid). I checked the URL produced by JCE. No Itemid, therefore it uses the Home menu item. I checked the Home menu item. I saw it was Guest access. I put two and two together. Compared to what we usually deal with that was kindergarten level.

Panopticon doesn't have a Pro version, and I am not sure I want us to have one. It's already tied into Admin Tools and Akeeba Backup for security and backups which means that people will be paying us for these features -- if they need them -- anyway. Besides, the global economy is pretty rough, possibly worse than it's been in 2008-2010. I'd rather just charge people enough for me to make a living and help everyone survive, rather than try to make a killing at the expense of everyone else's survival. One is a symbiotic relationship between software developers and site integrators, the other is parasitic. You know where I stand on that :)

Thank you for your kind words :)

Open Source CMS like Joomla! and WordPress don't have more security issues, they are just open about them. Software as a service (SaaS) vendors just patch things quietly; they don't tell you they had a security issue unless they have a security incident, i.e. information gets stolen off their servers.

The perception of "more security issues" is skewed by the fact that a substantial number of people -- about one in five -- use very old versions of the Free and Open Source CMS, they get hacked, and then they idiotically blame the CMS... which had patched the security issue five years ago, but these folks couldn't be arsed to install.

The other compounding factor is third party software. On a SaaS platform there is a very hard delineation of the architectural border between first party and third party code. If a third party add-on cocks up, users are unlikely to blame the SaaS. On an open CMS like Joomla or WordPress the third party code is much more integrated and, as a result, the border between first and third party code becomes blurry, if not outright disappears, in the eyes of the user. Thus, when a badly written third party software cocks up, the open CMS user will blame the open CMS itself, even though it has nothing to do with their plight. On that note, yes, WordPress is "far less secure" than Joomla inasmuch it has a far higher proportion of third party plugins which are a security nightmare than Joomla does. When comparing the core CMS itself, both Joomla! and WordPress are on equal, solid footing when it comes to security, which is surprising considering how much more you can do with just the core in Joomla! compared to WordPress.

On another note, about automatic updates. WordPress sells itself as infinitely backwards compatible. Sure, it's utter hogwash, and it does introduce breaking changes in minor releases without announcing them. It's just that a majority of its users are brainwashed zealots, therefore any backwards incompatible change causing problems upon unsuspecting plugins is blamed on the plugins, not the bad management of code and the lack of communication from the core WordPress folks. Therefore, WordPress can offer automatic updates without worrying about its public image; having an army of zealots willing to besmirch, disparage, and outright slander any rational voices is a great marketing tool, if not at the very least giving a malodourous whiff of a dystopian nightmare.

Joomla!, on the other hand, stands on the the opposite shore of the public perception river. It is known that minor releases (e.g. 3.6 to 3.7) introduce backwards incompatibilities which are attempted to be mitigated, but given the breadth and depth of third party software it may not always be possible. As a result, minor breakage is expected upon a minor upgrade. Major upgrades used to be big (e.g. 1.0 to 1.5, 1.5 to 2.5) or small (e.g. 2.5 to 3.x, 3.10 to 4.0) migrations. It was only with Joomla! 5.0 that a major upgrade was not at all different to a minor upgrade... as long as you are using extensions by people like us, who do read the deprecation information in the impossible-to-find Joomla! documentation, and work around them in advance of a new release. And that's exactly why Joomla! won't attempt (yet?) any automatic update.

Speaking of which, you will notice that the default setting in Panopticon is to only install minor (e.g. 5.0.x to 5.1.0) and patch (e.g. 4.4.3 to 4.4.4) version updates, trying to hit a balance between never giving you trouble (that would be patch updates only) and virtually guaranteeing you will run into trouble (that would be if we included major updates). You can of course change that globally, or per site, depending on exactly how your site operates. For instance, I can definitely have my blog install major updates as I am proactively ensuring that only software guaranteed to run in the new major version is enabled on it. On our business site, though, we do use third party software which only recently added robust Joomla! 5 support, which is why I have set it to minor and patch updates only.

Another thing to be said about automatic updates in WordPress is that they are not a great feature to begin with. WordPress uses web-based pseudo-CRON by default, and tries to download the new version, extract it, and run any post-update code all in one page load. This works in about 9 out of 10 generic servers. The other ten percent will fail for various reasons including PHP or web server timeouts, firewall settings, memory limits, the OS killing processes etc. That's why you get "WordPress-optimised" servers which cost extra; they are beefed up and under-utilised to ensure that these failure conditions won't happen. They are also almost always an absolute overkill to the specs you need to actually just serve the site. It's a lot like buying a Ford F-150 when 99% of your use case is commuting for 5 miles each way every day, and 1% is hauling some heavy cargo cross-province. Joomla's approach to updates is what I'm doing with restoring backups (no surprise; I wrote the original Joomla! Update component): each small bit of the update takes place on its own page load. This makes automating the process without an external mechanism to trigger it impossible, but it also makes it far more reliable on that lower ten percent of hosting. If Joomla! Update fails, your server is basically a potato and you need to reconsider your life choices. Panopticon being an external trigger (using CRON jobs to provide a reliable, continuous external trigger to automation tasks) can perform the update without a problem, which is why it supports automatic updates.

You can't really check an extension for compatibility. The only thing you can do is check what the extension claims. However, because of issues in how Joomla Update works, developers like me end up saying that our extensions support Joomla! 4.0 to 4.9999, 5.0 to 5.9999, and 6.0 to 6.9999 to allow for upgrades between major Joomla! versions without Joomla! idiotically slandering our software as "incompatible". Therefore, any compatibility check is useless.

Joomla! 4.4 and 5.1 (and even 5.0!) are 100% compatible with PHP 8.3 before PHP 8.3 was released. That's what I have been daily driving for development since last September, and used as a test target since last June. This year we'll be doing that with PHP 8.4. Do note, however, that you must set Error Reporting to None. There are deprecation notices. There is no PHP codebase in use right now which doesn't have them, and that's normal. PHP is evolving, and the deprecation notices start at least a year before they become  warnings, which is itself a year before we get obsolescence error messages.

As for MySQL 8.0... Do people REALLY have a problem with a database server version which was released six years ago in 2018?!