I've been working on Protector and have it updated to work with PHP7 - installation works and it is activated if the permissions are correct on /plugins/preloads/.
Similarly, a new release of SimplyWiki is in the final stages of testing, and working in ImpressCMS 1.3+
as a matter of fact, I have the base theme template working, so the admin control panel renders in the new system. It's the system module that I have issues with because at the moment I have this kind of Frankenstein combination of a mobile-first responsive shell, and a nineties-inspired table-based interior.
There are 2 theme selectors - 1 for the user side and 1 for the admin side. To skin the admin area, have a look at libraries/icms/view/theme/Factory.php and the method getAdminThemesList(). There is where the override is set for the admin area. The core looks for the overrides in either modules/system/themes/ or themes/<your theme>/theme_admin.html
I'm working on a new admin theme that should be clean and very light based on bulma (https://bulma.io). I was hoping to include it with ImpressCMS 1.4 as a responsive, modern alternative admin theme.
I have the admin section itself working more or less (always a few details that crop up from time to time) but I seem to hit a blank when I adapt the template files for the different pages in the system module. When I change the template files in the module itself, I get the results I want, but when I update the correct files in the theme (like I do with all other template files), nothing happens. Is the 1.4 system module not ready to be skinned by a theme?
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.
for ImpressCMS 1.4, the second alpha release should be feature complete, we're just waiting for the transformation of the protector module in order to start with beta releases. That means that it is possible in the meantime to begin testing the compatibility of existing modules with this new version of ImpressCMS and PHP.
Modules that I will be checking in the next few days :
Feel free to add test results of other modules to this thread.
This is good! I also have been learning the internet marketing basics so that can manage my website’s promotional work on my own. Since I have been learning these techniques, I am relying solely on business sms marketing method. Must admit that the results are epic with it!
The link in the first post isn't correct anymore. It's now updated to the correct one. There are many services like Woorank that offer insight in your site with actionable information to improve SEO, but they're Belgian so I thought I should mention some countrymen of mine.
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.
I made 2 pull requests for these changes :
Thank you for the info! Do not hesitate to make a github account and propose changes like this yourself diretly via Pull Request.