Thanks for clarifying that Steve!
My situation is a bit different : my websites are standalone, and not linked to businesses at the moment. I am part of ImpressCMS in order to evolve and improve the experience by adding features, reworking existing features so they can be improved, and also removing features if they are no longer relevant for the future direction we want to go in. That last can be a difficult decision, but in those cases you need an alternative of course.
I think the way @Mekdrop and I want to evolve with ImpressCMS is not always compatible with the more-or-less status quo you desire : we already did major changes in the architecture to be able to evolve in a certain direction that will make it difficult to offer a one-click migration from an existing older site. I'll see with Mekdrop what are the best ways of doing that, but we might need a few manual steps to migrate from one module to another (something that might benefit the end-user in any case, the possibility to move data between modules).
I'm glad you want to focus your efforts on keeping the lights running with the current codebase, that means I will be able to focus a bit more on getting the next generation ready for primetime together with Mekdrop. It's really time we got that one in the wild.
Thank you both for contributing to every release of ImpressCMS! We all have a stake in continuing and moving forward.
My personal interest is continuity for sites I maintain and the businesses they support. For the most part, they aren't needing any new functionality. The sites aren't the products of these businesses. The sites provide gateways to the businesses through their content, through the search results they are earning. The primary need of these sites is continuity - their ability to exist in the change ecosphere of the web. As a site maintainer, the main thing I need is the least amount of friction in keeping the sites running.
To maintain continuity, being able to run on the currently supported versions of PHP and MySQL are the primary factors. Doing this also improves performance, another critical component of a viable website supporting an organization, a project, or a business. I can commit to this - helping updating the core and key modules to be compliant with PHP 7 and 8. I believe we can do this without changing the minimum requirements for PHP and MySQL dramatically.
When we couple this with the commitments we originally made for the next major release of ImpressCMS, we can have a major impact on our constituents. First - we did what we said we were going to do. Second - we deliver something that performs better, runs on current web servers, and displays on all types of devices. That's what keeps me up at night.
Super news! I tried changing the deprecated filter typ with a 'default' filter, but that broke everything (white page) so the solution isn't as simple as that.
I saw that a few months ago and thought it was a nice touch. It's true that the Dutch grocery stores have been coming to the Belgian market these last few years, and to be competitive in our already saturated market (and counter the difficulty in finding staff to man the checkout counters) they invested heavily in self-scan and self-checkout.
Personally (but I'm an IT guy, so I'm not really joe public) I prefer doing the self-scan (the kids love it) and the self-checkout, but I can understand that for some people, they prefer a more personal touch during their shopping.
The last 5 years we've seen that the big grocery chains with their big stores on the edge of the towns have been setting up a network of in-town small grocery shops. The independant shops can no longer compete with the buying power of the large concerns, so they let themselves be integrated in those networks. The idea is that more and more people living in towns don't have a car anymore and go around by bike. Singles don't go shopping for the next 2 weeks, they go multiple times a week to buy what they need at that time. The smaller grocery stores respond to that need.
@fiammybe I'll try to look into these issues at the end of the week.
My regular work is to provide service and support for retailers and restaurants for their point of sale systems. We also offer 'self checkout', also known as 'fastlanes'. I saw this and it brings back an era I grew up in, and even closer to what my parents and grandparents experienced. Being part Dutch, I connect with this a lot.
I'm curious what you're shopping experiences are like.
The 2 points I'm encountering while testing 1.5 currently is an issue with seemingly non-declared constants when installing under PHP 8.0, and deprecated filter types when installing under PHP 8.1 (I think I don't get to the point where the non-declared constant is used, the filter types throw me out sooner ). If those 2 points can be fixed, I think we could consider moving what is currently identified as 1.5 directly to the 2.0 release.
And, as a matter of fact, we should think of writing a new ImpressCMS compass, to identify the direction of the project and put it somewhere explicitly. We all have good ideas and the best intentions, but our efforts lack a common direction
For 1.5 I think the main issue is not removing functions from the core - because they are rarely used - but differences in the newer PHP versions.
For 2.0 also the biggest issue is upgrading templates to the newer Smarty syntax.
I hope that 2.0 will have a modules testing framework, so it will be easier to find if a module breaks with newer versions of CMS or PHP.
About that post from 2012 - what I really know is that probably we still will not have the system module rewritten fully with IPF. Sadly I don't have so much time to such big changes.
What are the intermediary steps for someone who has created or maintains a module to prepare it for compatibility with upcoming releases of the core?
Normally, modules that do not use removed or deprecated functions should continue to work as they work now. I haven't been able to test that for the moment, as I have issues setting up a 2.0 version currently.
Using 2.0 functionality is not backward compatible, and @Mekdrop was looking into adapting imBuilding so that it generates first-class citizens for ImpressCMS 2.0.
Maybe we should relabel 1.5 as 2.0 and what is in 2.0 as 3.0.
This action would take care of the number only. That version would still lack several fundamental parts that a current-day CMS is expected to provide, and that are in the 2.x branch currently. The need for 3.0 would be as pressing from the start as the need for 2.0 now Things have changed quite a bit in 10 years.
On the other hand, renumbering 2.0 to 3.0 is just a git branch rename, so it's not really a big deal, it's just version semantics at that point.
What are the intermediary steps for someone who has created or maintains a module to prepare it for compatibility with upcoming releases of the core? A module doesn't work without the core, and the core alone isn't enough to create a website. We need them to progress in parallel.
With the changes in the later releases of 1.4, and the removal of deprecated functions, files, and folders in 1.5, the original scope for 2.0 has been realized, at least based on this (and others) - Navigating ahead - ImpressCMS Compass 2012. Maybe we should relabel 1.5 as 2.0 and what is in 2.0 as 3.0.
Is the information in the debug panel enough to help get a module ready for what's next?
I also created a Fediverse (that's what it's called it seems ) account for ImpressCMS itself : @email@example.com
I split of this conversation to this new thread on the forums.
The situation you describe is sadly a universal one, and not only in open source. The way I see it, is that ImpressCMS can only take responsibility for the core and the core modules when it promises an upgrade path. We cannot take responsibility for all the other modules that are out there, whether they are still supported or not.
Your point about what it takes to make a module 2.0-compatible is a good one. I understand that Mekdrop made every effort to keep backward compatibility with the old modules, but those old modules will only offer the old ways of working. Once we have a more stable 2.0, the documentation should be made available, firstly on how to create new modules from scratch, and after that how to make existing modules compatible.
Keep in mind that we are bridging multiple gaps here : ImpressCMS 1.4 -> ImpressCMS 2.0, but also PHP 7 -> PHP 8.x. It is very well possible that modules are simply not compatible with the new PHP version, before looking at the ImpressCMS version.
We will need to do extensive tests on upgrading module versions, and define a general upgrade policy.
It would definitely be good to see 2.0 come to reality. And for us to use what we have learned for the benefit of us all. It's even better when we can incorporate what community members share with us.
One of our core promises was to provide all users with a path to upgrade. It was the foundation for the development of the deprecated messages in debug. I have yet to comprehend what it will take to make a module compatible with 2.0, or if there is an upgrade from 1.3/1.4/1.5 to 2.x. Even with that commitment, 1.2 > 1.3 was a 'start over' for some webmasters (including me). There were modules that didn't make the transition and replacements need to be found (still). 1.3 > 1.4 dropped more modules because they weren't updated by their developers and they haven't been adopted by anyone else.
As a founder and one of the developers I take responsibility for this. I am also a stakeholder and have sites that rely on what we produce. Don't get me wrong - what's been happening with 2.0 is going to be a great thing. I don't have the skills to have done any of it. I also lack the ability to explain it.
I've gone off topic for this thread - I apologize. I'll move to another topic where we can continue the conversation.
I think it's safe to say that the ticket is gone on the mean time. It will be better to create a new one for that.
I would prefer to focus this change first for 2.0,eventually later it can be back ported to 1.5.x,but it is important to give precedence to the 2.0 branch now.
Search is an area where we can improve a lot, for example by making it easy on a core level to use external search providers as well, next to the standard search
I was looking for something else and came across this post. Things have moved around a bit and I couldn't find a branch or a ticket about this. We still can benefit from this approach. I'll add a new issue in github, unless someone can find the original
That's because I just submitted it before the post
We've finished a few more shops at work in recent months, including some Shopify ones. What we learned there was that Shopify is a very capable solution, provided you can adapt your requirements to the way Shopify works. We sadly have had a customer that insisted on using Shopify, but came with loads of requirements for which we needed to force shopify to work in ways it wasn't really designed for. In the end, we got it to work, but it would have cost that particular customer a lot less if he had gone for a Shopware (or magento2) solution because that kind of platforms give you more freedom if you need it.
There was a paypal integration with oledrion at the time, but I don't think it will still work without change.
We're a bit light on tradition in our family, compared to you We've moved across the country (150 km, which is almost the other side of the country here in Belgium) from our family, so it takes some organising to keep everybody happy, and make sure we have some time for ourselves as well. Schools have Christmas holidays for 2 weeks each year, so we have to organise that period for the kids as well, in combination with our limited number of vacation days.
Normally, we go to my parents for Christmas Eve, and there we open all the gifts under the christmas tree we have for each other. You won't be surprised when I say that the vast majority is for the girls We're flexible in the timing.
Because we arrived around noon on christmas eve this year, we opened the presents then, taking into account we would leave the country 2 days later. That way, the girls had as much time to play with their newly received toys as possible.
These last few years, my parents-in-law have chosen to spend the Christmas and new year period in their appartment in La Caleta, on the gorgeous sunny island of Tenerife, and they invite us to come over for a holiday and see the fireworks. These last few years we were lucky that christmas came at the very beginning of the holidays, so we could spend almost 2 weeks there. I dare almost say this has instantly become a new family tradition. And believe it or not : the first day after we get here, we go to get a haircut, every time
Because we are always guests somewhere else, we try to suggest food that is easy to prepare, and try to help as much in the organising and the preparation the day itself. This year, on Christmas day, the journey was more important than the destination : grandpa making pizza from scratch with his granddaughters. Priceless to see the amount of fun they had, and the result was very tasty as well.
Climate wise, it's been since my teens that I can remember a white christmas. The last time we had really multiple days of snow was more than 10 years ago. This year, it even looks like we will break the record of the highest temperature ever in Belgium on the last day of the year : 16° Celcius - a nice spring day.
The first saturday of the year, the Mayor of Mechelen invites all his citizens to come together on the market plaza in the center of town, and have free drinks and free snacks to celebrate the new year. You can imagine it's a fun way to greet people also living in Mechelen you see only a few times a year, and it's very popular.