Tim Gary

We have the exact same warning in the logs. Doesn’t matter if PHP 8.0, 8.1 or 8.2 they all have the warning. Nt problems using 7.4 but it is not supported and we need to update but don’t really want errorlog files growing quickly.

I there any simple way to track down the cause?

It would be super useful to have this hook.

In our case, we don’t want admins to be synced at all between sites. One site is a cart/WooCommerce site for purchases and one is for course material. The course material people shouldn’t have access to the cart site since that could be problematic–and same in reverse.

The common setup for this plugin would likely be similar to this. Granted, many sites are small and don’t have more than one admin and they handle both, but that’s not the case for us. If we could filter by role it would simplify things greatly.

Thanks!

I saw the update, and it looks like this is fixed. Thanks again @joedolson !

• This reply was modified 4 years, 5 months ago by Tim Gary.

Thanks Joe. Really appreciate it!

Ok, understood on the changelog ??

Thanks for taking another look, or bumping this item for inclusion in a new version. We’d love to be able to update safely again.

If some sort of workaround were possible via functions.php or otherwise, that would help in the meantime.

-TIm

Hi Joe,

Just looking to see if this might still be on your radar. I tested the latest version 3.2.7 and the issue remains. As noted above, the “previous” button is showing now, but not the “next” button.

Thanks!
-Tim

Note: changelog.txt file in plugin only goes up to 2.5.17 ??

• This reply was modified 4 years, 6 months ago by Tim Gary.
• This reply was modified 4 years, 6 months ago by Tim Gary.

Quick note/clue: Latest version shows the “previous” link now. “Next” is still missing, but maybe that’ll give a hint as to what’s going on.

Hi Joe,

Thanks so much for the response.

Is there anything we might be able to help with to work through the conflict? We do have a dev/test environment I can enable and provide access for debugging. Contact me privately for details.

Thanks again,
Tim

Hi Aakash,

I’ve contacted you via your site. Much appreciated.
-Tim

Can we please have a step by step outline of what’s needed to recover from this issue when we updated from 4.6 to 5.x prior to the “fix”?

Since we updated already, there are already shortcodes in the new locations.

I’m assuming that’s why updating again doesn’t do anything.

The question is, what’s the *safe* way to handle this?

Right now we have 4.6 data. We also have pre “fix” 5.x data. So when we try updating from 4.6 to 5.x (fixed) it doesn’t seem to do anything.

What are the steps to fix this specific situation?

Do we export 4.6 data, then update to 5.x (latest), then delete all the broken shortcodes there, then import?

Seems like that’s the most likely case, but we don’t want to loose, nor break anything.

Thanks

Hi Aakash,

I was referring to the backslash symbol \ disappearing, as in the original post.

I tried updating to 5.1 from 4.6 and the problem remains. I’m guessing this was due to updating this way earlier and the 5.x data not being replaced?

This is what we did:
1) updated from 4.x to 5.x before the fix was in place
2) discovered the problem noted above
3) saw this thread, and copied the 4.6 version to the plugin directory, with different directory name
4) renamed the existing live 5.x version directory, then renamed the 4.6 version to make it the active version
5) at this point we see the shortcodes with \ correctly
6) then we updated that 4.6 version to 5.1 via WordPress
7) the problem returned

So it appears that because we’d already updated to 5.x in the past it didn’t rescan and replace the previously updated shortcodes (from #1 above).

What is the safest way forward to update to 5.1 at this point?

Thanks,
Tim

We have this same issue. Reverting to 4.6 works fine, however then updating back to 5.1 the problem with missing \ symbols remains.

This may be due to already converting to 5.x earlier.

What are the steps to *safely* go from 4.6 to 5.x when that process was already done in the past and you want a fresh start?

Note: we simply renamed the new plugin directory and copied the 4.6 files back in this case.

Thanks,
Tim

On “upgrade” the .htaccess file has bad code in it that brings down the server.. to fix, try the following…

If the beginning content in the file beginning of the file looks like:

# BEGIN iThemes Security
# BEGIN Ban Users
Order allow,deny
Deny from
Deny from 176.53.65.71
Deny from 141.138.204.113
Allow from all
# END Ban Users

Remove the entire line that just has “Deny from” on it, so that it looks something like:

# BEGIN iThemes Security
# BEGIN Ban Users
Order allow,deny
Deny from 176.53.65.71
Deny from 141.138.204.113
Allow from all
# END Ban Users

Note, the IP addresses shown will likely be different for each site, and there could be many more of them, or none at all. Just remove the line indicated and leave the rest.

Hope this helps.

Thanks Jean, I’m sending it via email directly and momentarily rather than posting it here.

This is actually a much worse problem than reported above. *all* custom post types break with the latest releases (3.31 and I assume 3.3, but am not sure)

For example, using the “Agentpress Listings” plugin, you have custom post types that begin with “listings” among others. With this latest version of WP RSS Aggregator, all of the listings and other custom post type pages return 404 errors.

Tested under WordPRess 3.52 and 3.6
Reverting to 3.2 fixes the problem.

Other than this recent bump, I appreciate your plugin, thanks!