Re: accessing system data in preloads

I found how I can access the theme template variables in my preload:

$icmsTheme->addMeta('meta','icms:flops', $xoopsTpl->_tpl_vars["icms_pagetitle"]);

This adds metadata type 'icms:flops' with the value of the icms_pagetitle template variable.

I'm still puzzled why this works with the xoopsTpl variable, and not with the $icmsTheme->templateVars code.


Re: accessing system data in preloads

Super, thanks for that, that plugin really comes in handy!

I'm thinking of extracting the Google analytics code from where it's now and put it into a preload as well. That would make it easier to replace with some other analytics option, as well as add special taggings to the page (such as special javascript to track downloads or other events) during rendering of the page. On my to-do-soon list, now that I'm having some knowledge of preloads


Re: accessing system data in preloads

<p>There is a <a href="" rel="external">plugin to help with preloads</a>! I wrote this a while back to help me figure out some of the same things. I like the idea - in the past, I wrote these into the theme. This would make them available, no matter what theme you used. As for when the information is available, rendering takes places in the footer (/footer.php), so all variables are set by then. In the header (startOutputInit), very few, if any, are set.</p>

Steve Twitter: @skenow Facebook: Steve Kenow

accessing system data in preloads

Hi, I'm working on a preload to dynamically add Social Media metatags to the pages you're viewing. Adding basic stuff that is the same for each page is working ok,and getting the preload to fire is ok too. WHat I can't seem to figure out is hwo to get access to the data of the current page, such as page title and the likes.

This is the code I have working in the plugins/preloads/socialmeta.php file:

class IcmsPreloadSocialmeta extends icms_preload_Item { /** * Function to be triggered at the end of the core boot process * * @return void */ function eventBeforeFooter() { global $xoopsTpl; global $icmsTheme; $icmsTheme->addMeta('meta','twitter:splut','blabla'); } }

Some questions : is the eventBeforeFooter the correct one? I was using eventStartOutputInit but was not sure if the data I am after is already in the system.

Any idea on how I can get access to the theme variables? I have access to icmsTheme, but how do I get to the variables that are passed through there, such as icms_pagetitle in the template?

I was thinking of doing something like this :

$icmsTheme->addMeta('meta','icms:metatest', $icmsTheme->templateVars['icms_pagetitle'] );

But that is always empty. Would you have any ideas?

Re: Login module - is this 2 factor authentication?

Yes it was intended to be SQRL (and maybe to serve as place to bundle other non-core authentication mechanisms).

It is not finished as I got distracted and forgot about it. I think there might be some SQRL libraries available now that might make it easier to finish.

The messy bit, if I remember rightly, was the library I was using for generating QRL codes seemed a bit slow and resource demanding (and you can't cache it). Probably there are better libraries for that now too, and putting it on a separate page (rather than in a block) would probably reduce load.

The SQRL thing is definitely worth another look, it has all sorts of applications. I might be doing something on using it to authenticate paper documents (certificates of authenticity) for a work project soon.

Login module - is this 2 factor authentication?

I was looking through the different ImpressCMS modules on Github and I stumbled upon the 'Login' module. Except for a rather generic name, it looks interesting. When I looked into what is exactly was, I had a déjà-vu of what we have now with the Google/Microsoft/other Authenticators.

@madfish is this SQRL authentication scheme related technology?

There are quite a few gems hidden in the depths of the module library, any help in uncovering them would be appreciated.

Re: Combined forum AND archive module

I for one think this would be a powerful addition to ImpressCMS : to have each and every element of content on your site identifyable with a single, unique ID.
In essence that is the way Drupal works, they call it NodeID, and I'm sure other CMS providers have a similar approach. If we extend the basic object to be identifyable by a single ID that is unique over all modules on a site, I would applaud such a development.

Re: Combined forum AND archive module

With some changes it could be. I'm working towards providing a single feed of cross-module content on one of my work sites (so it will kind of be like a blog of all kinds of different content, filterable by tag). It's always going to be messy while the data for different objects sits in different tables.

However, a shared 'object registry' table would greatly simplify the most common operations. The taglinks table in Sprockets/ImTagging are close to what's needed, as they already record object type, ID, tag etc for data across different modules.

If this table included a timestamp and an online/offline switch then it would be relatively simple to (say) retrieve the last X objects on subject Y from Z different modules, while minimising query load.

It would (slightly) complicate queries for retrieving individual items but I don't think that's a big issue, the expensive ones are the multi-object lookups. It would also make Sprockets/ImTagging compulsory rather than optional components, as the date/online fields would be moved out of the object tables.

Re: Combined forum AND archive module

@ Madf: Unfortunately the cross-module content functionality has also proved to be quite resource intensive.

Wouldn't it grow more slim with some experience?

Everything better than Wordpress

Re: Wordfence

I needed to drop out of development mode for some time with me becoming a father. It's even harder with your 2nd child I came to see, because you have the first one to keep taking care of like you always would. Even if you haven't slept much and you'd rather go back to bed

My composer developments where at the stage that I was able to replace the custom-built ImpressCMS autoloader with the standard composer one.

While that is a great accomplishment already, there is still much to be done. Possible improvements here are the removal of all the external libraries from our core, but that will mean some important rewriting on how we include and call those libraries. I managed to break the Smarty installation that way on my local machine.

I left the core for what it was, and didn't start to yank out all the existing external libraries, but chose to look at the feature with the biggest impact : module discovery and installation. I have a project on Github (composr-module-installer-plugin) that defines a composer plugin to install impresscms modules.
That all happens from the command line at the moment. Improvements there are to allow this to work from a HTML interface, and to integrate the 'oninstall' and 'onupdate' hooks into composer.

I am slowly getting back a grasp on my life, so I plan on dedicating some time to that in the near future. Thanks for the interest!

Re: Wordfence

I think we could manage it for free, although we would probably have to provide alerts for a defined range of modules (the actively maintained ones) rather than the whole universe of legacy things.

There are some potential links with module stats reporting. A 'wordfence-like' module would need to scan the site it was installed on to check what modules and versions were installed in order to see which needed updates. Either it would have to download a list of updates from an official service, or post the data off for analysis.

As "payment" for maintaining the module, it could send anonymised data to a project statistics collection service. Or not, if you turned it off.

There's also a potential link to an official module 'app store' service here (new mod version gets uploaded, submitter sets 'security update' flag, sites discover flagged updates and email their admins).

How are you going with that composer thing :D

Re: Wordfence

The first part is part of the Drupal core, and I believe we must do that as well. It's trivial to have the core send a mail to the administrator when a new important update is released.

Failed login attempts : would be a great improvement. I think tiggering events during the login process for this kind of information would be great. I think it will make the login process more flexible and easier to maintain.

It would be great to have something similar for ImpressCMS, and I would personally be prepared to pay €20/month for such a service (provided I can protect at least 5 sites with it).


There's an interesting security plugin for Wordpress I came across recently called "Wordfence".

It does quite a few things which include:

* Alerts the admin via email when an update is available for Wordpress or one of it's plugins. It will send a list of things that need to be updated on your site, and which ones are critical (ie. security sensitive - which turns out to be quite a lot, it's a bit scary).

