WordPress 6.5, a bug in plugin Kadence Importer, defunct FooGallery pages – and some lessons for WP error finding

My wife still administrates Web-sites for customers. Some of them are based on WordPress. After an upgrade to WP6.5 some pages of a customer web-site went down in the middle of last week.

In addition previewing of authors on these specific pages did not work any longer.

A standard WP error message regarding a critical error of the few affected pages and messages from Browser developer tools that the pages were found to be in “Quirks mode” were not really helpful. Especially as the header of the pages in question consistently were correct!

The common property of all these pages was:

They included relatively large FooGalleries with image numbers beyond 35.

As the customer had to participate in a fair pretty soon and wanted to prepare even more pages with large Foogalleries, he and my wife got into a time pressure situation. Both asked me for help. Well, it took me some time to find the culprit. But I was stupid enough not to follow three simple reasonable rules for such cases:

  • Check for PHP errors first!
  • Systematically deactivate or even delete unnecessary plugins afterward.
  • Never perform some changes in parallel when trying to isolate faulty SW and errors.

Instead I was misguided by experimenting with the FooGalleries first.

As a first measure we performed all the steps recommended by Foogallery for problems (see this site). No effect.

Then I found that if one emptied the thumbnail cache completely the web pages with the large galleries could be loaded just once (either by a page preview or a call from a browser via a VPN). The second call crashed the page however. From this experience I focused on a caching problem first. Which obviously existed …

Afterward I had a look at a reference test site with WP version 6.0.3. There we also had some problem in the beginning.

Concentrating on potential cache handling problems we after a while thought that we had a major problem with a certain Statify method to count visitor numbers in case of caching plugins. From a time when the website owner had installed the W3TC-plugin, the settings of Statify have remained such that a Javascript based evaluation of site visits had been activated without nonce check. Meanwhile W3TC was removed due to some major problems with this plugin in WP and PHP-upgrade phases. But the Statify settings had remained the same. On our test site this appeared to have helped immediately. But I had overlooked that my wife in the meantime also had reduced the number of plugins in parallel to a minimum.

Again a substantial mistake in a process of finding errors! Never work with multiple people at different investigation fronts in parallel without a coordination of the changes in a step-wise row! And do not let pressure from customers affect you.

Correcting the Statify method for counting visitors on the main web-site did not prove to be a remedy in the long run. Some test pages which had not worked before now ran flawlessly. The stupid thing was that for other major pages a cache problem remained and after some time some pages became defunct again. But only some!

On the customer’s website the following plugins were installed: Kadence theme, Statify, FooGallery, FooBox Image Lightbox, Pinnacle Toolkit, Kadence blocks, Kadence Importer.

To make a long story short: Kadence Importer (as of present version V2.1.1) has a major PHP bug. Had I run the website in debug mode from the beginning I would have found it and saved me from hours of testing. And I am now pretty sure that the problem had existed for a longer time – undetected. So even returning to a backup before the upgrade would not have helped.

Deactivating and deleting this plugin, which is not needed on productive WP sites anyway (!), removed all problems. I cannot go into details here why this stupid plugin created caching problems. It is bad – just do not use it!

Lessons learned

  1. Do not let the customer play with WP-plugins. Mistrust any plugins which basically are made for advertisement.
  2. Strictly cling to a step-wise strategy for isolating faulty SW after upgrades. Do not let the pressure of a customer make you deviate from your planned sequence of steps.
  3. First look for PHP errors in WP debug mode.
  4. Have a test site available and compare the plugin status and settings in detail.
  5. Deactivate and remove all unnecessary plugins in a systematic manner.
  6. Keep track of special settings of WP plugins, in particular with respect to other caching plugins. And do not let the customer fiddle with such parameters undocumented.
  7. And, of course: Make a full backup of yours site before upgrades. Deactivate any automatic upgrade.

I hope this helps other WP admins.


Opensuse Leap 15.5 – YaST2 bug – no repositories can be added via YaST2

In one of the last posts I have said that upgrades of running Opensuse Leap 15.4-systems to Leap 15.5 are a smooth business. However, a major bug in the present Leap 15.5 did not appear on my radar until now.

