WordPress.org

Ready to get started?Download WordPress

Forums

Enclosure Custom Field Erasing after Saving Post (50 posts)

  1. Hi there,

    I've encountered a strange bug where a custom field called "enclosure" added to a post (which contains an MP3 podcasting URL) is getting erased whenever the post is saved. The field seems to still be there after pressing "Save/Update" but when you return to the post after closing it, the custom field is completely gone.

    My client noticed this problem recently so I'm not sure when it started, but I haven't made any changes to the site recently other than update some plug-ins, which I've ruled out as the culprit (see below for the reason.)

    I found one workaround that may provide a clue: if the custom field is simply added (using the button "Add custom field") and the post is not re-saved afterwards, it does not get erased. So it seems like it's definitely the act of saving that is causing the erasure. This workaround is not practical in the long term as occasionally my client needs to go back and edit the post, and the enclosure then gets erased and does not correctly appear in the podcast feed.

    I can add custom fields with any other name besides "enclosure" and they don't get erased.

    I've tried turning off all plug-ins, but the problem persists.

    Two additional strange things:

    1) I noticed this Trac history which at first sounds related, but in my case the same MP3 URL is linked to in the post itself, so perhaps it's not the same issue.

    2) I have the same site (same custom theme, plug-ins) running on my test server, and I do not have the enclosure erasing problem. I can edit posts there and the enclosure stays, as it should. Both test and live site are on the same server and running the same version of WP (3.3.1). I can't think what the difference could be that might cause this issue.

    Thanks in advance for any ideas.

  2. esmi
    Forum Moderator
    Posted 2 years ago #

    Are you sure that field's title is "enclosure" and not "_enclosure"? Any custom field whose title begins with an underscore is hidden from the Custom Fields display in Edit Page/Edit Post/

  3. Thanks, esmi. Absolutely - it's enclosure - no underscore.

    It's not just that the field gets erased from the WordPress admin area - unless that enclosure field is there, the audio interview does not get fed correctly to iTunes for podcasting purposes, so it's a really serious glitch.

    All has been working fine for many years - so strange that this problem started all of a sudden.

  4. sebastiencyr
    Member
    Posted 2 years ago #

    Have you checked in the database if the entry is there in the postmeta table? (if it's either set or just empty)

  5. Sebastien - I see something like this when the enclosure is there:

    http://www.twitpic.com/8e17kc

    After saving the post that field disappears from phpMyAdmin completely.

  6. sebastiencyr
    Member
    Posted 2 years ago #

    if your WordPress site didn't change, maybe the hosting did. I've seen some crazy stuff happen when the host suddenly installs new mods for apache/php like suhosin.

    I would also try and rename the field to something like enclosure2 to see if the same information stays under a different name.

    Maybe I'm just shooting in the dark, this Is pretty weird...

  7. esmi
    Forum Moderator
    Posted 2 years ago #

    It might be worth testing this out in a local install to see if this "removal" is server specific.

  8. esmi
    Forum Moderator
    Posted 2 years ago #

    FWIW, just ran a test on my local server. Added a custom field called enclosure (value : testing) to a random post without any problem. No erasure.

  9. if your WordPress site didn't change, maybe the hosting did. I've seen some crazy stuff happen when the host suddenly installs new mods for apache/php like suhosin.

    It might be worth testing this out in a local install to see if this "removal" is server specific.

    Hiya, thanks for both your ideas.

    I don't think it's a server issue since I have a test version of the same site (same theme, same plug-ins) running on the same server on a test domain - and there is no problem with custom fields getting erased on the test server!

    Sebastien - I've tested fields with all kinds of other names and they are not erased. I will now try enclosure2 for fun. ;-)

  10. p.s. it's my own dedicated server and just for the record we haven't made any changes on it lately.

  11. Further tests are still mystifying:

    - If I rename the field as enclosure2, it gets added OK, but the old enclosure field stays put too, even if I delete it

    - putting a word (rather than a URL) still causes the erasing problem

    Here's the biggest weirdness to date. There are over 150 interviews in the system. I went back and spot-checked a half-dozen of them, and all stay OK after saving (i.e. enclosure is not erased) until the most recent few. And when I add a brand new one, the enclosure is also erased on saving.

  12. sebastiencyr
    Member
    Posted 2 years ago #

    In phpmyadmin, if you search for all metas for a post with the erasure problem, are there more than one meta with the enclosure key?

  13. Only one enclosure meta in phpMyAdmin for posts with the issue. (I did a search for two.)

  14. esmi
    Forum Moderator
    Posted 2 years ago #

    Been giving this some thought... do you have any inactive plugins that could be using the same custom field title? enclosure is rather a generic title - which opens up the possibility of some sort of custom field name conflict.

    If you had a rogue plugin that also used enclosure as a custom field name but which updated its field by deleting and then setting up the record again (instead of updating) and fell over after the delete step, that would explain what is happening. I may be stating the obvious but a theme switch to Twenty Eleven and a plugin reset via the db would rule out or confirm any such conflict.

  15. Hi Esmi, Thanks for all the suggestions so far. Very appreciated. Interesting theory about the rogue plug-in. The only inactive plug-in on the live site was Viperbar, which I've just removed.

    I am really loathe to switch themes temporarily - this is a well-visited live site and I don't want to risk anything further going awry during the process of switching and switching back. Same concern with resetting the plug-in database. I saw this plug-in - http://wordpress.org/extend/plugins/wordpress-reset/ - and it says it resets all plug-in values to defaults? This site has about a dozen well-configured plug-ins, I don't think I can risk wiping out all their settings. Or maybe I'm misunderstanding what a plug-in reset does?

    If I can't resolve this I'm going to have to start looking for a new audio plug-in. We've been using WP Audio to convert the audio links to an audio player but its development seems to have been abandoned in any case. See my earlier related thread: http://wordpress.org/support/topic/plugin-wpaudio-mp3-player-wp-audio-no-longer-adding-mp3-enclosures-as-custom-fields?replies=1

  16. esmi
    Forum Moderator
    Posted 2 years ago #

    I am really loathe to switch themes temporarily - this is a well-visited live site and I don't want to risk anything further going awry during the process of switching and switching back.

    Can you replicate the basic setup in a dev/local install? Same active & inactive plugin(s), same theme?

  17. Hiya, I do have an almost identical install already running on a test server.

    Let me go install the few additional plug-ins on the test site that that the live site has - and see what happens!

  18. Still no luck. Cannot get enclosures to be erased on the test server - same theme, same plug-ins. :-(

  19. esmi
    Forum Moderator
    Posted 2 years ago #

    Can you run php info() on both servers (local & live) and see if any obvious differences crop up?
    Anything cropping up in the server's error logs?

  20. I will check the server logs...

    I can also try running phpinfo() but it's literally the same server (mine) so I don't expect to see any differences... so weird.

    Thanks again for your persistence!

  21. esmi
    Forum Moderator
    Posted 2 years ago #

    Are the two sites literally on the same server? If so,l that rules out anything at the server level and you're back to looking at the environment of the sites themselves. I have to ask... have you tried a db plugin reset?

  22. Yes, the two sites are literally on the same server: my own dedicated box. Same IP and same physical machine.

    I have to ask... have you tried a db plugin reset?

    What do you mean exactly by a db plug-in reset? Is it using a plug-in like the one I mentioned above to set all plug-ins to their defaults?

    If so, I haven't - am nervous about having to reset every single plug-in. In fact, we have one plug-in doing an A/B split test right now gathering stats - things like that just can't be reset, unfortunately.

  23. esmi
    Forum Moderator
    Posted 2 years ago #

    What do you mean exactly by a db plug-in reset?

    The Phpmyadmin method described in resetting the plugins folder.

  24. Thanks, esmi - I haven't tried that. What do you think is the risk of plug-ins getting messed up when reverting the option_value field back after the test?

  25. esmi
    Forum Moderator
    Posted 2 years ago #

    A well coded plugin should only remove its settings from the db when it is deleted via the Admin, so the good ones should be fine. However, in these situations, I sometimes take screenshots of the more complex settings pages - just in case. If you use Firefox, the Pearl Crescent Page Saver add-on is brilliant for this as you can save a screenshot a complete page (not just the visible part) in 2 clicks.

  26. Thanks for the tips, Esmi!

    Going back to the error logs, this is the only error showing from yesterday, it relates to the Yet Another Related Posts plug-in:

    [Tue Jan 31 11:19:39 2012] [error] [client xxxxx] PHP Warning:  Invalid argument supplied for foreach() in /home/xxxxxx/public_html/boc/wp-content/plugins/yet-another-related-posts-plugin/options-meta-boxes.php on line 236, referer: http://www.boxofcrayons.biz/boc/wp-admin/plugins.php?activate-multi=true&plugin_status=all&paged=1&s=
    
    [Tue Jan 31 11:19:39 2012] [error] [client xxxxx] PHP Warning:  Invalid argument supplied for foreach() in /home/xxxxxx/public_html/boc/wp-content/plugins/yet-another-related-posts-plugin/options-meta-boxes.php on line 177, referer: http://xxxxxx/boc/wp-admin/plugins.php?activate-multi=true&plugin_status=all&paged=1&s=

    I could try resetting YARRP to its defaults in the database if I find instructions on how to do that - do you think that's worth a try? There is no similar error on the test server.

    Regarding the phpMyAdmin plug-in reset - I could perhaps try it on the test server first and see if any plug-in settings are lost. Good tip to take a screenshot of all settings first, too.

  27. esmi
    Forum Moderator
    Posted 2 years ago #

    Yes - I think it's worth a try.

  28. Reporting back:

    Completely uninstalling YARPP including the database tables - no effect, enclosure still erasing.

    Next, I went into phpMyAdmin to try to reset the plug-ins folder, following the directions linked to above.

    But... the value of the active_plugins field in question already says a:0:{} so now I'm stuck again. :-( See screenshot here: http://www.twitpic.com/8efe8w

  29. p.s. do you think I should instead try resetting the plug-ins folder with method 2 - i.e. by renaming it via FTP ?

  30. esmi
    Forum Moderator
    Posted 2 years ago #

    value of the active_plugins field in question already says a:0:{}

    Are any plugins active?

    do you think I should instead try resetting the plug-ins folder with method 2 - i.e. by renaming it via FTP ?

    Yes.

Topic Closed

This topic has been closed to new replies.

About this Topic