yes thats true those three points are seldom to find and community and response effort is awesome, this is the reason we are here. but some base stuff is or hopefully soon was not stable enough for some productive workload, some stuff derive from Gutenberg Bugs and WP Shortcomings that was true either, some many from our rookiness but some are there and at the end while you already have procedures to work you must decide if something truly works or not in the actual state, i also think and beliefe cwicly will fit into this in about an year or so.
Would love to see some of these complex websites!
I’ll pm you a few links
thanx hopscotch…i compared the navigator of tabular email with taht one in the different wordpress site editors not the use-case or output itself. for tabular: it is asfaik the only mailing tool which shows working mobile and desktop and tablet viewports which truly work.
of course i really am happy with the roadmap here, the people, the crew who really is absolute amazing in itself and even much more amazing if compared to other site editors and vendors that is really great.
but some stuff in my view is not working proper or efficient enough. the sytem itself is very speedy and fast. but some core bugs must be adressed already in my opinion. before pushing special effects and other stuff.
but of course many shortcomings are from me and also from gutenberg which is not easy to see in first site which one is causing it that is true.
I don’t think these types of musings helps anyone.
“I am not going to do this, and I am not going to do that” - Who cares!
There must be actionable items in the feedback - Consider this or consider that…
If you implement this feature or fix that bug then Cwicly will get better, and so on.
There is no actionable item in your musing.
I wrote down something similar along those lines the other day. And I pretty much agree with your POV!
A feature freeze and 100% dedication to bugs and documentation would be the best move to keep quality and trust high. My suggestion in the other topic would be to introduce a beta channel where new features can be tested without sacrificing the current stable build.
Or even better: modularize new functionality and sideload it in the form of addons/plugins. Just like the gutenberg plugin concept or extensions for other WP plugins
This strategy was used by the Cwicly team for v1.3 to introduce the Components features.
The biggest issue at that time was ensuring synchronisation between the release channel and the beta channel, otherwise it is harder to switch between them to test out features.
I think a beta channel can work well as long as the iterations are on the shorter side and/or any bug fixes and enhancements from the release channel are kept in sync.
This is an interesting one. I have seen many very good plugins switch to modularisation using multiple separate add-ons and then switch back to a single “Pro” plugin for various reasons.
In theory having separate modular add-ons can be good to keep the file size lower and only include what is needed. On the other hand, it does require additional maintenance, keeping everything in sync and can lead to some duplication for each plugin.
On hosts like SiteGround which has “Inode” restrictions, the number of files can also be more of a significant factor than the size of the files.
I think a reasonable compromise initially may be to make each release go through a short beta stage. This would increase the time to get each release out but would likely catch many bugs / conflicts before they can affect a lot of users.
from the looks of it, because it’s toggable in the settings, Tailwind as a major feature is already being thought of as a module. Good example of what I was referring to. Not quite sure what you mean with duplication though.
Can’t really see that argument, because the bottom line is having feature A with it’s codebase being implemented as part of the big package VS standalone. Those 5 extra files don’t appear as such a big problem on hosts like SiteGround.
Plus I was thinking, that additional “major” features could be maintained in a seperate plugin until it reaches stable status and is ripe to be integrated into the main branch. Again, just like they do with the Gutenberg Plugin.
How should this beta stage looks in practice and how does it differ from the status quo?
Ik zie je post nu pas. Wat mooi dat je dit zo beschrijft.
Cwicly is inderdaad geweldig maar we lopen soms nog wel tegen wat issues aan.
Ik gebruik het nu altijd, al heb ik weinig grote projecten.
There can be many duplications required, one common example would be license checking code, which would need to be present in each add-on, if it is a separate installable plugin.
I’m not sure what you are basing 5 files on, but I am inferring there could be significantly more overhead than this.
A temporary additional feature plugin may work well, as it would eliminate any synchronisation issues. This may work for a completely standalone feature, obviously wouldn’t necessarily work as well for something that modifies or enhances an existing feature.
Beta releases could have a separate channel and users could opt-in to install them. After an agreed time frame, any feedback or bug reports can be incorporated and then this can be released into the main release channel. In the case where there are no bug reports or feedback reports, the release could be directly moved over to the release channel.
Maintaining two separate builds of the same plugin and making sure everything works correctly on both, including dependencies, hierarchy, and iteration is not a trivial thing, especially when you have a small team. It adds overhead and complications that might not be worth it, or simply might hurt the entire release process, including fixing the bugs you might want to be fixed earlier rather than later. Not to mention customer support, and the communication hiccups that may occur. It means doing everything twice, including taking twice the time it would take to release bug fixes. It’s more common on these scenarios to have a reduced quality in overall code, potentially leading to more bugs over time.
The idea seems lovely on the paper, but implementing it might not be as simple as one would think it is.
Ok I get the point. From the developers perspective it’s not easy to do. But from a clients view, it’s important to have stable and reliable software though. I’m not talking minor bugs, rather breaking changes.
Let’s set aside the Beta/LTS channel idea.
What do you think of the idea to release big new features (like Tailwind) as separate Plugins? And potentially introducing a Cwicly API to piggy back on?
Big releases like TW should be perfectly integrated in the whole system. I hardly see how it can be a separate extension. Also I tend to dislike smaller extensions for a main extension. With that it’s easy to have edge cases with one version of the plugin is not compatible with another one. Or they should be 100% independent.
In short having only one plugin is in my eye the assurance that everything should work together nicely. This doesn’t block any “quick patch” on the main branch of the project.
Hi, maybe two update possebilleties?
Stable and Latest?
The emphasis is on “should” here. The reality tells another story though: With the introduction of Tailwind, people got aware that it’s possible to set mobile first breakpoints. Me included. I expected to be able to flip the approached as I please, based on the dynamic nature Cwicly brings to the table. Including the help text
"Make sure to regenerate your block CSS and Global Class CSS after modifying breakpoints."
Sadly this is, just not yet, the case. So we are left with taking the red or the blue pill. All in for Tailwind/mobile first (probably starting all over) or staying with the prior way of working with Cwicly and missing out a bunch of opportunities.
And in both cases breaking changes are introduced to at least one block, the most important one: the Nav Block and it’s decendants. It’s impossible to style it correctly with Tailwind classes and the former Cwicly way is broken, because presets don’t work.
I filed a bug already:
This is super frustrating to me and I just wanted to express my thoughts on a more safe approach to handle updates or new big features. While I see and have an utterly positive picture of Cwicly, this particular way of handling updates and QA raises questions.
I feel you. It should be really frustrating. Tailwind integration is a HUGE change indeed. Hopefully, everything will get sorted asap.
I couldn’t say it better, I share exactly the same thoughts about TW or updates like that. and there was not appropriate warning about it.
I still think complicating things won’t make fixing others faster.
It’s just going to take more time, because now you have extra plugins to compile, and extra tasks to do. Then you have to handle compatibility, and user support, and infra.
I understand your concern and that your goal is to raise awareness about issues you think are important. You probably feel that Cwicly is not prioritizing your concerns. But I don’t think this is the best approach.
We’ll have to be patient.
I am patient, but I was thinking constructively about ways how the Cwicly team may deal with new features that can introduce bugs in the future. And it seems I’m not alone here.
So I’m curious to hear some constructive ideas from an Elementor Dev Community Manager like you, @zeinnicholas. You probably have some experience and insights in this matter. How to deal with breaking changes?
please understand that I’m not here to unconditionally refute or invalidate your opinions or points of view, I’m just trying to share my personal ones. I’m here representing myself, and my own points of view only. If for any reason you felt oppressed or offended I apologize.
Even when I’m extremely familiarized with the term “Separation of concerns”, as a Graphic Designer with experience in software development I do understand that usually things are not as simple as they might look. There are many pieces of a big puzzle that need to all fall in place at the right time, in the right way, and most of the time taking the long route is the best option when you take into account the big picture.
Moreover, working on specific new features never means setting aside the maintenance or improvement of existing ones. It just means they get priority on release based on a myriad of reasons that only make sense when you know the whole project. Sometimes working on these features means opening opportunities to not only fix existing bugs, but also improve the infrastructure to prevent them from returning, or to allow improving them further, and adding new features in the future. In other words, just because there is work being done on something, it doesn’t mean other things get abandoned. Not to mention sometimes fixing a bug means more than simply changing a couple of lines of code, but actually requiring refactoring that may affect a lot of other components, and therefore needing more time to make it right.
The idea of making everything optional is really something we all look for, because it’s easy for us. But to do that it means adding a lot of complexity that in the long run may actually hurt us instead of benefitting us. It’s also very true that most of the time there are simply too many things that are out of the dev’s control, and require more time to be handled (like dependency bugs, or conflicts with other software). While it would be great to have this separation, it means adding complexity to something that is working well already, which translates to more time to develop, maintain, and support. Time that could be spent on actually working on fixing the things that are broken, and/or adding new features.
To summarize, thinking about what @Xonbu.com asked:
Adding more complexity to the whole project might actually cause more damage and delays than having a single point of truth to deal with.
But this is just my opinion.