Re: Best open source e-commerce options?

Hi @Steve, I was wondering if your payment provider does offer tax calculations? My current knowledge only covers services that are active in Western Europe at the moment, so I don't know about US-based payment or shipping enablers.

Have you had the chance to review oledrion? I know it's old, so probably a refactoring is really necessary, but would it work for you in its current state?

Topic | Forum

Re: Remove TinyMCE from the upcoming 1.5.0

Should we wedge this in and apply the same methodology for TinyMCE?

Absolutely agree.

Topic | Forum

Re: Remove TinyMCE from the upcoming 1.5.0

I was looking at this and discovered the work we did on removing FCKeditor is not in the core. We had intended that to be in the 1.4.4 release.

It might have gotten missed - somehow I was working in your repository -

Should we wedge this in and apply the same methodology for TinyMCE?

Re: get module foldername

The constant wasn't hardcoded - it was determined as the module was loading - modules/{module directory}/icms_version.php or something early in the loading sequence. With imBlogging, the constant is defined in {imblogging directory}/include/common.php.

In icms_version.php -

$modversion = array(
    'name'=> _MI_IMBLOGGING_MD_NAME,
    'version'=> 1.1,
    'description'=> _MI_IMBLOGGING_MD_DESC,
    'author'=> "The SmartFactory",
    'credits'=> "INBOX International inc.",
    'help'=> "",
    'license'=> "GNU General Public License (GPL)",
    'official'=> 0,
    'dirname'=> basename(dirname(__FILE__)),
    'modname' => 'imblogging',


In include/common.php -

if (!defined("IMBLOGGING_DIRNAME"))        define("IMBLOGGING_DIRNAME", $modversion['dirname'] = basename(dirname(dirname(__FILE__))));

Re: get module foldername

I'll need to check out how this works in that case for iForum. It's rather old code and my first focus is to get it working on 1.5.0 without rewriting it completely.

The way you describe @skenow is not always possible, I remember from the old X days that it was sometimes possible to clone modules, and this the module needed to be aware of the folder in which it was installed. That wasn't hardcoded in a constant. Not that I think that's a good way of doing things, but I'm just saying perhaps some of that logic is also there for iForum.

Re: get module foldername

I would think that should work - I have it working like that for SimplyWiki. I have also set the module directory in the header file, which then is used to set icms::$module

Other IPF modules use some logic to determine if they are in the module

if (is_object(icms::$module) && icms::$module->getVar("dirname") == IMBLOGGING_DIRNAME) {
    // We are in the module

This puts the directory name in a constant, which is set dynamically as the module loads {module}/include/common.php

If you're in the module's preferences, you will be in the system module, technically, for most modules.

get module foldername

I'm updating iForum to be compatible with the upcoming ImpressCMS 1.5.0, and as such I need to replace the $icmsModule variable with something else. That variable is used in many cases in this way : 


When I replace it with icms::$module->getvar('dirname') the value I get back is always 'system' instead of the folder in which the iforum module resides. Any idea how I can retrieve the module folder in newer code?

Now on Mastodon

I'm not a big twitter user, but it has been impossible also for me not to get exposed to the drama coming with the acquisition by the world's richest man.

As many of the people on twitter I follow are from the PHP scene, and quite a few of them are moving to Mastodon and the fediverse (like the metaverse, but the fediverse does exist), I decided to take the plunge and create an account on

You can find me now on

Re: Best open source e-commerce options?

yeah, the only thing that shows the final price with all the taxes included is fuel - when you put gas in your car, the price on the pump includes it all.

There are online services that just do tax tracking and updating. Fortunately for us, nothing we have changes taxability based on location, only the amount changes. It isn't difficult for us to do, just trying to reduce the friction of the customer having to wait for someone to do the calculations and get back to them to finalize payments. Not the 1-click checkout people are becoming accustomed to.

Re: Best open source e-commerce options?

I think the tax thing is a perfect case to throw at a specialised web service. Not only do you have to develop the functionality, you also need to make sure you stay on top of changing legislation and such. We are seeing the same issues now in Europe, now that governments have seen the big cauldron of tax money hidden in online sales somewhere. Every country in the European Union has VAT tax, but they all apply different percentages for different types of goods.

One thing I noticed last time I was with you in the States (too long ago, we're looking into a new trip with our girls this time in the next few years), is that your shops don't show the final price, tax included. In Europe, the full price must be shown in shops (even online ones) so there are different pricing strategies : either you keep the final price the same, and countries with lower tax in essence pay more for the goods, either you vary prices depending on the rate of the country. But it's a hassle in any case.

Re: Best open source e-commerce options?

Thanks! I had forgotten about oledrion. I'll have a look at it and see what we can do with it.

You're right - I'm not looking for a catalog of even 50 items, probably more like 10 - 15 at this point. The challenge we face hear in the US is the variety of tax jurisdictions, all based on the point of delivery. That's why I was looking for something that already has tackled that aspect of things.

Re: Best open source e-commerce options?

I am now working at and what we do is create e-commerce shops based on Shopware (mostly, we also do shopify, but that's not really relevant for this case as it's PaaS and not open source).

Next to that, I am also on loan to our sister firm PHPro where I manage a fairly large magento2 website.

Both Shopware and Magento2 are monsters : Their codebase is tens of times that of ImpressCMS, and it takes more or less 9-12 months to set up a shop from start to finish with all the customisations that a customer normally requests.

Shopware 6 is the new kid on the block (Shopware 5 still runs a gazillion of sites, but wasn't API-first so it was rewritten from scratch and now SW6 has more or les 25% of the functionalites from its predecessor )

Fun fact : Shopware 5 used Smarty as templating engine.

But even with those gigantic ecosystems, in most cases we go for specialised services like to setup subscriptions for recurring revenue.

Most of the large shops that we handle use a PIM, with a very popular one being Akeneo. And anyhow, in most cases we need to do a connection with an ERP that handles product definition, description, pricing, and stock information. That connection is one of the weak spots of any project. Another one is discounts. I couldn't have imagined the creativity of retailers in inventing everytime another complex set of rules for even more discount types. Each with their own exceptions of course. And the cherry on the cake is the payment provider integration. In Europe, Adyen is frequently used, with Mollie also very popular in Belgium-the Netherlands. We've been in dicussion with Adyen for months now because some parts of their Shopware module don't work as expected.

I take it you're not looking at offering a catalog of a few thousand items online, so Magento or Shopware would be overkill. But, I have been thinking of resurrecting the oledrion module based on the knowledge I have gathered until now.

A big weakness in both Magento2 and Shopware, even with hundreds of millions of venture capital behind them : they suck at handling content htat isn't a product or a category description. Shopware has an elasticsearch running, but you can't search for keywords in 'blog' pages. The same with Magento. And several of our clients got the remark from the SEO guys and gals that there simply wasn't enough text on their product pages for Google to index, so their SEO would suffer. So blog content really is important.

So in that respect, ImpressCMS + oledrion would do a much better job

Re: Best open source e-commerce options?

And - what about recurring revenue and digital content?

Best open source e-commerce options?

I'm curious what others have tried, abandoned, really find useful - and is there a module that we can use or adapt and improve? Didn't Simon have a catalog module? What other options - OpenCart? Magento? WooCommerce?

Re: Remove TinyMCE from the upcoming 1.5.0

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

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.


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.

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.

Roadmap on github

As a temporary link, the roadmap for the next few releases can be found here : Milestones - ImpressCMS/impresscms (

This is a temporary measure, as I try to get a better integration with Github into the site, and we will need to apply the versions more rigorously to the tickets that we have. But it's a start (and every begin is difficult).

Moving translations from Transifex to Crowdin

The nice people on Crowdin have provided us with our very own server to manage our translations, and the feedback up until now is that the crowdin translation instance is easier to use, certainly for casual translators that come by once in a while for a few lines.

I have started the migration from Transifex to crowdin for all the translations in the different languages that we have, because it is a waste of time to do those translations from scratch every time. 

If you are curious, the ImpressCMS Crowdin project is available here : Impresscms · Crowdin