korynorthrop

@sumitsanadhya thanks for your reply. Well, from my perspective it still seems like a QSM issue. When I disable all other plugins, enable the default 2023 WordPress theme, and activate your plugin, I get the critical error. When your plugin is disabled it goes away. There are no other plugins activated and no customizations on the theme. So, really there’s nothing else I can point to except your plugin being the cause of the error. So how can we move forward?

[ Please do not bump. ]

Can I upload/send it to you somehow? I don’t want to post it on this forum since it has server information in it.

Thank you for the reply @sumitsanadhya. Those are the same changes I already made and they do not fix the problem. I still get the same error message, “There has been a critical error on this website. Please check your site admin email inbox for instructions.” I even tried on a fresh install of version 8.1.14 of your plugin.

Thank you @sumitsanadhya. The website and example page that uses a QSM shortcode is here. We’re using version 8.1.14.

Thanks for the reply, @suascat_wp. I’m not looking to modify the schema, I’m just wanting to fetch the schema for a page.

It’s a bit strange to me that the filters would be removed without any mention of that in the version notes. But, also, the filters still exist in the code base they just don’t work.

@shresthauzwal I’m curious why you had to write custom code for me when your plugin ostensibly already had filters in place to do the exact thing that I was trying to do. Is there a plan to address those other filters that aren’t firing?

@shresthauzwal I tried the user_registration_success_params filter and it worked, the new user was redirected to the new $redirect_url defined in the custom function. Is there documentation for the user_registration_success_params filter, I searched your website, but could not find anything.

So of all of the hooks that I’ve tried, these ones successfully fired:

user_registration_success_params
user_registration_before_register_user_action
user_registration_after_register_user_action

But these ones do not fire:

user_registration_login_redirect
user_registration_redirect_from_registration_page

• This reply was modified 2 years, 7 months ago by korynorthrop.

I replaced the version of the User Registration plugin with the .zip version in your link, but it is still not working. The user_registration_login_redirect filter does not appear to fire whatsoever.

Thanks for your reply @shresthauzwal. I added your code snippet, but it didn’t help. I already mentioned that I tried using the user_registration_login_redirect filter to no avail. It doesn’t even seem like that filter is firing because I have an error_log() statement in the function that is called on that filter, but nothing gets printed to my error log.

I have the “User Approval And Login Option” setting set to “Auto approval and auto login” as well.

What other ideas do you have?

@westerndeal I got it working, it wasn’t made clear that the “Google Sheet ID” and “Google Tab ID” were both required when making the connection between a CF7 form and the desired Google Sheet. All is working fine now.

I am having the same issue as the other posters and have been unable to resolve it following the directions given by the plugin author.

Thank you very much @rockfire for chasing down the problematic code in the Revisions plugin and thank @kevinb for making the appropriate fix so promptly. I have been out of the office all week and am just seeing this now. I’ll be sure to open a ticket to get the 2.4.9-rc version. Happy new year, y’all.

Thanks for your reply. I created a brand new sandbox and only installed WP REST Cache then repeated the process I outlined above. This time everything worked fine, just like your testing showed. So, I’m not sure what happened with my first new install.

Anyway, I re-examined by production and staging sites, disabling all plugins and switching to Twentytwentyone theme. Everything worked fine with just WP REST Cache enabled. I re-enabled the remaining plugins one-by-one and re-tested and I found that there might be some kind of conflict between WP REST Cache and the PublishPress Revisions Pro plugin. A NULL value is consistently returned if both plugins are active at the same time, however if I only have one enabled (doesn’t matter which one) then the
wp.data.select('core').getEntityRecords('postType', 'attachment', { include: [ 6 ] })
call returns the media data properly.

Any thoughts on how to dig further into this? I can raise a ticket with the author of PublishPress Revisions Pro as well, just curious if any potential thoughts come to mind on what could possibly be conflicting.

• This reply was modified 4 years, 3 months ago by korynorthrop.

Yeah the closure works, but not the named function. It’s bizarre, I’m a little baffled, but I’ll keep digging in a bit more to see if I can figure it out.

I actually started doing exactly what you suggested with removing the callback from the filter stack after it’s called and then re-adding the filter later on. I was able to reduce the number of fires to two that way, but still trying to find the proper hook to re-add the wp_insert_post_data filter so that it doesn’t fire any additional times. However, like you said, the downside of doing a string replace a few times isn’t too awful, so I might just cut my losses and move on.

Thanks for your feedback.