I just upgraded Cornerstone on my dev site to the latest version, and everything is now showing up as “classic”, as if all the shortcodes on thousands of my pages is up for obfuscation in the next releases.
What is your plan with this? I hate to think that my 3 year old site needs complete rework due to new implementation of cornerstone elements.
Why keep making things bloatier and bigger? Why not tighter and faster?
Hey @bluedotproductions,
No, your site won’t need rework. The old elements has just been renamed to Classic for the very reason that users won’t have to deal with new options should they choose not to. The new elements are separately added.
Our management has reached out to many users from different channels as well as getting the pulse in our forums. The changes are the result of user request for a more powerful builder.
I recommend that you keep up with our New section and participate in discussions so that your voice be heard before the updates.
Thanks.
I owe you an apology, and want the Forum readers to hear this. Lets face it, this is what happens when you’ve been coding for for 25 years and you’re a grumpy old timer.
I use a complex child theme that incorporates custom mobile menus and custom buddypress pages from Buddyboss, running a Buddypress community with over 40 plugins for it’s membership based system, etc. I just upgraded from 4.4.2 to 5.2.4, and was able to get all my issues worked out in a few hours.
The new cornerstone is faster, feels more robust, and as long as we don’t deprecate the classic features - I love the new V2 additions. Especially, being able to edit WP page settings inside of cornerstone instead of jumping back and forth.
I just hope I don’t miss any bugs…
Thank you for your kind words.
By the way for all other users that feel the V2 elements have too many options that they can achieve with simple CSS code that means the V2 elements are not for you and you will be good to go with classic elements. We will support classic element and it will be integrated into the ecosystem. Even better news, you can go to X > Cornerstone or Pro > Settings and you can choose to have both V2 and Classic elements available or one of the two:
So for the customers that prefer to use classic elements and the simple view, they can hide V2 elements altogether.
And for the customers that feel they will use only V2 elements they can hide classic ones.
We totally understand that there might be 2 completely different approaches to the builder depending on how savvy the user is.
Thank you.
I spoke to soon. One bug took me a day to trace down, and I still don’t have it fully solved. I now fear that I went with a WIX wannabee theme on a high traffic site that is my livelihood that tens of thousands of users rely on, and I’m stuck building a new theme without Themeco.
My first note was concern about “legacy elements”. But, as I tried to take my theme originally written in v3 and take the time to update to 5.2.4 that my real issues come up. One little bug became impossible to track down with the headers (wp_header is being called twice, somewhow in responsive mode for tablet and under). The old header systems have been obfuscated. The templates we used before is now told on your support forum that the new X doesn’t support them. But wait - I found a post here that had your support team tell a user to add simple header meta into a functions.php hook! That’s crazy, and not best practice.
How long are you going to support your legacy header system?
You do realize functions.php fires every time, right? And that we can turn off plugins in an extensible fashion, per page for optimization? And that simple things in headers are only called when that page is called, right? This is the bad logic that creates bloat and dependency issues.
I also found that the legacy system is so automatic, I can’t stop it. I also can’t figure out how one is supposed to write header templates for the new system without a GUI. What is the new best practice? WIX style? What if you have thousands of pages that rely on the same header and template? Edit them all individually?
It’s like Themeco is attempting to stop use of custom headers and templates, as your forum support seem to reflect that.
I didn’t invest in Theme X for a GUI. I thought it was well designed, and was popular so it would be upgraded. Now - I am seeing that I may have to jump ship when my 4.4.2 no longer works. Hope I get a year out of it, as it took 6 months to develop the site around it with about $50k in dev costs. Ouch.
I suggest your team think about extensibility in themes, not just fancy GUI’s that can only be supported by telling everyone to turn all their plugins off.
I have not experienced this in my test site even updated from older versions. This sounds like a customization issue. If you’re using a child theme, please switch to the parent theme so we know if this is a bug.
Do you mean we will support your custom templates?
The code given was just a guide. That is mostly used for adding global script to your site. It’s not a bad practice to filter wp_head. Otherwise, WordPress core would not have had allowed filtering it.
The new version is backwards compatible with the old system. For instance, if you’ve modified wp-header.php previously located in themes\x\framework\views\integrity but now in themes\x\framework\legacy\cranium\headers\views\integrity, it would still work in your child theme themes\x-child\framework\views\integrity provided that you don’t have syntax errors or conflicting scripts.
Yes. I don’t know what you’re trying to achieve with this question.
Plugins can be turned off site wide and not per page. That is the functionality WordPress provides out of the box. If you’re able to turn off a plugin per page, you’re probably using a custom script or another plugin. I’m also not getting your point in here.
Please, give us more details.
Its the same as before. Please see our Customization Best Practices.
There’s no best practice. There is only preference. If you wish to code, then you can customize using a child theme. If you want GUI, you can use the builders.
I don’t get this. Why would you edit the pages individually if they are assigned to a header. Can you give us more information?
Custom headers and templates? Do you mean support giving custom templates or development? If so, please bear in mind that custom development is not part of support ever since. We provide guidance, yes. But, it is the users responsibility to maintain the custom codes because they are not official part of the theme.
X and Pro are not only GUI based themes. It is only GUI if you use it that way. If you’re a developer, you’ll see that it is well designed and its code follows modern best practices. There are bugs, yes. But, there’s no reason it will not be ironed out.
This is only suggested for troubleshooting purposes. X and Pro and the rest of the bundled plugins are part of WordPress. It is expected that users will use third party plugins. There will be conflicts, yes. You have thousands of plugins in the repository and we could not test them all neither we could take into account the different systems will add into the WordPress system.
Thank you.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.