I have just encountered an issue with the plugin that stops me from adding any content at all for a very specific post type. I am in need of a plugin developer who can provide me a solution.
I have a Case Studies post type which I would normally expect to be able to add content blocks to (see screenshot1) if you attempt to click any part of the Click the "Add Module" button below to start creating your layout, nothing happens at all. If you try to move any of the blocks around at all (as in switch their positions) it is non-reactive, like there is a Javascript issue breaking everything. There is a console log, which shows a PHP error which may related to the problem (Screenshot2) but we have no idea what this is, and where it's come from, as everything works perfectly fine on a regular WordPress page. I can definitely see the Console Error above doesn't exists on a regular WordPress page.
I have tried Duplicating the Flexible Group (the group I'm having the issue with) and setting it to point at the Case Studies post type again, to which it does absolutely nothing still (Screenshot 3).
I've already been Advanced Custom Fields PRO about this and they have said to go to you with the following information:
> _"The ACFML plugin is throwing a fatal_ wp is not defined _error on a classic editor post type because it is blindly attempting to execute_ wp.data.dispatch('core/notices')_. This crashes the page's JS and breaks third-party interface buttons."_
Please can someone come back to me ASAP on this and help provide a solution, or some way to update the plugin?
It looks like they are suggesting that the ACFML add-on plugin is throwing a Fatal Error would indeed cause the function to stop.
1. Can you please as a test go to Plugins-> Advanced Custom Fields Multilingual and temporarily deactivate it ... does the issue resolve? (make sure to re activate again after)
2. Go in your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to:
define('WP_DEBUG', true);
Edit your wp-config.php file and add these lines, just before it says 'stop editing here':
3. I've added this in, but new error logs are not generated when. This site is setup in the root in a sub folder called 'staging'- there is an error log of the same name already there which does not update with any new errors.
ACF explicitly said that this was an issue being causing with an incompatibility with the Classic Editor, which is what we must use.
Please can you login with these credentials and investigate the issue?
[removed]
This is a problem caused between WPML and ACF which needs a resolution.
The URL above is sending me to a 404 page, please review and let me know if we need to whitelist the IP address.
Also, if possible share the access details one more time with us via the private information box to ensure GDPR compliance.
Additionally if you could share with me the feedback you got from their team based on this "ACF explicitly said that this was an issue being causing with an incompatibility with the Classic Editor, which is what we must use." it would greatly help
Can I just confirm the above FTP details have worked at all? I understand this was only sent this morning - I just want an understanding of timeframe at the moment. Will we expect an update on this before close of play today, or tomorrow, or by the end of this week? This just means I can update the customer with something.
Just thought "Wow! 5:21am's early to be coding!" 😛 Then realised you're Timezone: America/Los_Angeles
CPTUI Drives the post types available in the backend, the plugin adds these for you.
The content of the custom post type is output in a page template. The problem is with the backend management of the content though, not the front end. Flexible Content Blocks are assigned to the Case Study post type, and that's it - this is the problem which I believe is being caused by WPML.
If you've found the issue, has there been a resolution for it? Is this a code fix? Is there anyway to resolve the issue for us via a plugin we can install, or an executable update for the plugin?
Our client is relying on this functionality for their content and is very eager to get this working.
Thanks for your continued investigation into this.
I wanted to share additional findings from the ACF support team, as they’ve now been able to isolate and replicate the issue in a controlled environment.
Importantly, their debugging process did not involve switching themes. Instead, they kept the theme consistent and focused on isolating variables within plugins and post type configuration.
Here’s a summary of their steps:
Deactivated all plugins except ACF PRO
Created a brand new post type (“Test”) using ACF (not CPTUI)
Assigned the same Flexible Content field group
Created a new post under this post type
In this clean setup, the issue disappeared entirely — no wp.data.dispatch error, and the “Add Module” button functioned correctly.
However, when using the existing “Case Studies” post type, the issue persists — even with WPML deactivated.
ACF’s conclusion is that WPML leaves behind configuration data (such as post meta or transients) tied to translated post types. This appears to continue triggering the acfml_post_edit_translation_notice script on the edit screen.
That script depends on Block Editor (Gutenberg) functionality, which is not present when using the Classic Editor. As a result, the JavaScript fails and breaks the ACF UI.
This suggests the root issue is not simply active WPML code, but residual WPML data affecting specific post types — which would also explain why:
The issue persists after deactivation
It is isolated to a specific post type
It disappears entirely when using a fresh post type
Given that ACF has been able to reproduce this behaviour independently, it seems to point to an interaction issue in how WPML handles (or cleans up) post type-related configuration.
While I understand that switching to a default theme resolves the issue in your tests, the above findings suggest that may be masking the underlying cause rather than addressing it directly.
Could you advise whether WPML stores persistent configuration (e.g. in post meta, options, or transients) for translated post types that might continue affecting the edit screen after deactivation?
Happy to provide any additional details or assist with further testing if needed.
"
I completely understand the confusion! Let me clarify exactly what I did to get the "Add Module" button to appear.
When I ran the conflict test, I didn't test on the existing "Case Studies" post type created by CPTUI. Because the error is tied to WPML trying to display a translation notice specifically on the edit screen of translated post types, I needed a completely fresh environment that WPML had no history with.
Here is exactly what I did step-by-step:
1. **Deactivated everything** except ACF PRO.
2. **Created a brand new dummy Post Type** named "Test" directly using ACF's built-in Post Types feature (bypassing CPTUI entirely).
3. **Assigned your "Flexible" field group** to this new "Test" post type.
4. **Created a new "Test" post.**
When I opened that fresh post type, the wp.data.dispatch error was completely gone, and the "Add Module" button worked perfectly.
The reason the error persists for you on "Case Studies" even when WPML is off is that WPML leaves behind some configuration meta or transients that still trigger that acfml_post_edit_translation_notice script to run on that specific edit screen. That script relies on Block Editor (Gutenberg) features that are not active on your Classic Editor screen, which crashes the JavaScript and breaks the "Add Module" button.
This further confirms the issue is rooted in how WPML interacts with your post types. Passing the technical summary I provided earlier to the WPML team is still the best path forward to get a permanent fix for your "Case Studies" post type.
Let me know if that makes sense or if you have any other questions!
"
