All Post Type Field Sets show when using default WP template (i.e. page.php)

This topic is: not resolved
Viewing 10 posts - 1 through 10 (of 10 total)
Author Posts
January 21, 2015 at 9:14 am #3601
handbuiltDave
Post count: 7

G’day Traversal,

Kudos on the plugin BTW!

I am sure there is probably a quick fix/hack for this one, and apologies if you have already answered it before (I couldn’t find a search facility for the forum).

The issue we are having is that when we exclude Post Type Field Sets from specific WP theme templates, every single Post Type Field Set shows up when you create a blank new page (which defaults to the ‘Default Template’ – i.e. page.php) – regardless whether you use the include or exclude options.

We have tried excluding these Post Type Field Sets from page.php but it doesn’t seem to work.

We have a large site going live in the next week for a major Australian brand, and we would rather our client could just create a blank new page and see only the Post Type Field Sets we intended (without having to change templates).

Any chance you could help?
Our thanks in advance.

Dave

January 21, 2015 at 9:26 am #3602
handbuiltDave
Post count: 7

Quick update:

Looks like the DB is storing the correct info for the field set.
Here’s a dump of the ‘visibility’ JSON array from …mp_field_sets:

json:{“sites”:”*”,”templates”:”site_home.php”,”post_types”:”page”}

In other words, this field set is visible to all sites, only for pages assigned with the ‘site_home.php’ theme template (which is what we want), and for posts which are designated as ‘pages’ (again, this is perfect).
Problem is – MasterPress doesn’t honour these visibility settings.

Would you agree that this sounds like a PHP error when the field set is rendered?
I assume there is an ‘if’ statement which checks the visibility of the field set against the current page settings before it renders the field set in the admin area of WP?

Traversal, I presume you will already know this info but thought it may helpful with debugging.

January 21, 2015 at 2:04 pm #3603
traversal
Post count: 207

Hmmm, yeah it certainly should be working like you’re expecting. The only thing I’m unsure of is “site_home.php” as your template. If you change the template to the name equivalent to “site_home.php” when after you create the page, does it then hide the fields which aren’t relevant?

Is site_home.php a template you’re reusing for multiple pages?

Cheers

Trav

January 22, 2015 at 10:24 pm #3604
handbuiltDave
Post count: 7

Hey Trav,

Bizarrely, when you select ‘Homepage’ in the Templates drop down in the back-end (i.e. ’site_home.php), then all other Field Sets switch off – just like you intended.
We use multiple templates that each may often be used by multiple pages.

For some reason the only template that doesn’t honour the visibility settings is page.php.
Hmmmm…. perhaps it’s something to do with the fact that page.php doesn’t have (or need) a PHP template declaration – you know that comment at the top of a custom template PHP file that tells WP that the file should show up as a template in the back end.

As you know single.php etc.. are also similar files in that they do not need the template declaration.
We don’t use them, so they too may not honour the visibility settings – does this help?
You get the feeling it’s just a small if statement somewhere.

Anyway… hope it helps.

All the best

Dave

January 23, 2015 at 3:47 pm #3605
multipliertech
Post count: 13

Hi Dave and Trav,

I seem to be having the same problem too.

Say I have 3 templates – page.php, page-one.php, page-two.php.

The field sets will display accordingly on page-one.php and page-two.php templates. Perfect.

However, if I choose the “Default template” (page.php), which has no field sets assigned to it, the page displays all the field sets that I have set for page-one.php and page-two.php.

Here’s an example.

My visibility setting of a field set for page-one.php is as follow:

1. Post types –
[selected] Include all specific post types
[ticked] Pages

2. Templates –
[selected] Include all specific templates
[ticked] page-one.php

3. Taxonomies –
[selected] Include only in specific taxonomies
[ticked] none

4. User profiles –
[selected] Include only in specific roles
[ticked] none

This field set will display correctly when I select the page-one.php template, and will not display on other templates. But it will be displayed when page.php template is selected.

If I have the same visibility settings for page-two.php. The field sets for page-one and page-two will both be displayed when page.php template is selected.

I would appreciate any help with this.

Cheers

Kat

January 25, 2015 at 3:40 pm #3607
handbuiltDave
Post count: 7

Hey Trav,

Any further forward with this one?
If you can point us roughly in the right direction file-wise then I can get my guys to have a look at that location and see if we can help out.

We just can’t spare the time to trawl through all your code to find the specific file to start working on at the moment due to lots of client work.

Hope this might help.
Thanks

Dave

January 28, 2015 at 8:38 am #3611
traversal
Post count: 207

Hi Dave and Kat.

Sorry for the lack of activity, I’ll look into this further now. It does indeed seem that when no template is selected, the visibility settings are not excluding field sets that are bound to specific templates, and they really should be. Thanks Kat for the detailed example, that’ll really help to recreate and track it down.

January 28, 2015 at 2:15 pm #3612
traversal
Post count: 207

Hey everyone, I’ve created a gist which should work around this until I prepare a better fix:

https://gist.github.com/traversal/e57d96397172ca25c088

This should trigger a change on the template select box, which should hide the fields as the page loads.

You may see the fields briefly as the page loads, which isn’t ideal. A proper fix would hide them before they have the opportunity to be shown. I can’t actually exclude the fields from being sent in the HTML completely, since the applicable fields may need to be dynamically shown / hidden as the template is changed.

Let me know if that helps.

February 2, 2015 at 6:18 pm #3615
handbuiltDave
Post count: 7

Thanks Trav,

Bizarrely (and rather worryingly) this feature started working all of a sudden.
Not sure if it was based around the number of pages we had – which doesn’t seem right – or some other factor.

Sorry I can’t give you any other info that is immediately related to the plugin as we have been focused on our project, and I just realised it was working.

Hope this helps in some small way.

March 18, 2015 at 11:15 am #3643
handbuiltDave
Post count: 7

Hey Trav,

I can confirm that the situation in my previous comment did eventually change – it stopped working as feared.
So I tried your Gist, and this seems to work a treat – so many thanks.

I’ll let you know if there are any further issues.

D

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.

Latest From the Blog

MasterPress 1.3.10 is now available

9th November 2023

MasterPress 1.3.10 is a feature and bugfix release. Workaround for fatal error introduced by changes to WordPress’ wpdb class in WordPress 6.4. Added actions to MPC files upload_field & WF image save_image functions.

Plugin Requirements

MasterPress requires a minimum of WordPress version 4.9, MySQL 5.6, and PHP version 5.6.20.

We also recommend that PHP is configured to use a memory limit of 64MB per request (128MB may be required for sites with higher complexity).

This plug-in is not compatible with the WordPress.com hosted service.

Three AM