* Monitors and reports on failed login attempts.

* Monitors and reports on attempts to recover admin passwords.

One of the reasons that people don't patch their sites is that they are busy and may not manually check to see if there are updates for long periods of time. Having alerts emailed to you automatically is quite a useful service, I think.

I don't know how it is administered, but presumably the owners of the plugin (freemium model) maintain a database of plugin versions and security issues, which the plugin checks periodically.

Re: CKEditor 4.3 preview

getting back to this after a while, I spotted a flaw in the reasoning : composer-maintained packages are handled like they are on github, with an owner and a package name.

If we use composer to handle our packages, we can't hardcode the paths to the libraries we use, because those paths are not fixed. CKEditor will not be in /vendor/ckeditor, but it could be in /vendor/ckeditor/ckeditor, or /vendor/fiammybe/ckeditor, where I might happen to have made some fixes that are useful for a specific site.

The discovery of the paths is somewhat more complex than what we had until now, and that means that we need to rely more on the creators of the classes, and no more on 'include' statements.

Re: Proposal to collect installation statistics on Gone Native modules – have your say


fiammybe wrote:
@skenow, well, we specifically target the installation of the system module at the moment, so no other module installations are notified at the moment.

It would be rather trivial to add so all modules are included, along with the particular action - install, upgrade, deactivate, uninstall

Steve Twitter: @skenow Facebook: Steve Kenow

Re: Proposal to collect installation statistics on Gone Native modules – have your say

@skenow, well, we specifically target the installation of the system module at the moment, so no other module installations are notified at the moment.

@madfish I'll send it to you in a few moments. Edit : sent!

Re: Proposal to collect installation statistics on Gone Native modules – have your say

Could I please get a copy of the backend file that catches the data? Will have a look at getting it working again / improving it if possible. Please email to simon at


Re: Podcast module development

Given that Flash is no longer supported on current mobile devices, I don't think your audience will suffer from this removal.

This said, in ImpressCMS 2.0 the installation of dependencies should be handled by composer, so the 'manual install' reason should no longer be there.

Re: Podcast module development

Just a short note to ask for some feedback - I'm thinking about removing support for JW Player from an upcoming update to the Podcast module for several reasons:

i) All mainstream browsers now support the HTML5 audio and video tags.

ii) It has to be installed separately, which is an extra hassle for people, and in principle I don't like to use external libraries etc. unless there is a good reason to do so.

iii) Adobe Flash can export directly to HTML 5 now.

As far as I can tell the only sticking point may be a loss of support for Flash, which is only really relevant to PCs as the main mobile platforms don't support it.

If there's anyone out there that still cares about Flash please let me know.

Re: Network module V1.01 beta

Cool new module, I'll definitely have a look!