Closed GoogleCodeExporter closed 8 years ago
Hi Fireproof!
An update...
I have another site that exhibits the same issue. Again it is an old site which
I've upgraded to V4 then installed CCTM to add new functionality. Again, I
disabled the other plugins and changed theme to ensure it's nothing I've done.
Interestingly, this site used a number of custom fields and none of the fields
are being saved, so this is clearly not specific to a field but a general issue
with saving field data. I tried hooking into add_post_metadata and
update_post_metadata but they are never called for any of the CCTM meta fields
in existing posts/pages.
However... if I create a new page/post and add custom fields they DO save! I
can only presume that somewhere in your save/update routine, it's failing based
on some confusion with the structure of old post data before the Wordpress V4
database upgrade and new post data.
I hope this proves useful!
Original comment by ThomasDa...@gmail.com
on 25 Nov 2014 at 8:24
After ages of digging found that the this was only impacting pages that had the
_wp_page_template custom field. Because we've created a new theme, we did away
with the old templates so they don't exist anymore.
I found this thread relating to an almost exact replica of this issue for a
similar plugin;
http://support.advancedcustomfields.com/forums/topic/fields-not-saving/
In the mean time, I'll delete the _wp_page_template from my database but I hope
this helps you address the issue for a future release?
Tom
Original comment by ThomasDa...@gmail.com
on 26 Nov 2014 at 12:20
Thanks for the detailed info, and you are correct: I don't police the forum,
and reports need to end up here in the bug tracker in order for me to address
them.
Given that the same issue has occurred with a similar plugin, my strong
suspicion is that this that the underlying cause is yet another WP failure of
architecture that these CMS plugins are trying desperately to correct. Without
looking at the code, my guess is this: _wp_page_template plausibly stores a
basename of the template file's name and thus triggers that PHP file to be
included and ultimately to render the page on the front-end when that file is
loaded via the convoluted logic triggered by the WP "Template Hierarchy". If
no theme file exists with that name, then WP could choke entirely. If that's
the case, then the correct place to fix the problem would be the WP core. It's
possible to smooth the problem at the plugin level, but that's no real fix and
ultimately its futile because you end up with massive amounts of additional
(and untestable) code that becomes problematic or useless if/when the
underlying WP error is fixed.
Original comment by ever...@fireproofsocks.com
on 26 Nov 2014 at 1:18
https://github.com/craftsmancoding/custom-content-type-manager/issues/3
Original comment by ever...@fireproofsocks.com
on 11 May 2015 at 5:41
Original issue reported on code.google.com by
ThomasDa...@gmail.com
on 28 Oct 2014 at 10:59