Frontend post type not showing

Resolved davidnash11
(@davidnash11)

3 years, 5 months ago

We are experiencing an unusual issue with version 0.8.9 – we are using the basic version.

When this new version is used we seem to “lose” post types on the frontend.

Going to view a custom “event” post type frontend – we are shown the homepage – the post type is “page” rather than “event” – the url in the address bar is the correct event post url not the homepage so no redirection.

If we go to the admin post types – edit any of them – then click save, the post type frontend view is now visible again.

We can see that there are changes to the pro version with regards to using /my-theme/acf-json/post-types – but would this affect the basic version ?

Anyone else had something similar?

Viewing 14 replies - 1 through 14 (of 14 total)

Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 5 months ago

Hello,

Thanks for the feedback!

Since the 0.8.9 version, the Post Type module has been reworked. What you’re describing (post type URL showing homepage instead of the post type view) looks like an issue with rewrite rules.

You can try to visit the “Settings > Permalinks” admin menu in order to regenerate rewrite rules. I would also recommend to install the Query Monitor plugin, it’s an excellent tool which will help you to get further information on what is going on on the front-end.

In all cases, upgrading to 0.8.9 should have no effect on rewrite rules. Can you please export your Event Post Type Json using the tool in the “ACF > Tools” admin page, and post it here so I can try to import and test it?

As a side note, the usage of “/my-theme/acf-json/post-types” you’ve seen in the changelog is only for the ACF Extended Pro package, so you aren’t concerned by this new feature with the Free version.

Regards.

Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 5 months ago

Hello,

Just a head up to let you know that I ran some tests upgrading from 0.8.8.11 to 0.8.9 using a Custom Post Type, and everything works correctly on my end. Here is a video of my test.

I’m waiting for your Post Type export to test it too.

Regards.
Thread Starter davidnash11
(@davidnash11)

3 years, 5 months ago
Thank you for your response.

I’m not sure it is rewrite rules – but when this happens with another site I’m working on – I will try refreshing these rules. As I said in the original post – when I clicked save on a completely unrelated post type – the event post type worked on the front end.

Below is the event post type export.
```
[
{
"name": "event",
"label": "Event Manager",
"active": true,
"description": "",
"hierarchical": true,
"supports": [
"title",
"thumbnail"
],
"taxonomies": [
"event_category"
],
"public": true,
"exclude_from_search": false,
"publicly_queryable": true,
"can_export": true,
"delete_with_user": null,
"labels": {
"singular_name": "Event",
"add_new": "Add New Event",
"add_new_item": "Add New Event",
"edit_item": "Edit Event",
"new_item": "Add New Event",
"view_item": "View Event",
"view_items": "View Events",
"search_items": "Search Events",
"all_items": "All Events"
},
"menu_position": 20,
"menu_icon": "dashicons-calendar-alt",
"show_ui": true,
"show_in_menu": true,
"show_in_nav_menus": true,
"show_in_admin_bar": true,
"has_archive": false,
"rewrite": {
"slug": "carer-support\/events-training\/event",
"with_front": false,
"feeds": true,
"pages": true
},
"capability_type": "post",
"capabilities": [],
"map_meta_cap": null,
"show_in_rest": false,
"rest_base": "",
"rest_controller_class": "WP_REST_Posts_Controller",
"acfe_archive_template": "",
"acfe_archive_ppp": 0,
"acfe_archive_orderby": null,
"acfe_archive_order": null,
"acfe_archive_meta_key": "",
"acfe_archive_meta_type": "",
"acfe_single_template": "",
"acfe_admin_archive": false,
"acfe_admin_ppp": 10,
"acfe_admin_orderby": "date",
"acfe_admin_order": "DESC",
"acfe_admin_meta_key": "",
"acfe_admin_meta_type": ""
}
]
```
Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 5 months ago
Hello!

Thanks for the details.

I couldn’t manage to reproduce the issue with your post type either. Everything works fine on my end. It seems like an edge case.

May I ask you few questions, it might help to figure it out:
- Did you do an upgrade from 0.8.8.11 to 0.8.9, then a downgrade back to 0.8.8.11, edited some settings, and upgraded again to 0.8.9, when this problem occured?
- When the problem occured, does your “Event Manager” admin menu was missing too? Or you could still edit your events normally?
- What is your WordPress version + ACF Pro version?
Thanks!
Thread Starter davidnash11
(@davidnash11)

