Classic elements result in "The definition for this element could not be located. You may need to activate a plugin. The type declared for this element is: undefined"

[baardarswingclub]

I have upgraded from Cornerstone 1 to 7, and now none of my elements can be edited. Cornerstone just shows “The definition for this element could not be located. You may need to activate a plugin. The type declared for this element is: undefined” for each of them.

The JS console shows: app.359de5e.js:11 Could not find element definition cs175 {id: ‘undefined’, title: ‘’, options: {…}, active: true, group: null, …}

This happens both for existing Classic elements in my page (Text for example), but also if I try to insert a new Classic element.

I have enabled all the classic elements in the Cornerstone settings/permissions.

The registration seems to happen via Cornerstone_Classic_Element_Manager::setup(), as the elements are listed in the element list in Cornerstone.

[tristup]

Hi @baardarswingclub,

There might be some different reasons behind your reason, I would like to suggest troubleshooting the following common issue to help us to recognize the reason.

1. Theme Related Issue
2. Plugin Conflict
3. Theme Update related issue
4. Child Theme Related issue **if you have activated it.
5. CSS/JS Customization
6. Disabling Cache
7. Disabling CDN

If you discover that an issue is coming from a custom code or 3rd party plugin, kindly consult with a developer or contact the plugin author. Please note that we do not provide support for custom codes and 3rd party plugins.
If that does not help, please provide login credentials for your site in a secure note to examine it further, including:

– WordPress Site URL & Login URL
– WordPress Admin username/password

To create a secure note, click the key icon underneath any of your posts.

Thanks

[baardarswingclub]

Hi and thanks for your reply. I’ve tried many of those things, none of them helping I’m afraid.

I also found another issue: I can not create new pages with Cornerstone. The Chrome console shows this:

I looked at includes/classes/Controllers/Documents.php and it registeres a route for a POST request, but then a GET request is used in practice. This seems wrong. Changing the route registration to GET seems to temporarily fix that issue, but there are other REST endpoints that have the same issue from what I can tell. Perhaps that’s what’s causing the lack of element definitions?

[baardarswingclub]

Ie this,

$this->routes->add_route('post', 'document-create', [$this, 'create']);

Should be doing a ‘get’ if that’s how it’s going to be used I suppose

[baardarswingclub]

Changing late-data and late-expanson-data to ‘get’ seems to fix the editing of classic elements.

Saving the page however fails still. The JS is doing a GET , so the registration needs to match that, but fixing that, we lack content to save, since that’s probably meant to go via POST:

Failed to save. {code: ‘tco-routing’, message: ‘Nothing requested’, data: null}

[baardarswingclub]

Correction, the broken save was due to this rule in my .htaccess:

# Ensure the URLs end in slashes
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*[^/]$ /$0/ [L,R=301,QSA]

Which resulted in the JSON POST call to https://www.winterjump.com/wp-json/themeco/data/save?_locale=user being redirected to https://www.winterjump.com/wp-json/themeco/data/save/?_locale=user, as a GET but without the POST data

[baardarswingclub]

Which seems to have also been the issue with the creation of new pages and editing of classic elements. They all work fine now, as registered ‘post’ routes.

[baardarswingclub]

Problem solved

[tristup]

Hi @baardarswingclub,

Glad to know that the problem is solved now.

Thanks