Development Discussions

Re: Remove TinyMCE from the upcoming 1.5.0

TinyMCE has been removed in the upcoming ImpressCMS 1.5.0 in PR #1273.

Topic


Re: Working on ImpressCMS - micro-blog

Work on ImpressCMS 1.5.0 is advancing, with 2 major cleanups this last week : we got rid of a decidedly ancient version of TinyMCE, and we sunset the old OpenID login system.

Bye bye TinyMCE

The removal of TinyMCE looks important, because it removed hundreds of files from the repository (yay), but in essence it was fairly self-contained within its own folder. We decided to remove it primarily because it was really old, and nobody has stepped up to propose an update to a newer version. That old version represented also a security risk because it was no longer supported with security updates.

While we removed TinyMCE from the core at this time, that doesn't mean a recent version can't be added as an addon. It would definitely be a welcome addition to the addons list, and give site owners more choices in which type of editor they want on their site.

OpenID

If removing TinyMCE was fairly simple, OpenID was a totally different affair. The tightly coupled way in which OpenID had been integrated at the time meant that all the places in the code that access the user needed to be checked and adapted. That also meant quite a few tests needed to be done to make sure everything kept working. For instance, the first iteration of the Pull Request totally broke the creation of a new user, something you definitely want to avoid when running a live site.

We removed support for the very first OpenID protocol. Because of some terrible naming decisions a few years ago, there can be confusion between OpenID (which we removed for 1.5.0) and OpenID Connect, which is part of the OAuth 2. At the moment, ImpressCMS does not support OAuth.

What's next

1.5.0 will support PHP versions starting with PHP 7.4. those restrictions still need to be enforced. Next to that, we will introduce support for MySQL 8, which introduced new reserved words that can clash with column names in SQL when they are not quoted properly. PHP 8.0 support could be feasible as well.

When will 1.5.0 be out?

The plan is to have 1.5.0 out by the end of september 2022.

Topic


Return to the forums

It has been very quiet on the forums these last months/years. The main reason for that was because of the rising use of Slack by the development team. In the beginning, Slack giving us realtime chat capabilities was very much appreciated, but after a while the novelty of that became less and we used it more and more as a forum, but (sadly) a forum within the walled garden of Slack.

If you are a Slack user (there are quite a few around it seems) you will have received the notification that the free version of Slack will only let you keep the last 90 days of posts, which we find too restrictive. We started looking out for alternatives again.

It turns out that our good old forums were one of those alternatives, but only if they receive a major overhaul and become more realtime-oriented. The technical overhaul was something I have been considering on and off a few times now, so that was good news. I'm currently working on rewriting iForum based on the latest IPF framework, and you can expect quite regular updates on that.

That also means that these forums will start picking up in activity, which is always a good thing . Feel free to submit your questions, frustrations, offers for help or other things you would like to share with the rest of us. We're here to help and listen.



Remove TinyMCE from the upcoming 1.5.0

Currently no-one in the development team is using TinyMCE on their servers (we're more partial to CKEditor), and we need to do a major version update of TinyMCE because of a security issue in the editor.

If there is no-one that can assist with testing the newer version of TinyMCE, that editor will be removed from the core starting with ImpressCMS 1.5.0.



Re: Where does the core inject all this javascript?

From a new post in an old topic - https://www.impresscms.org/modules/iforum/viewtopic.php?post_id=50656#forumpost50656

Wondering about the options below



Re: Where does the core inject all this javascript?

As a side note, this thread does not show paragraph tags when I post something new. Strange



Re: Where does the core inject all this javascript?

Those issues are the same ones that I encountered during my tests. After that, I was investigating webpack, and there you can include files with a specific directive, and it tells webpack to make it a relative path.

Perhaps this kind of functionality should be left to the front-end developers and not taken on by the CMS?



Re: Where does the core inject all this javascript?

There are minify and combine functions in the core - and currently left unused. Mostly because the resulting file was placed in the cache/ folder and at least one of the js and css files had some specific paths that didn't work when the file was in a different location.



Re: Where does the core inject all this javascript?

I found the locations in the header file where all the different files were loaded, and I included a switch statement so that I can switch the way includes are done by simply defining a boolean in the theme. When the boolean is true, I include a file 'combined.js' and 'combined.css', which are combined and minified versions of the different javascript and CSS files that are included at the moment. Whent he boolean is false, the old behaviour is still there.

This reduces considerably the loading time (first time at least) of a page. I still have some small issues with the minifying, but I think I have identified the problem.



Re: Where does the core inject all this javascript?

icms_core_theme_Object does all the work, but the work to be done is defined in /header.php. Just search for ->addScript and ->addStylesheet

include/cp_functions:: icms_cp_header() creates the work for the admin area.

 



Re: Where does the core inject all this javascript?

The billboard module needs major updates and it is no longer used on the site at the moment.

I'll look into the icms_view_theme_Object, because I want to understand where the different javascript and CSS files get included in the core. I believe some of them are not needed on every page. 



Re: Where does the core inject all this javascript?

This is the question I had in the slack channel - "async deferred" can be used to move when the javascript is loaded. The actual place is during the renderMetas method of icms_view_theme_Object.

This works for most things and I have it running this way on several sites. The Billboard module does not work properly on the initial page load and renders separate images for each slide until you refresh (works sometimes)



Re: Where does the core inject all this javascript?

These comes from <{$icms_module_header}> variable in theme. Sadly, right now I think there is no way to specify place where to output this variable.



Where does the core inject all this javascript?

I'm trying to find out where the core automatically injects javascript in my page. I use Bootstrap theme, and I came to the conclusion that I have 2 jquery scripts, and a load of other scripts as well that are included automatically on my page. Google proposes to change the place on the page, in order to speed the rendering, so I would like to know where the core does that, and perhaps alter the behaviour.



Refactoring the system module templates

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.

Bummer.

The reasons were two-fold :

  • in many places, the template file was hardcoded to the one in the module, and not the one in the theme
  • where the theme template was referenced, the reference was using a path structure in the identifier, and that didn't work with the templating engine (smarty 2 at this moment still).

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.



Re: Working on ImpressCMS - micro-blog

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.



Status of 1.4

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.



update 8 june 2019

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.

ImpressCMS 1.4

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.

ImpressCMS 2

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.



Re: Forum bugfix

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.



Re: Defining modules and plugins in a composer world

yeah... probably that is so called.




 Top