The Fundamental Issue of EditorX & Studio Editor

Hello there,

After playing around with Wix Studio Editor for a while now, I’m still surprised as to why Wix has announced an editor, that is fundamentally the same as EditorX, but with a fancier name to match their plans to launch new pricing for their platform.

I was at least expecting them to fix the issues I and many developers suffered from on EditorX before announcing the new editor. One of the major issues that made me stick with the old classic editor and ignore the new responsive editor is the gaps between elements. As we all know, not all elements should be visible on the page when it first loads, like error messages, success messages, etc., and we simply used to collapse an element, and it’s removed, but most importantly, the elements below it are shifted upwards, but that’s not the case in EditorX or the Studio Editor, even if you used a grid, and set the min-height to 0px, when you collapse the element, the space stays there, as if it’s just hidden, even the delete function, which is supposed to remove the element from the DOM, doesn’t have any effect on the space, the element just disappears from the viewport, but the space remains there.

Finally, the “Stack” feature, which I thought would be the solution to this issue. A stack, as the name implies, stacks elements on top of each other (or horizontally in Wix), which would mean if you took an element from the middle, all elements would change their location and shift downward, but noooo, Wix can create something that doesn’t work as a stack, yet name it a stack, but turns out, it’s just a way order stuff on the editor and move them around, not an actual stack.

I’m done with Wix, that’s it. For the last two years, I was trying to find a reason to stay on this platform, but I can’t work this way, I’m out.

Like you, I have been playing around with Wix Studio for a while too, since I was granted access to it a couple of weeks back.

After playing around with Wix Studio Editor for a while now, I’m still surprised as to why Wix has announced an editor, that is fundamentally the same as EditorX, but with a fancier name to match their plans to launch new pricing for their platform.

I have to disagree with you there. I think that there are at least three major differences between Wix Studio Editor and EditorX:

  1. Interactions / effects / animations.
    You have a lot more options with Wix Studio right off the bat without having to using the Dev Mode, which makes it a lot easier and faster to set up, and makes the page faster too (I’ve tested and compared this a few times.

    Interactions in Wix Studio (for containers)

Interactions in Editor X–limited to “Click” and “Hover”

  1. Wix IDE.
    You can now edit your site’s code using Wix’s own VS Code-based editor, which can be quite pleasant if you’re used to VS Code and do a lot of code modifications. However, there are pros and cons. You can no longer edit backend code directly within the website editor and have to use Wix IDE instead. Personally, I enjoyed being able to edit backend code and test it in preview mode, but maybe I’m just not used to it yet.

  2. Access to CSS.
    This is a HUGE game changer. Thanks to this new feature, you can now “fix” small issues and access tons of useful CSS properties, like setting button widths to auto, adding bottom-borders to containers, using :root to set up variants, and basically edit pretty much everything that the editor doesn’t allow.
    The big thing missing with this feature is the ability to target HTML tags, e.g. h1, h2, h3, p, a, li, etc., which would also be huge, since there is currently no way to set the default color for links.

  3. Different pricing structure with slightly cheaper lowest-tier pricing.
    Unlike with EditorX, the number of CMS items you are allowed to have with Wix Studio is now limited based on the pricing plan that you’ve selected, but the limit is still decent (around 1,500 items if I remember correctly). I don’t really think that this is an improvement since I know that a lot of Wix users with “bigger” sites are understandably unhappy about this, but at least the lowest-tier plan being slightly cheaper is somewhat good for simpler websites.

  4. There are also a few additional features in Wix Studio that I haven’t tested, like creating templates from your existing sites and creating client kits.

Wix Studio is by no means perfect though, although this is not surprising, considering it has not been released to everyone yet. So, I guess (and hope) that they are still perfecting it.

  1. So far, I have encountered numerous issues and bugs with Wix Blog, Wix IDE, and the editor itself. However, the Wix Support Team has always fixed the problems swiftly.

As we all know, not all elements should be visible on the page when it first loads, like error messages, success messages, etc., and we simply used to collapse an element, and it’s removed, but most importantly, the elements below it are shifted upwards, but that’s not the case in EditorX or the Studio Editor , even if you used a grid, and set the min-height to 0px, when you collapse the element, the space stays there, as if it’s just hidden, even the delete function, which is supposed to remove the element from the DOM, doesn’t have any effect on the space, the element just disappears from the viewport, but the space remains there.

  1. When it comes to issues that have always existed, I personally have never encountered the same “gaps between elements” issue that you had with collapsed elements—using auto and/or max-content has always fixed the problem for me.

    However, I am under the impression that there are still some bugs and will always be some. For instance, sometimes when I create a new dynamic page, I will get an error message saying that there’s a glitch, but I just need to navigate away to another page and come back for the problem to go away.

    Then, there is the fact that everytime I try to edit the mobile font size for “Rich Content” it will always go back to the default size when the site is published.

    Regardless, I think that Wix has come a long way, and they’ve got a great support team that is always swift to help when needed, so I can live with these little “bugs,” at least so far.

I have considered moving my projects to Webflow or Oxygen Builder for a while, but I’ve decided to stick with Wix for these reasons:

  1. Unlimited CMS items (with EditorX) and decent limits (with Wix Studio), which is not the case with Webflow.

  2. Wix Velo!! and the ability to install pretty much any NPM library and integrate the site with 3rd party APIs without going through any other integration APIs like Zapier, which is the case with Webflow. The ability to expose the site’s API is also a huge plus for my niche.

  3. Wix Multilingual. While it’s imperfect, I’ve found a way to make it work with dynamic pages without using WeGlot, which is mandatory if you use Webflow, and it is quite expensive!

  4. Wix Blocks! With Wix Blocks out, it’s now even harder to consider other web builders.

  5. No need to depend on plugins. To achieve the same kind of functionality using WordPress (for the travel niche), I would have to either spend time coding everything myself or use tons of different plugins, namely ACF Fields and a few more, which means more maintenance and also leads to a rather confusing backend + additional costs.

  6. Pretty much zero maintenance required and a centralized billing system (for hosting, CDN, security, etc.). Much easier to manage compared to WP sites.

I guess it comes back to what your needs are. If you want to build a simple, fast, single-language site that doesn’t require too many dynamic pages or CMS items and looks awesome with a seamless website-building experience, Webflow is worth looking into, but the moment you need something more advanced, it gets either more complicated OR expensive pretty quickly with Webflow.

Moreover, seeing how the platform has evolved so far, I have faith that the platform will continue improving! I have invested a lot of time in experimenting with both EditorX and Wix Studio so I really hope that I am right!

2 Likes

Hi! Hmmm, I haven’t seen this same issue with EditorX:

I’m currently using collapse on load (meaning collapsed as the default value) in two separate ways in EditorX: (1) with full sections that then expand on “read more” and (2) collapsed elements within stacks.

image

For both of these uses, the elements below it are still shifted up when these elements are collapsed. What works for me is ensuring that the height for the parent container (or if it’s a collapsed section, the page itself) is set to AUTO without any minimum height set. Most of my spacing issues in EditorX often have to do with minimum height/width set, especially when cascading down across viewpoints.

I hope this helps. Let me know if you need more screenshots :slight_smile:

1 Like

Just chiming in to say that collapse works as expected for me too. That being said, one of my biggest bugbear with Editor X is that there is SO MANY things you need to set to auto for your sections/containers/grids to take the height of the elements inside them.

But if there isn’t a minimum height on anything, collapsing will make it take no space.

2 Likes