PHP 4.4.4? Suddenly new posts are drafts, cannot delete posts

  • Resolved adagiomarine

    (@adagiomarine)


    17 years, 7 months ago

    Running v2.0.2. I’ve been troubleshooting for 10 days a mystery — the symptoms:

    – a new post via xmlrpc results in a null response [using ecto application]
    – the new post is saved in mySQL, but tagged as “draft”

    I immediately retested using WP direct interface wp-admin/post.php getting the same results. The browser page refreshes with a blank screen. NB, the URL is not changed to wp-admin/post.php?posted=true as it should be, so the PHP code did not complete normally.

    Obviously the problem isn’t xmlrpc.

    – using the PHP admin interface I can change the new post status from draft to “published”, save it – then the post displays normally
    – using /edit.php or /post.php I cannot delete the any post [no errors, but the browser page doesn’t repaint]. I can simulate a delete using /edit.php to change status to “draft”.

    I can of course delete the posts directly in mySQL.

    To troubleshoot, I cloned the exact, entire WP install directory, seekerblog.com/www/ into my “test” install seekerblog.com/www/test/. The http://seekerblog.com/test/ instance works fine in all regards [except dbms state is only Mar 15,2006].

    Bottom line unless I’ve missed something, [2] works fine, [1] fails where:

    1] main instance, WordPress Address & Blog Address both point to http://seekerblog.com

    2] test instance, WordPress Address & Blog Address both point to http://test/seekerblog.com

    3] both directories are identical, though mySQL post tables are not up to date in the seekertest instance.

    4] I also got a null differences result from comparing my existing main directory to my local master version of the 2.0.2 installation.

    What else is different? The excellent support folk at luxsci.com replied

    “The only thing that has changed on opur side in the past 2 weeks is that we upgraded PHP from v4.4.3 to v4.4.4 and apache from 1.3.36 to 1.3.37 to fix some security issues. I suppose it is possible that the internal changes in PHP may have had some effect.”

    Any suggestions would be much appreciated – I’m stuck.

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter adagiomarine

    (@adagiomarine)

    17 years, 7 months ago

    Updated problem isolation tests:

    To isolate between SQL dbms problems and WP install directory problems, I have had web host restore the production mySQL rows into the test instance. Now both WP install directories and mySQL dbms are identical between test and production blogs.

    And now the seekerblog.com/test instance fails identically to the production case.

    That implies to me that the problem is associated with the SQL dbms rows.

    Thanks in advance for suggestions on what to do next. E.g., is there any way the PHP v4.4. or Apache 1.3.37 updates could cause this problem?

    vkaryl

    (@vkaryl)

    17 years, 7 months ago

    Sure, server “updates” can cause stuff like this. Thing is, I’ve had wp working normally for the last couple of months on the backend versions your host is saying they just implemented – with no errors at all….

    [Um. Leaving out the fact of course that part of the “updates” MY host did included a serious mod_security “fix” which meant NOTHING worked – so now I have NO mod_sec on my server….]

    Thread Starter adagiomarine

    (@adagiomarine)

    17 years, 7 months ago

    vkaryl,

    >I’ve had wp working normally for the last couple of months on the backend versions

    Thanks, that’s helpful to know. Are you running 2.0.2 or …?

    I’m considering asking web host to restore Sept 1 backup to my test blog – i.e., content prior to the mystery. If that works, do I have a “corrupt dbms”? Then what?

    vkaryl

    (@vkaryl)

    17 years, 7 months ago

    2.0.4 – I update immediately whenever there’s a new version. Part of the situation with my reseller/host provider is that I’m basically responsible for making sure EVERY SCRIPT I run is the most up-to-date and (presumably) most secure version out there since what they did with the mod_sec ruleset meant that NONE of my php scripts worked (can you say “unhappy clients”? – and that was putting it mildly….)

    So for your situation…. first, try repairing the tables which seem to be involved. If that has no effect, try repairing the whole database. If you’re not able to do this yourself, your host should be able to do it for you.

    If you still are in the same ditch, make sure you have backups of the databases (even if corrupted), and try upgrading to 2.0.4 – can’t hurt (because it can’t make it any worse than it already is), and might help….

    Thread Starter adagiomarine

    (@adagiomarine)

    17 years, 7 months ago

    I’ve found the problem I think, by snapshoting the error log before/after attempting a new post [via xmlrpc]. This generated 2 log entries [see below]. I disabled the Google Sitemap plugin –>> all works OK now.

    I think what happened is the size of mySQL database reached a point two weeks ago which caused the Sitemap plugin to need more memory. I’ll report this to Arne Brachhold.

    [Tue Sep 19 08:39:46 2006] [error] ALERT – script tried to increase memory_limit above allowed value (attacker ‘142.179.103.65’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/wp-content/plugins/sitemap.wp2/sitemap.php’, line 1516)
    [Tue Sep 19 08:39:53 2006] [error] ALERT – configured GET variable value length limit exceeded – dropped comment (attacker ‘212.248.241.2’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/index.php’)
    [Tue Sep 19 08:40:41 2006] [info] [client 202.108.1.5] (104)Connection reset by peer: client stopped connection before rwrite completed

    Chris_K

    (@handysolo)

    17 years, 7 months ago

    Ahh… I wonder if when the PHP upgrade happened, you got the default 8MB php max memory default set instead of whatever it may have been previously?

    Thread Starter adagiomarine

    (@adagiomarine)

    17 years, 7 months ago

    HandySolo,

    > you got the default 8MB?

    That is a very good point – thanks heaps for that insight. In fact the test I just completed may confirm your thesis. I had the “test” mySQL instance restored to Sept 1 – before the mystery errors. And of course a somewhat smaller database. If my thesis was correct it should have worked.

    But it didn’t – same errors – until I deactivated the Google Sitemap plugin. I think this points to the PHP update in some way – your thesis being a leading candidate. It could also be a 4.4.4 issue in the Google Sitemap plugin.

    Thread Starter adagiomarine

    (@adagiomarine)

    17 years, 7 months ago

    A followup to make this thread complete for future reference. Further testing indicates that the source of these problems is the combination of PHP 4.4.4 and the Google Sitemap plugin.

    Our web host luxsci.com updated to PHP 4.4.4 late evening on Sept 9. Not long after our site error log shows the first instance of this error:

    [Sat Sep 9 22:18:59 2006] [error] ALERT – script tried to increase memory_limit above allowed value (attacker ‘142.179.100.111’, file ‘/xd1/homes/hash/41/a2141/90/05/u20590/seekerblog.com/www/wp-content/plugins/sitemap.wp2/sitemap.php’, line 1516)

    Where line 1516 is:
    ini_set(“memory_limit”,”128M”);

    Our web host confirms that their administrative memory limit [8MB] overrides the ini_set() call. I speculate that v4.4.4 changed the way ini_set() operates – perhaps the prior versions didn’t generate an error when the requested limit could not be established?

    I have also installed the WordPress 2.0.4 update and retested – the error persists.

    I just added the sitemap tag to this post. And I’ve emailed the plugin author Arne Brachhold.

    My workaround is to disable the plugin until this is resolved.

    Any other suggestions welcomed.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘PHP 4.4.4? Suddenly new posts are drafts, cannot delete posts’ is closed to new replies.