Forum Replies Created

Viewing 5 replies - 16 through 20 (of 20 total)
  • Thread Starter fractaleater

    (@fractaleater)

    Just a follow up here. So, the problem is located in the plugins_loaded and wp_loaded hooks.

    The password submit action generated by get_the_password_form sends “wp-login.php?action=postpass”, and post data of the actual password. In plugins_loaded, the plugin sees the request as a wp-login.php anonymous access attempt and quashes it by stomping on the request URI. Later, wp_loaded checks $_GET and $_POST, which it rightly expects to have been filled earlier, to identify “action=postpass”, but at that point, both $_GET and $_POST appear to be empty (at least using error_log). This causes the plugin to pass the request along as is, and the browser gets a 404 response.

    The problem is that in wp_loaded hook $_GET and $_POST are both empty.

    Similarly, both are empty in the earlier plugins_loaded hook. I suppose one could make the thin argument that changes to $_SERVER[‘REQUEST_URI’] in plugins_loaded trigger changes to $_GET and $_POST, and my error_log statements that occur before the modification could be a result of output buffering, but I disabled the modifications in plugins_loaded and $_GET/POST were still empty. I also changed the priority the hook tomuch earlier and much later to bypass any naughty plugins without effect.

    So, unclear why these PHP globals are empty. The site has PHP 7.4.15. WordPress W3 Caching disabled, CloudFlare CDN in development mode, tried Chrome browser incognito and normal window, and logged in admin user, all result in empty $_GET/POST. Used Chrome development tools to verify form and expected URL.

    Best guess with existing information is htaccess QSA flag behavior needs to be implemented/checked in WordPress add_rewrite_rule, but less clear what is going on with empty $_POST when it should contain “post_password”.

    Richard

    Thread Starter fractaleater

    (@fractaleater)

    I use a plugin to vacuum revisions, and based on reading some of your other detailed threads, you try to be efficient in the post-save, so probably these videos were at some point inserted in posts they currently make claim to, but the revisions no longer exist.

    I’ve found that just hammering the database with something like:

    SELECT * FROMpostsWHEREpost_contentREGEXP '\\[video.*blah..blah.*\\.mp4"\\]\\[/video\\]' AND NOTpost_type= 'revision' AND NOT post_status = 'draft'

    Mostly solved my immediate problem.

    You asked for a page that has the problem. I’m not sure I can provide that without offering you temporary admin access.. (something I have no problem with, but just saying).

    Or is my vacuum plugin, “Optimize Database after Deleting Revisions”, theory probably the source of the issue?

    And if so, I’m not sure how to reconcile it. Perhaps, yet another feature to your quite rich product’s assets could introduce a button that rebuilds he “inserted in” field contents from scratch?

    Was working fine, but after upgrade to 2.1.8.1 on wp 4.7.1, I get a white screen on admin interface that corrects itself if I rename UPI plugin folder. I’m guessing the fatal error..

    Log file confirms:

    [16-Jan-2017 23:57:33 UTC] PHP Fatal error: Can’t use method return value in write context in [mysite]/wp-content/plugins/upi-crm-universal-crm-solution/admin/upicrm_settings.php on line 198.

    After rename UPI plugin folder back to normal, attempts to activate the plugin in admin interface are rejected with above error.

    Sorry can’t be more helpful.. if you provide a upicrm_settings.php with debug output, I can post sanitized results or email?

    Thread Starter fractaleater

    (@fractaleater)

    Was a memory resource issue.

    Found this one line construct in my wp-config:

    /**#@-*//** Memory Limits. */define('WP_MEMORY_LIMIT', '96M');define('WP_MAX_MEMORY_LIMIT', '128M');

    Which is actually *not* a comment. Making it a comment and increasing values to 128 and 256 corrected the problem.

    Sorry for the distraction, and thanks for your effort on this plugin.

    Definitely donation worthy!

    Thread Starter fractaleater

    (@fractaleater)

    Have not ruled out memory issues, but troubleshooting shows that with VC and MLA active, and disable “W3 Total Cache” and “Wordfence Security”, and “edit.php?post_type=page” shows expected results. Enabling either one of those two plugins results in a blank page.

    I’ve followed the instructions for increasing PHP Memory in wp-config, but my hosting provider says I’m not bumping against my 1GB limit.

    I’ve moved on to identify any other combinations of disabled plugins that don’t result in a blank page.

Viewing 5 replies - 16 through 20 (of 20 total)