This was written in 2015 by @frankl . 2015 was early on in the BS era, well before the days of Phoenix.
In the past, and even up till now, the base code has been relatively easy to install but hard to alter - which has come at a cost. Haphazard add on development, with changes to the core code that causes conflicts, and great difficulty in theming. This results in headaches if people want to alter their osC store (and most osCommerce stores that basically all look the same).
What is the motivation for people to create and maintain add ons and themes? To make money, or contribute back to the community. For the former, it is a complete headache to provide support because if a shop owner (or developer) installs add on Y, it interferes with add on X resulting in extra coding work (plus the time it takes to find the problem!). For the latter, the amount of work involved helping out less experienced shop owners makes the whole exercise of "giving back" a tiring and thankless exercise.
Look at a program like Wordpress - easy to install, easy to maintain, easy to skin, easy to install add ons - and people are happy to code for it because they know it will just work if they adhere to the standards. osCommerce can be like that. Old time osC users need to change their thinking in this transitional process.
Where some us find it a great (and satisfying) challenge to hack the core code to get it to do what we want, we need to look at things differently. How can we add functionality without touching the core code? How can we use hooks, modules and themes to make an exciting and functional shop? We want to get to the stage where the average shop owner won't even need to know what FTP is used for! They should be able to download and install add ons and themes from an osC app store - some may be free and some may be paid. We aren't even half way there yet.
We have to let the developers get osC to that "easy" stage. We can make suggestions, test, and in general help wherever we can. The result will be a robust, easy to use eCommerce suite with many more users and stores that have a unique look and feel that will result in what we are looking for - more sales and conversions. Plus developers, add on writers and theme creators should be able to make money, adding even more creativity to the osCommerce ecosystem.
I don't remember when this post was, but very early on possibly 2015 from @CarineB
Why build a cathedral when I just need a tiny church
Have a read over a coffee. Let me know your thoughts.
I for one do not miss the "find this and replace with this, or add this after this" type of modification, and the hours spent pouring over Beyond Compare when things did not work......... Having said that it still holds a certain amount of nostalgia.....
I think Phoenix has hit the "sweet spot" Modifications are easy to install and still give flexibility to make changes if an individual customer requires them, if they like they can delve into the addon code and tailor to their requirements.
Personally I don't like the "one-click" installation of modifications such as the model being used on OSC 4 - It takes away all flexibility.
yeah ... but still we need ... for modules / admin programs ... "REQUIRED" - "PROVIDES" - "DEPENDENCIES" etc. ... otherwise automated update will stay a Fata Morgana ..... this off course applies for all parts of Phoenix ... Sounds complicated but once you established a Standard it is kind of easier .. because you allways need to comply to the Standard - for every admin program - every Action recorder - every Content Module etc.
I have allready coded it - working perfectly! With a Package Manager that establishes / checks for all the requirements ..... and updates the code (both core and user specific) on the fly ... I will not just share my solutions on the forum because I don't want to determine the way Phoenix chooses to go ... That's up to the Devs ... I have shared "my" findings with @burt Gary ....
Moreover I get more and more convinced (If the above was/is/would be avalaible in Core) Phoenix can "enforce" users to update core .... So each user is on the same Version (page ) which makes the development of Phoenix a lot easier for DEVs ... no Backwards considerations.
azpro wrote: ↑Mon Oct 05, 2026 11:24 am
Moreover I get more and more convinced (If the above was/is/would be avalaible in Core) Phoenix can "enforce" users to update core .... So each user is on the same Version (page ) which makes the development of Phoenix a lot easier for DEVs ... no Backwards considerations.
It's a great discussion point.
Anyone else have a view on what @azpro Arjan writes here ?
azpro wrote: ↑Mon Oct 05, 2026 11:24 am
Moreover I get more and more convinced (If the above was/is/would be avalaible in Core) Phoenix can "enforce" users to update core .... So each user is on the same Version (page ) which makes the development of Phoenix a lot easier for DEVs ... no Backwards considerations.
It's a great discussion point.
Anyone else have a view on what @azpro Arjan writes here ?
I'm not convinced it should be "enforced" but I agree with the general idea which is why I've been pushing to have some method of updating Phoenix so users can easily keep update to date with current versions and the community isn't as fragmented as it is today. I've been thumping this tub for a long time.
azpro wrote: ↑Mon Oct 05, 2026 11:24 am
Moreover I get more and more convinced (If the above was/is/would be avalaible in Core) Phoenix can "enforce" users to update core .... So each user is on the same Version (page ) which makes the development of Phoenix a lot easier for DEVs ... no Backwards considerations.
It's a great discussion point.
Anyone else have a view on what @azpro Arjan writes here ?
I suppose finding the balance between helping people and putting people off using a software needs finding. Forcing people to upgrade should be avoided I think, but there has to be a way of encouraging people to upgrade.
I get the staying up to date bit, and why it should be done, but not everyone want to keep something up to date if it means breaking something they have specifically coded.
Forcing upgrades is not something I'd like to do, for sure.
That sort of goes against "you use it as you like" ethos.
What I could do potentially do is EOL all the old versions.
And sunset (ie they are on their way to EOL) some versions.
EG: We consider here that v1.0.9.0 is already 2.5 years old (released March 2024)
Currently supported:
v1.1.x.x series
Sunset:
v1.0.9.x series
EOL:
v1.0.8.x series
and older.
EOL would (in simple terms) mean "use it as you like, but when problems arise you might not be able to get support from others".
Now, if we jumped to (eg) v1.2.0.0...
Currently supported:
v1.2.x.x series
Sunset:
v1.1.x.x series
EOL:
v1.0.9.x series
and older.
Something like that would establish a clear lifecycle.
And have users think more positively about taking the time to upgrade?
--
On a somewhat related side note, I don't think about backwards compatibility when writing addons. If my addons work on the latest version, that's good. If they get tested and work on others, that's good. If they dont work on some, that's also good! If dev's build in backward compat, it just makes it easier for end user to stay where they are, right?
I've just checked the User List and doing this EOL / Sunset would not affect many users at all.
I am only able to go by those users who have put the version into their profile, admittedly.
We do have a number of users on v1.0.8.21 - but that version is identical to v1.0.9.0 (other than the version.php file), see https://github.com/CE-PhoenixCart/Phoen ... ..v1.0.9.0 - All of the guys on v1.0.8.21 can just make that change to bring them up to v1.0.9 series.
After that we have a handful of users (fewer than 5) in older versions.
To reiterate, we don't know how many users on older versions, only those who have placed such info in their profile.
I'll think harder on the pro's / con's of EOL/Sunset.
I'm open to suggestions/comments etc
) which makes the development of Phoenix a lot easier for DEVs ... no Backwards considerations.