3 years, 5 months ago

Hi Again,

Thanks for your continued support.

Just an upgrade – no downgrade. I did when I couldn’t get to the frontend post try downgrading in the second site it happened with.

The Event Manager element in the backend was still visible and editable, it was just the front end view.

The WordPress version: WordPress 6.1.1
ACF Version: Pro Version 5.12.4
Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 5 months ago
Hello,

Thanks for the details!

In this case, it’s definitely related to Rewrite Rules not being up-to-date.

For your information, if that ever happen, having your Post Type in the admin menu but urls not working on front-end (even independently from ACF Extended), then you have to visit the “Settings > Permalinks” admin menu in order to re-generate URL rewrite rules (See WP documentation). This action is safe BTW.

Question is, why up-to-date rewrite rules need to be re-generated after upgrading to the new 0.8.9 version in your case.

I’m running multiple tests since few days, going back and forth from 0.8.8.11 <> 0.8.9 with different post types configurations, and I cannot reproduce this issue. Every single time, rewrite rules are working out of the box.

I’ll continue my investigations. Few more questions, if you don’t mind:
- Can you please send me your server specifications?
  
  You’ll find these information in your “Tools > Site Health” admin menu. Under the “Info” tab (See screenshot 1), you’ll find an accordion called “Server” (See screenshot 2).
  
  I’m interested by the “Server architecture”, “Web server”, “PHP version” & “PHP SAPI” versions. So I can try to reproduce your environment, and test on it. These information are pretty common and not sensitive, so it’s fine if you share it here.
- Did you upgrade to the 0.8.9 version manually, using your WP Admin “Plugins” page, by clicking on “update” next to the plugin?
  
  Or did you use some management application in order to update the plugin at distance? Like ManageWP or something like that?
Thanks in advance.

Regards.
Stefan
(@stufu07)

3 years, 4 months ago
I also had this problem with all my websites after I updated the plugin to 0.8.9.
I was able to solve this problem by re-opening the custom post type’s settings page and saving once. I had to do this with every single Custom Post Type I had created with ACFE.

Few notes:
- Problem occurred on both Apache and Nginx servers
- PHP version was always at least 8.0
- Manually updated the plugin via WP Admin Plugins page
- Regnerating Permalinks via “Settings -> Permalinks” didn’t fix the issue.
- This reply was modified 3 years, 4 months ago by Stefan.
- This reply was modified 3 years, 4 months ago by Stefan.
- This reply was modified 3 years, 4 months ago by Stefan.
Thread Starter davidnash11
(@davidnash11)

3 years, 4 months ago

Thanks I will try rewrite rules the next time it happens.

We are using composer to push new plugin versions.

Server info:

Server architecture Linux 4.15.0-197-generic x86_64
Web server nginx/1.18.0
PHP version 8.0.20 (Supports 64bit values)
PHP SAPI fpm-fcgi
PHP max input variables 1000
PHP time limit 30
PHP memory limit 128M
PHP memory limit (only for admin screens) 256M
Max input time 60
Upload max filesize 64M
PHP post max size 64M
cURL version 7.58.0 OpenSSL/1.1.1g
Is SUHOSIN installed? No
Is the Imagick library available? Yes
Are pretty permalinks supported? Yes
Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 4 months ago
Hello,

Thanks for the details @stufu07 & @davidnash11!

It looks like your common setting is PHP 8. I just ran multiple tests between 0.8.8.11 <> 0.8.9, with PHP 8 (both Apache & Nginx), and it works fine on my end.

Here is the video of my test.

At this point, It’s really a mystery. If one of you have the time, can he try to follow the steps I did in my video, see if he can reproduce the issue?
1. Setup a clean install with ACF Pro 6.0.6 / ACFE Basic 0.8.8.11
2. Create a post type, create a post & check front-end link
3. Upgrade to 0.8.9 & check front-end link again?
Thanks in advance!

Regards.
Stefan
(@stufu07)

3 years, 4 months ago

Hi Konrad, thanks for taking the time to look into this problem. I’m afraid I won’t be able to do a test setup in the next few weeks due to some deadlines, but just thought of something else that might be helpful. I’m not entirely sure, but I think I’ve updated from version 0.8.8.7 to the latest version on some of the sites where the error occurred.

