revolution
revolution copied to clipboard
modxcms
Think over the mechanism for installing components for MODX 3
Feature request
Summary
There is very little time left before the release (I hope), but now the process of installing / updating components in the manager is not clear.
Questions about working with components:
- In MODX 3, will I see ALL available components in the component tree or just for the 3.x branch?
- If I install a component from 2.x, will there be a message about it? Maybe there will be a label in the components grid?
- Some components work in two branches, and some do not work at all, how to find out about this before installing?
- If I upload the components in a zip/folder (for both 3.x and 2.x branches), will there be a message about different branches when installing from a zip/folder?
- What happens if I try to upgrade from a 2.x branch to a 3.x branch? How will the components behave in this case?
Perhaps the mechanism has already been thought out, but it is not yet clear how and what will work, perhaps it is worth discussing it.
You mean installing extras through the installer, right?
When releasing a version you can set the minimum and maximum version it supports, which the package provider then limits accordingly based on the installed version. There's no strict 2.x/3.x branch but setting it to a minimum of 2.8 with no max will also allow installation on 3.0, for example.
That does require developers to set the min/max version accordingly and some may no longer be actively involved to do so, but perhaps @jaygilmore @rthrash @opengeek @theboxer can discuss a process for the community to request corrections?
You mean installing extras through the installer, right?
Yes, through the installer (both packages in the repositories, and packages through a zip/folder). And the question with updating the 2.x branch to 3.x. How it will look and work in the admin panel.
I propose to make a separate repository for version 3. Relying on add-on authors to indicate compatibility with a particular version is highly unreliable. And the component statistics will be clean. Now you go into the package manager and you see packages that are 10 years old - and you understand - they are definitely compatible with MODX3 and PHP 8.1)
I think, Extras should explicitly marked as compatible with MODX3 by the developers. The package manager should then list only Extras, wich have that checkmark, by default, maybe with a switch-option or system-setting to list also all other packages, which don't have that checkmark.
I definitely agree with this issue. For an end user it is not so easy to see if a package is compatible. Recently I did a clean install of RC1 and tried to install some packages - some of them failed and then they were somewhat corrupted so I couldn't even deinstall them.
If the supported versions are set correctly, unsupported extras will not show up to download in the package manager. We really don't need a whole new repository for that, this has been a feature for many, many years.
We do need some sort of coordinated effort to encourage developers to set it correctly for their extras, and a way for the community to suggest changes where it's not correct and the original developer has vanished; even if that's just sending an email somewhere. I don't personally have the access to the repository to make those changes but would be happy to help managing such incoming reports.
I know this is old, but for those of us creating packages that will run equally well in MODX 2 and MODX 3, I hope that our packages will show up via Package Manager for MODX 3 users, as long as no maximum version is set at modx.com/extras.
Yeah that's how it works.
Closing as I don't believe any action is still required related to this issue.
I don't believe any action is still required related to this issue.
@Mark-H There is a question for this comment... For example, why can I install a package for MODX 3 if it is not supported in MODX 3, according to package requirements (see screenshot)?
p.s. This is even without taking into account the fact that you can throw zip-archives into a folder and install manually.
Oh, I was under the impression that was already filtering based on supported values.
Regardless that's something that needs to be handle server-side on MODX.com though.
@opengeek @theboxer As this requires modx.com changes, do you want this issue here open until that's addressed in the provider or in an internal tracker?
@Ruslan-Aleev This is already filtered. If you search for Batcher in MODX 3, it does not even come up. So you'll have to better describe the problem you are encountering, as I cannot reproduce it.
@opengeek Reinstalled everything from scratch using git clone. MODX 3.0.3-dev, Batcher is shown in the packages, I can both find it and install it.
Nevermind—somehow, my installation had no provider selected. How is that even possible?
You search in the wrong field, you search in the filter of installed packages, this is not an installer. You need to click "Download Extras" and enter "Batcher" in the search. Or am I misunderstanding something.
Either way, the data is indexed incorrectly in the search engine for some reason. The package shows it supports all future versions despite none of the existing versions supporting past 2.8. Seems to be some sort of anomaly with that package. But I assure you, in general, the data is filtered.
But I assure you, in general, the data is filtered.
In any case, the filtering is now working strangely. It seems to me that there are more packages in the repository that don't work with MODX 3 than they do, although I'm not sure. In general, I would only list packages where exactly the 3.x branch is listed, of course a lot of packages will hide then, but maybe this will encourage the authors to check for compatibility.
The breaks_at is set by the package author. If they set it to all future versions, it will show up. That is how it works.
I reindexed the live data, which is why batcher is now gone. Again, it seemed to be a data anomaly. Perhaps someone deleted a package version that was listed to support 3.x.
If they set it to all future versions, it will show up.
Yes, I understand. But it would be correct if the 3.x branch would completely inherit the 2.x base, but now it turns out similar to the situation with Evo / Revo (not exactly the same, but still). And, as it seems to me, it is worth showing ONLY those packages that work on 3.x. For example, I can install FastField now, but it doesn't work. And what is the point of such a repository? Install and guess if the package will work or not?
The author of FastField needs to update their package. It's a pretty simple concept.
Or if it is not maintained, it should be reported and updated by the repository maintainer, i.e. us., via support channels.
@Ruslan-Aleev Be aware that there are a lot of MODX extras. Each one has to be tested by the author(s) for MODX 3 compatibility, and test results may be misleading. For those extras that won't work in MODX 3, the author has to specify them as MODX 2-only at the extra repository. This is not likely to happen for packages that the author plans to upgrade to work in MODX 3, but hasn't yet found the time to do it. It's also not likely for packages that the author hasn't found time to test, or packages that are no longer supported but shouldn't be removed because some one else may decide to provide support for them.
The MODX core team doesn't begin to have time to test and manage all MODX extras, so the rest of us have to live with a less-than-perfect repository. If this is a serious problem for you, you might be happier with a commercial platform rather then an open-source one.
The MODX core team doesn't begin to have time to test and manage all MODX extras, so the rest of us have to live with a less-than-perfect repository.
Yes, I understand. By the way, you can make it more universal - it is to add a separate filter / category to the repository - "For MODX 3 only" and display packages that are precisely tested and have MODX 3 requirements. Those the user can install 100% working packages, and if he wants, he can turn off this filter and install any other packages (although we need to specify that the packages can work fine even if MODX 3 is not specified in the requirements).
Although perhaps no one has problems with packages at all, and I’m in vain going so deep into the question =)
Like allready posted before: https://github.com/modxcms/revolution/issues/16024#issuecomment-1029796454 Isn't it possible to
- set all Extras to not be compatible with MODX 3 by default,
- inform all developers, they have to get in action and
- set their Extras compatible for MODX 3, if they are.
Is this really that big of a problem that we need to disrupt everything to fix it?
In between step 1 and 2 not a single extra will be available in MODX 3 even if it had already been updated and marked as supported. Extras that are no longer maintained may work fine because they don't touch changed code won't be available. Extras that need testing won't be available for testing.
Batcher was glitched, but configured correctly already.
Can we not just report incorrect constraints when identified?
I'm generally with @Mark-H on this, you don't want to go changing the availability of extras that have not updated their compatibility status. That said, it would be nice to work toward a better UX in this area to make users aware of the compatibility status up front based on their currently-installed version, both for installed extras and ones being browsed to install. Ideally there would be a way that modx "corporate" could override the status; there are no doubt plenty of extras that work, but their creators have "left the building."
Anyway, I agree this is not worthy of disrupting/dropping everything to fix, but there are many details such as this that should be smoothed out if we want MODX to be a truly professional product.
