2025/1/5 11:40:58
|
---|
|
Integration of Composer in the coreComposer is the de-facto package system for PHP. In the TNG branch, we are using it extensively, and it allows us to re-use basic code from other people, and integrate libraries with much less overhead than we have today. Also, it would free us from the quite complex code around the autoloader. Not only the autoloader itself, but the code taking care of loading classes and registering classes for modules and such. Composer could be used to handle that. I have done a proof of concept in removing the autoloader and replacing it with Composer, and that worked out allright. I've also started work on listing modules using composer functionality in the admin screen. After that, it's performing actions on those modules : installing/uninstalling/updating. |
_________________
|
2025/1/12 12:20:37
|
---|
|
Re: Integration of Composer in the coreI like this approach - adding the functionality and allowing module developers to begin the work to enable it and leverage it in their modules in advance. It will make the move to TNG much easier and smoother. |
2025/1/14 19:25:01
|
---|
|
Re: Integration of Composer in the coreI agree, that was one of the mistakes we made in our previous approach to 2.0 : we were looking for a big bang approach. This way, we can gradually introduce functionality and change without breaking too much at once On the subject of the composer integration, I have a working proof of concept for the included libraries, but if we want to leverage this for our addons, this will need more work
Let's see where I get by the time we ship ImpressCMS 2.1 |
_________________
|
2025/1/17 17:21:13
|
---|
|
Re: Integration of Composer in the coreSounds reasonable. What would be the migration path? Would composer support be added as another library like IPF was, supporting both types of modules? |
2025/1/20 2:54:33
|
---|
|
Re: Integration of Composer in the coreThe final goal should be that every dependency is managed by composer, in the vendor folder structure. If you do that, composer can manage the entire lifecycle, managing versions and also dependencies.
At that stage, we could also remove the code that supports our home-grows autoloader, which is a bonus in my view. It's quite complex code, and going for a standard approach will get that off our plates.
As a migration path, we could foresee some overlap during a few versions, and with a button that would allow you to upgrade to the composer-based version of your module. Given that creating a composer-based module (or translation, or theme, or other kind of addons) should not necessarily require code changes, it should be feasible to make that a smooth transition, just moving the module, while keeping the data intact. |
_________________
|
2025/1/21 8:20:16
|
---|
|
Re: Integration of Composer in the coreIt will take some adjustments to get used to the new mindset and I'm sure it will make more sense as we go through it. Looking at the TNG branch, I see folders for modules, themes, libraries, and plugins, which makes it easier for me (and ICMS?) to differentiate between them. I also see a 'deprecated_class_aliases' package that appears to be the path for legacy modules and libraries, even the core itself as classes are moved to new locations. My current objective is to familiarize myself with the composer architecture and methods while working on several modules that still need updates to be compatible with 2.0. These are modules I rely on heavily and have no viable substitutes. Good news is I'll be well-versed in these modules as the move to composer comes up. |
2025/1/22 8:02:43
|
---|
|
Re: Integration of Composer in the coreThe error we made in the TNG branch was to change too many things at once, and losing the overview. We did really cool stuff, but should have taken it more gradually. For example : we tried to offload all the current install logic into the composer file. That was a huge mistake. The composer file became a monster of configurations, semi-code and workarounds. The end result was that no-one really understood what was going on in there, and we arrived with a solution that made things much more complex.
I think it would be a better approach to keep the composer file as simple as possible, and perhaps review the way modules are installed.
If we want to grow ImpressCMS again, simplicity should be the action word : make it simple for users and developers to work with ImpressCMS, otherwise they will be going to another CMS in a heartbeat. Plenty of fish in that sea.
Back to composer integration : the specific folders for modules, languages and themes could certainly be an option, BUT we shouldn't rely on the physical location of files to let ImpressCMS work. For example, instead of going through all the subfolders in the modules folder and looking for a version info file, the way it is done now, we should simply ask composer to return a list with all the installed libraries of type 'impresscms-module'. That way, the system keeps running, no matter where your files are stored.
What modules are the ones that you need working on 2.0? Let's see if we can work together on them to speed these things up a bit. |
_________________
|
2025/1/25 7:35:33
|
---|
|
Re: Integration of Composer in the coreI'll put the modules I'm focused on in the thread started for prioritizing module updates for 2.0 readiness. Many of my other posts come from working with these modules. Could we start a wiki page about integrating Composer? When we started converting to IPF, I added the setDeprecated method to icms_core_Debug to give some clues as to how to migrate to the new patterns, classes, and functions, rather than leave it up to a developer to figure out what needed to be done. Looking back, it would have been great to have a list somewhere, too. There was (and still is) a spreadsheet in the project doc folder - impresscms_1.3_refactoring.ods - that has quite a few cross-references. I don't think we had 100% coverage, either in the code or in the spreadsheet. Having something like this will help keep ourselves on track and also help others pick up more quickly. Edited by skenow on 2025/1/26 6:44:29
|
2025/2/13 1:23:20
|
---|
|
Re: Integration of Composer in the coreI started a new page on the wiki that should serve as a working document for everyone : https://www.impresscms.org/modules/simplywiki/index.php?page=Refactoring I'll create a list of the things I need to do to refactor the modules and the core to be aligned with the latest way of working. Please update this page as well, so we can modernize faster and we don't re-invent the wheel separately. |
_________________
|
2025/2/17 2:13:48
|
---|
|
Re: Integration of Composer in the coreA bit delayed but here few mine cents...
Sadly, there's no easy, in user-friendly way to do that. The only real drawback of TNG is the lack of fully functional Composer module management from the web interface. It's a much bigger task than it seems - it's easy to make composer work from command line but it's not so easy from web interface. You can try but honestly I think this will be waste of time. But maybe if you think about this as some module instead core functionality this could benefit both parts... Quote:
My idea was to have a console command where you provide the path to a module using the old syntax , and it automatically converts everything into a composer.json-style module. I believe developers should minimize mechanical tasks—they already have enough challenges with module logic and ensuring compatibility with newer PHP versions.
I have to disagree. The TNG composer.json file maintains almost the same structure for data as impresscms_version.php, but in the extra config section of composer.json. There is no point in duplicating the same data across multiple files—storing it only in composer.json is much more efficient. That was the only reason for this approach. Ok, but what about older modules? They can continue using impresscms_version.php. It was even possible to use both, with composer.json taking priority as the primary data source. |
2025/2/17 2:38:41
|
---|
|
Re: Integration of Composer in the coreI'm working on a way to call the composer library from PHP code (thank you github copilot On converting modules : I don't think there will be much needed for that, simply adding a composer.json file should do the trick Concerning composer or impresscms_version.php, I agree that there should be one source of the truth for everything, but that doesn't mean it should be all in the same location. I already experimented a bit with impresscms_version files pointing to the composer.json file for some data, and that works well. But not every element from the impresscms_version file has an equivalent in the composer.json file, so for those elements, let's see what is possible and what are the pro's and cons. |
_________________
|
2025/2/17 4:14:32
|
---|
|
Re: Integration of Composer in the coreUsing Composer in PHP isn’t that difficult, but my main issue is that I still haven’t figured out how to integrate its data into our module admin and attach everything to the installer. TNG’s current method is too slow and can time out because it runs everything instantly from a PHP script. A better approach would be to show a progress bar, but since I’m so deep into Vue.js and other modern frameworks, thinking in older ways isn’t easy for me. The worst part is that I wish templating would work properly there. What to do with module admin is an even harder question for me. I think search functionality should work out of the box, similar to how WordPress handles it. But again, I’d prefer to use some JavaScript for this, yet templating is lacking in this area as well. |