- This topic has 28 replies, 4 voices, and was last updated 2 years, 12 months ago by
Fabien.
-
AuthorPosts
-
May 16, 2022 at 1:09 pm #2221653
Fabien
Then it makes it impossible to select in Display Rules. I believe this should be fixed 😉
May 16, 2022 at 7:53 pm #2221871Tom
Lead DeveloperLead DeveloperHi there,
Just to confirm:
1. The post type does not have archives you can view on the frontend
2. The taxonomy (attached to that post type) does have archives you can view on the frontend
3. The post type does not show in Display Rules
4. The taxonomy does not show in Display RulesIs that correct?
Thanks!
July 19, 2022 at 5:37 am #2287210Fabien
Hi @Tom,
Sorry just saw your reply now.
Find my answers below :
1. The post type does not have archives you can view on the frontend
True
2. The taxonomy (attached to that post type) does have archives you can view on the frontend
True, terms archives
3. The post type does not show in Display Rules
The post type (single view) shows in Display Rules. Which is a “normal” behaviour, then you can target the single template, but not the archive template (again, all normal here).
4. The taxonomy does not show in Display Rules
Here comes the issue. When the CPT archive is set to false, in display rules, you only have the option to select taxonomy terms 1 by 1. Example 1 in private information.
In order to target all terms, you need to have the CPT archive set to true. Example 2 in private info
To summarize: CPT archive (true or false) shouldn’t impact taxonomy archive. But it does.
Hope it’s clear.
July 21, 2022 at 5:58 am #2289464Fabien
July 21, 2022 at 6:02 am #2289469David
StaffCustomer SupportHi there,
Tom is out the office today and tomorrow. I can see its on his issues list, so he we will able to review early next week.
Sorry for the delayJuly 21, 2022 at 6:03 am #2289472Fabien
No worries. Thanks @David !
July 21, 2022 at 6:17 am #2289487David
StaffCustomer SupportThanks for your patience and understanding 🙂
July 28, 2022 at 3:23 am #2295904July 28, 2022 at 1:45 pm #2296617Tom
Lead DeveloperLead DeveloperSorry for the delay here – had a couple weeks of vacation.
We’re about to start reviewing the last needed tweaks/fixes for GPP 2.2.0, and I’ll make sure this issue is reviewed and fixed if possible. Certainly seems like a bug, but I’ll need to dig in a bit to confirm.
Will update this thread once I have more information.
Thanks!
August 25, 2022 at 7:25 pm #2324113Tom
Lead DeveloperLead DeveloperHi there,
Been playing with this trying to find a solution for 2.2.0.
The current functionality is intended – it works this way with all other post types as well.
In order to display an Element within an archive (showing all posts with a specific taxonomy term), the post type needs an archive. This is just the way the Display Rules feature has its logic, unfortunately. We could remove that check, but it will introduce a whole new set of bugs/inconsistencies.
One alternative is to set
has_archivetotrueand just 301 redirect the actual archive pages.I’m going to leave this open in our private GitHub in case we can figure out some sort of solution. Perhaps a way to filter in post type names to allow even if they don’t have an archive. Something like this:
add_filter( 'generate_elements_allowed_archives', function( $archives ) { $archives[] = 'your-post-type'; return $archives; } );March 15, 2023 at 8:39 am #2568755Fabien
Hi @Tom,
Any news on this ?
Again what I am trying to target is a taxonomy archive page where the post type attached to this taxonomy has_archive is false.
It is defintaly feasible (without custom code) with Beaver Builder / Themer for example. I don’t see why it wouldn’t be possible with GP/GB. Having a custom tax attached to a CPT without archive is not a “specific” case.
Happy to discuss live / show you the example with BB.
Thanks,
Fabien
March 16, 2023 at 8:14 am #2570097Fabien
Any news ?
March 17, 2023 at 7:45 pm #2571759Tom
Lead DeveloperLead DeveloperHi there,
No update on this, unfortunately. I’d like to fix it without any code, but we’re unable to do that without possible breakages, which is why we’ve stalled on a solution.
I’ve milestoned this for 2.4.0 (as we’re able to release 2.3.0 on Tuesday).
We’ll release a (hopefully no-code-needed) solution in that version.
Thanks for your patience!
March 20, 2023 at 1:31 am #2573728Fabien
Ok, great. Thanks @Tom, looking forward to the release.
Fabien
-
AuthorPosts
- You must be logged in to reply to this topic.