Errors with pages using the _wp_page_template Custom Field

[GoogleCodeExporter]

I posted this issue in the Wordpress forum but thought that this is a better 
place. Apologies for any duplication.

What steps will reproduce the problem? (Be *specific*)
1. Install plugin, create repeatable image custom field and add to post type
2. Create posts, some with the new image custom field and some without
3. Upgrade to 4.0
4. Try to change the repeatable image custom field on the old posts
5. Create a new post with the custom field and try to add image(s)

What is the expected output?

Should be able to add images to custom field on old and new posts

What do you see instead?

Can only edit the custom field on the new post

Does the problem continue if you disable all other plugins? (plugin
conflicts cause a LOT of problems, so please isolate the problem)

Yes

Please copy and paste the system information that appears in a yellow
textarea when you click on "Report a Bug" on any CCTM admin screen (this
includes the version of the
plugin, the version of PHP, the version of MySQL, a list of other active
plugins etc.):

*SYSTEM INFO* 
------------------------ 
Plugin Version: 0.9.7.9-pl
WordPress Version: 4.0
PHP Version: 5.3.28
MySQL Version: 5.5.35
Server OS: Linux
Language: 
------------------------ 
ACTIVE PLUGINS: 
 * Ajax Event Calendar v.1.0.4 [http://wordpress.org/extend/plugins/ajax-event-calendar/]
 * Contact Form 7 v.4.0.1 [http://contactform7.com/]
 * Lock Pages v.0.2.2 [http://wordpress.org/extend/plugins/lock-pages/]
 * MCE Table Buttons v.3.2 [http://10up.com/plugins-modules/wordpress-mce-table-buttons/]
 * Resize At Upload v.1.0 [http://dev.huiz.net/2009/01/26/plugin-resize-at-upload-v1-english/]
 * Social Media Feather v.1.6.11 [http://synved.com/wordpress-social-media-feather/]
 * WP-DBManager v.2.74 [http://lesterchan.net/portfolio/programming/php/]
------------------------ 
CURRENT THEME: Enon v. 

Original issue reported on code.google.com by ThomasDa...@gmail.com on 28 Oct 2014 at 10:59

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed title: Errors with pages using the _wp_page_template Custom Field
• Changed state: InReview