During the period that 1.4 is being finalised, I came across the Bulma CSS framework and i wanted to try it to see if it would be a good fit to develop a new, more modern, admin theme. The work is not yet done, but during that initial search I identified that in fact most of hte templates for the ACP part of the system module simply didn't work. It is possible to change the general appearance of your ACP with a theme_admin.html file, but the specific contents of the different ACP screens are locked.
The reasons were two-fold :
As a result, there are 2 PR in the 1.4.0 beta release that fix this : I changed the location and the name of the templates in the system module, in such a way that all the templates, ACP or user side, all live in the same folder. I also adapted the code to reference the theme template.
During that work, I came to realise that there are still some parts of the system module ACP that are hard-coding HTML (and some ugly HTML constructions, at that). I'm currently trying to refactor the avatar section into clean code and a separate template. That shouldn't keep a new version from being published, because it will not introduce new functionalities or fix bugs, but it's a small step in cleaning up the system module.
I just returned from Laracon EU in Amsterdam after 2 days of inspirational talks and exchanges with members from the Laravel community. Several talks in the unconference caught my attention: How did they organize in Github to manage ideas, development and bugs, and another one was about how to take on a legacy program and move it over to Laravel.
Although one of my projects in the near future will be to work on a laravel-based instance of ImpressCMS, something more directly actionable came from the talk by fellow-countryman Dries Vints, who works at Laravel. In order to keep focused, they have an entry repository in Github where ideas are posted, and where discussion around those ideas is done. From time to time, they go over these ideas and decide to implement some of them.
That means that their base repository only contains tickets that are ready to be worked on, and the list isn't 'polluted' by wild discussions that go nowhere.
As a result, I created a new repository this morning for ideas (https://www.github.com/impresscms/ideas/issues), and I am currently transferring as many tickets that aren't yet fully worked out towards that repository.
In my previous post, I was too optimistic about what needed to be done in order to get ImpressCMS 1.4 finished for global consumption. Because we want to be compatible with as many PHP 7 versions as possible, some PHP libraries will need to be updated as well.
One of the libraries that has been particularly problematic every time we touched it, is Smarty. We're still using Smarty 2, but the implementation we inherited from previous ImpressCMS versions is very much intertwined with the core. Combine that with the fact that a problem in Smarty usually takes us to a totally blank screen, and you have a hard to debug library upgrade on your hands.
Combined with holiday and heatwave periods, pace has been slow for now. I expect this to continue a for another few weeks, but I will try to finalise some tasks every few days.
I've had some interference by Life (tm) recently : either it was scorching hot, which didn't really tempt me to sit in front of a computer and sweat just because of the temperature, either we were having heat thunderstorms, and I was battling a leak in our roof. all of those aren't conductive to development sadly
That period seems to be over now (the leak is fixed, and the sun seems to be burning elsewhere), so now I can start finishing the 1.4 release.
As a matter of fact, the only thing that still needs to be done (and that is holding up that release of course) is the update procedure. The 1.4 release removes the banners functionality in the core, and replaces it with the banners module. That is a migration script that needs to be tested.
We're celebrating Pentecost tomorrow, and that means that we have a holiday on monday. Normally, I should have the 1.4.0 beta release out by monday evening to test the migration routine.
Not much progress on the composer integration until now. I really want to get this up and running, but composer is not easy to understand nor to debug.
Thank you for the confirmation! As it happens more with bugs that don't appear al the time to everybody, it was difficult to find out where the issue was, and during the iterations where we tried to fix the bug, we weren't 100% sure that it was well and truly squashed.
Given that you consistently had the problem, and you confirm now that it no longer affects you, I'm more confident that the bug is gone.
yeah... probably that is so called.
Interesting point, in a way we would use events to do some kind of observer pattern, am I correct?
Probably if we could fix our events system we could make modules do stuff that we trying todo with plugins. F.e. module that can use sitemap functionality could trigger some events that could be handled by sitemap module. If there are no such module, these events will be ignored.
in all ImpressCMS versions until now, (1.4) we are basing ourselves on the file location to determine whether a folder contains a module, a theme, a translation or a plugin. Autoloading and composer have allowed us to look into changing that concept a bit.
With composer, it is perfectly possible to change from one library to a fork, while keeping the same development interface. All packages are bundled under the 'vendor' folder now, without indication what type of library they are.
In the case mentioned above, it could be that that fork is more actively maintained, or contains specific code that didn't make it into the main library. Moving to another maintainer of the library makes that the file location of your library will change under 'vendor'. Fortunately, autoloader takes care of the discovery aspect for you : you just tell it that you need class X, and the autoloader matches that with the file that needs to be loaded to make class X available, without you needing to knpw the name of the file on beforehand.
If we take the same concept and apply it to modules, themes and plugins, ImpressCMS still looks in specific locations for certain addon types. we look for modules by reading the icms_info.php files in the subfolders of the 'modules' folder, we look for themes by checking if there is a theme.html in te subfolders of 'themes', and so on for translations and editors.
One place where this is problematic, is with plugins. For example, the sitemap module has plugins for a long list of external modules, to help it understand the content of those other modules, and construct a correct sitemap from them. At the moment, those plugins are bundled with the sitemap module, and they are stored in a subfolder of the sitemap module folder.
That poses a problem if we want to add a plugin for the sitemap module from another module without resorting to copying files from one location to another, or having specific 'registration' routines. Here, the PHP Reflection API comes to our rescue. It allows us to scan all the classes in the system, and identify the class interconnexions. Which class is a subclass of ipf_module, for example, and which class is a subclass of ipf_module_sitemap. Have a look at StackOverflow for an example.
Perhaps this is worth looking into for future versions, to make management of the different addons and other packages easier and decoupled from the file system.
Easter holidays, so work has been a bit more slow. I did manage to finish the German translation in transifex this evening, I'll upload a complete translation pack tomorrow.
I did start to rework my solution to plugin to the composer library, but I got lost in the complexity of what I'm trying to get. I think I'm aiming too high, certainly for a first version Work continues on that, because it is one of the remaining new funtionalities that needs to go in before we can start looking into producing beta versions of the 2.0 branch - feature complete, but perhaps more bugfixing needed. My new approach is to let the design patterns on the side for the moment, and just get something working first. We can refactor the hell out of it afterwards.
Because nobody understood why we work in the 'retro' branch, and because those reasons date way back, Mekdrop has taken on the task of migrating our working branch for ImpressCMS 2.0 to the 'master' branch.
I've installed the Chromium-based Edge browser on my machine, and it works like a charm. I know people will look at me sideways when I say that I didn't have any problem with the Edge that was included in Windows 10, I'm generally not such a plugin user so their initial lack didn't pose a problem to me. The chromium-based Edge feels faster and more responsive, and it remains very much Edge. The fact that there's a Google-sponsored Chromium engine underneath hasn't changed that much.
I mention this because I tested our site (of course) with Chromium Edge, and noticed that Edge now also suffers from ticket #100 in ImpressCMS 1.3. Time to get that sorted out.
David L asked how he could test out or current state of ImpressCMS 2.0, and it turns out that the documentation for that is severely lacking and/or out-of-date. I've given him a short roadmap on how to get a ImpressCMS 2.0 alpha 7 site up and running on his shared hosting, but it's time I wrote some documentation.
I discovered this morning when I was on the train going to Brussels that my work on the composer integration was more or less useless because I was re-inventing the wheel. Composer has a class 'installer' that takes care of most things for me.
I'm looking into resurrecting the API documentation for 1.3 and 2.0, and I've looked into Fabien Potencier's SAMI to do so. I know, it's been discontinued, but I still have to find a tool that allows me to do a command-line crawl directly in my Github repository. I have some issues with git telling me that my repository is not clean in the 1.3 branches, so I'll need to do some spring cleaning before that can be published.
I'm starting this thread to give you an idea about what I'm currently working on, without needing to fire up another module or another external service to do so. No guarantees about the frequency though.
No guarantees about the content either, except that it will be ImpressCMS-related, but I might ot limit my contributions here to pure development aspects.
I'm just testing the stuff to see if I can get another error that kicks in on the forums. I hope it doesn't, that will mean I've fixed the case for the version that we are using on the site.
Perhaps later we'll see into rewriting the forum module more thoroughly.
Visibly the fix wasn't working as I thought. It's a difficult fix because the problems isn't there the entire time
When you look at the error message, there is an error in the SQL because one of the keys in the object seems to give a totally nonexistent value. I tried to fix it now in the old Art framework, but I'm not sure if my fix is working ok. Let's test
I looked around, and stumbled upon this page : https://bitsofco.de/async-vs-defer/ where the author explains a bit what the different options are, and when you can use what.
In the end, lesser files to download, even if they are bigger, is also an optimization. So you could also consider using tools like webpack, to reduce the size and the number of files you include in your page as an extra optimisation.