Thread Starter davidnash11
(@davidnash11)

3 years, 4 months ago

Hi Konrad – I will try the clean install at some point. Just to say that I’ve experienced it again – and I regenerated the rewrite rules as you suggested and it worked as you expected.
Stefan
(@stufu07)

3 years, 4 months ago
I just remembered that I had an older test environment (PHP 7.4) with ACFE installed. I have now quickly updated the plugin there. Here are the results:

The same problem occurred. All post types that have a single page were no longer available in the front end of the website. When you tried to open a single page of any custom post type, you were automatically redirected to the front page.

This time, however, updating the permalinks via Settings -> Permalinks helped. Saving the ACFE custom post type settings also solved the problem, but had to be done for each post type individually.

WordPress & ACFE:
- WordPress Version: 6.1.1
- Permalink structure: /%postname%/
- Is this site using HTTPS? Yes
- Is this a multisite? No
- Updated ACFE from version 0.8.8.10 to 0.8.9
Server
- Server architecture: Linux 4.19.0-22-amd64 x86_64
- Web server: Apache
- PHP version: 7.4.33 (Supports 64bit values)
- PHP SAPI: cgi-fcgi
- PHP max input variables: 1000000
- PHP time limit: 360
- PHP memory limit: 256M
- Max input time: -1
- cURL version: 7.64.0 OpenSSL/1.1.1n
- Is SUHOSIN installed? No
Database
- Extension: mysqli
- Server version: 5.7.40-1
- Client version: mysqlnd 7.4.33
I hope this helps a bit in finding the problem. Especially because I think it is a very critical bug if you have to fear that all single pages of all custom post types are no longer accessible after an update. Once you overlook the problem, you basically ruin the website.
Plugin Author Konrad Chmielewski
(@hwk-fr)

3 years, 4 months ago

Hello,

Thanks for the information guys!

@stufu07: I just ran new tests on a production server from 0.8.8.7 & 0.8.8.10 <> 0.8.9, and post types work out of the box. The test server also has a more aggressive cache method using opcache/object cache with memcache just to make sure the issue doesn’t come from here.

For your information, visiting the Post Type Edit Screen (Tools > Post Types > “My Post Type”) will regenerate rewrite rules, even without saving the post type. It works just like the Settings > Rewrite Rules admin menu. Both have the same effect.

Also note that the latest 0.8.9 version migrate Post Types settings into a new format which is more modern and allows new advanced features which will come later this year. This is why this problem should only occur this time. Upcoming updates won’t have data migration like this one, so you’ll be safe.

@davidnash11 @stufu07: Using a process of elimination, the only plausible reason would be a custom server configuration or an aggressive cache setup which get out of the touch once the plugin is updated. This is probably the reason why you’re the only users reporting this issue too.

Since server caching is a complex topic and there are so many different possible configurations, I cannot exactly reproduce your server setup that easily. So the only way for me to debug it would be to get an access to a staging environment on your server which would let me reproduce this issue consistently.

If one of you find the time to setup this staging environment, I will be happy to debug it, as I really want to know what cause this edge case! It would probably just take one hour to find the curlpit.

Please feel free to join the ACF Slack Community, I’m always connected here, and it will be easier to discuss in private for the environment access.

It’s also a great place for general ACF development support if you like ACF 🙂

Thanks again!

Regards.

Stefan
(@stufu07)

3 years, 4 months ago

Thanks for the detailed explanation, Konrad. It is nice to hear that this problem is unlikely in the future, especially as I have had no other problems with the plugin so far and i really enjoy using it for all my projects.

Perhaps a few more details that might be helpful if you want to investigate the problem further:

Some of the affected sites were hosted on Kinsta and for those it was definitely a case of having to re-save the custom post type settings page in order to get the single page working again. I’m not sure if it’s Kinsta’s caching or not, but just opening the custom post type page without saving didn’t help.

Some of the other affected sites are hosted on a default managed server from Hetzner, without custom configuration or special caching methods. If I get a chance in the next few weeks, I will prepare a test environment on the Hetzner server and send you the credentials.

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘Frontend post type not showing’ is closed to new replies.