During the upgrades of most of my systems I just continued using a system-specific bunch of active Opensuse repositories – like the “graphics” and the “security” repositories. I used the ${releasever}-mechanism during the upgrades to point zypper to the new versions of the repositories. This all went well and after the upgrade I found the 15.5-versions of those repositories, which I had used on Leap 15.4 before, integrated into the YaST2-software and package management of Leap 15.5.

But, two days ago, I installed Leap 15.5 on a laptop from an ISO-image on a DVD. Such an installation only sets up basic Leap 15.5 repositories. So, after the installation I wanted to add further repositories via YaST2’s software-management. This did not work at all. The repositories simply did not appear in the list of managed repositories afterwards.

I fiddled around for about an hour. It became clear by switching views on repos and so called “services” that the requested new repositories were handled by YaST as SW-services, instead as standard repositories. Whatever “services” are going to be good for in the future. I could find some information at
https://news.opensuse.org/ 2023/07/31/ try-out-cdn-with-opensuse-repos/.

I moved in the end to zypper on the command line to add repositories. Which worked …. A good reason to suspect a bug.

Bug: Adding repositories with YaST2 does not work presently

Indeed: The following two links showed that other Opensuse users had the same problem and that there is a related bug-entry at Opensuse’s bugzilla:
https://forums.opensuse.org/ t/ cant-add-repos/ 171641
https://bugzilla.opensuse.org/ show_bug.cgi?id=1218399

Well, YaST2 is a central tool-box for Opensuse systems. And who would deny that the package manager is one of the most important tools on any Linux system? So, old kinds of questions regarding quality assurance came to my mind: Are changes to central Leap components tested thoroughly at Opensuse? In particular as also SLES is affected …. Unbelievable …

The affected package is yas2-packager 4.5.17-150500.3.3.1.


Adding repositories directly via zypper (which is used by YaST2) still works. So, you can add add repositories like the security repository, with command analogous to the following:

mytux:~ # zypper ar -f https://download.opensuse.org/repositories/security/15.5 security
Adding repository 'security' 
Repository 'security' successfully added

URI         : https://download.opensuse.org/repositories/security/15.5
Enabled     : Yes
GPG Check   : Yes
Autorefresh : Yes
Priority    : 99 (default priority)

Repository priorities are without effect. All enabled repositories share the same priority.

These repos afterward appear in the YaST2 packet manger and are fully usable to install RPM packages.

Weird aspect of the YaST2 packet manager: Opensuse and Nvidia services cannot be deleted via YaST2

After some updates of leap 15.5 you may find that all basic repositories have been switched to “services” at “cdn.opensuse.org”. What is disturbing: A fresh installation of Leap 15.5 from an ISO-image does not show any of the services displayed in the image above.

Once you got the “services” in your Leap 15.5 installation you may want to delete them and restrict your system to the standard repositories at “download.opensuse.org”. But this does not work with YaST2. Which appears as an additional bug. You may switch to “services” and delete them in the views coming up. And everything afterward gives you the impression that they are gone. But no: After a restart of YaST2 and the packet manager all Opensuse services appear restored again.


YaST2’s present packet manager for Leap 15.5 has a major bug: Repositories can not be added. In addition one cannot get rid of the new Opensuse services. Let us hope that we get a new and error free version of YaST2’s packet manager soon.

Eclipse Oxygen3 – old bug blocks certain key combinations in editors – e.g. Ctrl+Right/Left for next or previous word

After changing to Eclipse Oxygen 3 for my PHP work I have spent an hour to find out out what was wrong with the keyboard actions for navigating through code. One of the key combinations one typically needs is “Ctrl >” and “Ctrl <” to jump from one word to the other – more precisely between some whitespace/letter-combinations which are interpreted as word separation borders.

Whenever I restarted or reopened Oxygen3 the already opened editors on files I had worked with during the last session did not show any reaction to such key combinations. However, when I closed the file and reopened them again with the structured PHP-editor the key combination did work. But after a restart of the workspace no reaction again. It really took me a while to find out that all this was due to the “welcome” screen, which I had not deactivated, yet, in the new installation. After knowing this, I even did find a corresponsing bug and stack overflow report.


Just deeactivating the welcome screen did the trick. I find it very frustrating that this is really a rather old bug – and I could bet it cost a lot of people nerves and useless efforts.