Conflict with WP RSS Agregator after update to 18.2.18

Hi,

Thanks for reporting this. This is caused by a PHP library conflict. Namely symfony/translation

Both Shield and WP RSS Aggregator have the same PHP library in their plugin but with different versions. It means that when certain code in 1 plugin requires that library and it’s of a different and incompatible version, you’ll get the fatal error.

Shield’s minimum PHP version is 7.2. This means the libraries it uses are fairly recent. The library version in Shield is v5.x, while the library in WP RSS is a bit older at v2.x. The reason theirs is older is because they support older versions of PHP: 5.4+

This restricts them to using older libraries that are going to eventually, as in this case, lead to conflicts with plugins that require a higher minimum version of PHP.

The choice in your case is, unfortunately, not a great one. We don’t plan to downgrade our libraries – in fact, if anything, we’re going to keep pushing our minimum versions higher over time. These are your options:

• ask the developers of WP RSS Aggregator to consider upgrading their libraries.
• if they don’t, you may need to find an alternative.
• find an alternative to Shield Security (there isn’t one ?? )

This incompatibility is the nature of how WordPress works – if it’s not Shield+WP RSS that has a incompatibility today, it’ll be another plugin that has conflicting requirements with WP RSS, as their libraries are fairly outdated. To our mind, the better approach is to move PHP requirements upwards all-round, just as WordPress itself is doing with 6.3 and a minimum requirement of PHP 7.0.

There’s no happy solution here for everyone. Some time ago we ran into similar issues and decided to take steps to bring Shield’s libraries up-to-date.

Let us know if you have any questions and we’d be happy to help.

Edit: if you want to temporarily resolve this issue until the next WP RSS Aggregator upgrade, you can rename the directory
plugins/wp-rss-aggregator/vendor/symfony/translation/
to anything, for example:
plugins/wp-rss-aggregator/vendor/symfony/translation-backup/

This will prevent their older library from loading. It may cause other issues with their plugin that I’m not aware of, so have a test of their functionality to see.

• This reply was modified 1 year, 3 months ago by Paul. Reason: added workaround

I too am experiencing this FATAL error. Thanks for your response Paul – that makes sense. I will look further into a fix.

@rcain if you’re getting the error but you don’t have the WP RSS Aggregator installed, it’s probably a conflict with another old plugin, or plugin that support older PHP versions. If you do a quick audit of your plugins, and test by temporarily disabling the suspected plugins to see if the error disappears, you should hopefully find it.

Hi Paul – Thanks for the reply – I should have made clear – I am using WP RSS Aggregator plugin and have already disabled it temporarily. Awaiting a response from WP RSS Aggregator authors (As you suggest, they need to update the symfony package their end, or avoid conflicts some other way). (Increasingly frustrated that ‘Composer’ is supposed to help avoid situations like this, yet in reality seems to encourage bloat without properly addressing dependencies – not a criticism of your fine plugin ?? ).

It’s unfortunately not Composer’s “fault” either. Composer works great, in-and-of-itself.

The issue comes from how WordPress plugins work. Let’s say plugin A needs PHP library X. But plugin B also needs library X and so the developers of the respective plugins independently include library X in each of their plugins (via composer).

If library X are of different versions in the 2 plugins, and introduce incompatibilies for the code of the other plugin, you get this problem. But, each plugin needs to have the library present. How do you mitigate this issue at scale?

There are certain solutions out there, which we will probably explore as this problem does continue to pop up every now and again…

Hi Paul, yes i realize all that. (Sorry, having a bit of a general bitch). Maybe a case for WordPress itself to address this – eg: something akin to the JS/script (version) register & load process, but for PHP libs (& any other (co-) dependencies) – would still need to isolate them of course & avoid run-time conflicts. Anyway, that’s a bigger discussion for another day/forum. wp rss aggregator devs are looking at it from their end now at least. Thanks again. ??