ulicgn

@stevejburge Our status after 3.0.3 https://www.ads-software.com/support/topic/feedback-to-3-0-3-update-regarding-error-messages-and-empty-action/

I am closing this issue, this specific problem seems to be fixed, or at least I think so since I was able to bulk delete some orphaned items.

We have a couple more plugins using ActionScheduler, among them heavy ones like EventCalendar, Imagify and RankMath. So far no problems other than the one reported here.

Thanks and best regards, Ulrich

Oh, I didn’t see the github issue regarding #3. Great! So closing this issue, too. Thanks for the quick reaction to get 3.x running smoothly …

Update after 2 hours live operation with 3.0.3:

1. Since only 2 posts were causing the “configuration problem” warning message and empty action string, we just did the whole process again – disabling and re-enabling PPF actions on the problematic posts, and re-saving the desired actions. Now there are no more error or warning messages, and no mor items with empty action string in the list of future actions.
2. Newly created posts with PPF actions seem to be fine now
3. The one thing that persists, though: The Warning modal regarding unsaved changes keeps reappearing every time and for every post that has a PPF action.
   https://i.postimg.cc/k4pj8x0J/grafik.png

I think I saw other reports regarding this, but they might have been overshadowed by the more importan issues. Is it worth creating a new issue?

Regards, Ulrich

I went up to official 3.0.3, see my report at https://www.ads-software.com/support/topic/feedback-to-3-0-3-update-regarding-error-messages-and-empty-action/

Closing this issue, since there are enough others for this problem.

Update: our editors report new items with the message

“Action scheduled but its definition is not available anymore. Did you disable the plugin that defined it?”

after they update a post. In the post overview the message shows, in the future actions overview the action of the same item is just an empty string.

https://postimg.cc/jwwH17JV

https://postimg.cc/TLLFf04C

N.B. : the post causing the message and the empty action is scheduled for publication in the future using wordpress’ default scheduling mechanism.

• This reply was modified 1 year, 9 months ago by ulicgn.

Thanks for testing it! The problem appeared after the 3.0.2 update of PPF and it appeared after I did an action within PPF ( bulk deletion of actions) . So my conclusion was it has to do with this update, not with RankMath
( or other plugins using ActionScheduler as well – which never caused a problem so far) and would not be a support case for RankMathPro.

So if you think it is NOT an issue of PPF’s process_actions calling Rankmath’s process_bulk_actions() , see #2 and #3 of above stack trace, then we could close the issue.

But all this might also be a remainder of the Problems we had during the 2.x->3.x upgrade which has probably left some inconsistencies with some posts. The upgrade process with it’s on-the-fly fixes was a bit bumpy …

@mcsr regarding this error there is already a support thread with a link to a beta version, check it out at

https://www.ads-software.com/support/topic/uncaught-error-in-3-0-1/

Just a short update – it works as planned. I installed the prerelease version and checked the cache content of the affected posts immediately after a reordering operation: they are invalidated after reordering and have the new menu_order value as soon as they get recreated in the cache. This means that the new order is now shown correctly in both frontend and backend. In my use case, it was not necessary to implement the hook. Thanks!

@mguenter FYI

Hallo @mguenter ,

I very much appreciate that you tackled the caching problem and even created a prerelease version. Thanks for that!! Also, using clean_post_cache to invalidate only the changed items seems like the best solution, and the additional hook might prove useful , too – just to be sure …

I will certainly give it a try and report how it works! However I am not so sure any more whether or not we can actually use the object cache in production. I was assuming that WP core would handle the object cache “automagically”, like it does with transients. Since this assumption is wrong, we would now have to check each and every plugin for object cache compatibility (which is probably too much hassle) or use the cache with a very short lifetime only, which partly defeats its purpose.

Anyway, it is helpful to know that at least RCPO will now work well with our cache. ( So far, we did not identify other plugins with similar caching problems, but I assume there will be more. )

Thanks and best regards

Ulrich

It seems as if RCPO is writing the new values of menu_order directly into the posts table , so no caching solution whatsoever will be able to detect this change. So RCPO can not be used in combination with an object cache … right? Is there a filter/hook that can be executed either for each post that is changed, or generally after each reorder operation? This would at least allow to create a custom filter that invalidates the cache if a write operation has occured.

Thank you for taking the time to respond! Actually I did look into the FAQ before posting, but did not find information relating to this specific problem. ( OK, there is the generic recommendation to “contact the support team of the plugin regarding the issue and ask them to ensure object cache compatibility …” etc – I did so, up until now without response)

Regarding this specific case, where information from a core table ( wp_posts.menu_order field) is used, I assume that the plugin is writing directly into the wp-posts table with SQL so there is no chance for any caching solution to get informed about the change.

So the only solution I can think of is to clear the cache after each reordering activity, right? This would require the presence of a specific hook/filter at the “stupid” plugin’s side that is executed when a write activity occurs. If there is such a hook/filter, I could use it to perform a cache invalidation. But would it be possible to empty just the wp.posts cache subtree instead of completely invalidating the whole cache?

• This reply was modified 1 year, 10 months ago by ulicgn.

Why would you want to do that? Usually the memcache server takes good care of managing memory , expiring stuff etc. So you probably would be better off just restarting memcache on the server side if you want to free resources.

Since this “plugin” has no memcache gui management, you would have to install a simple memcache manager somewhere outside of WordPress, like this one: https://github.com/kn007/memcache.php . It has something like a dashboard view and a “flush” link. But note that “flushing” does not free memory, it just expires everything to be free for overwriting.

Be careful where you place it and make sure you change the default admin credentials so no one else but you can use it.

Note: The plugin recommended by @dgswim @mariankadanka is not maintained any more and also not update for some years now.

@vol4ikman : see https://www.ads-software.com/support/topic/fatal-error-php-9/

• This reply was modified 1 year, 11 months ago by ulicgn.

Just follow the install instructions letter by letter. After that, apologize to the team and upgrade your rating to, at least, 3 stars.

I have to admit though that the install process is highly unusual and error-prone, but that does not mean you can skip reading the docs and then belch out a one star review.