No Core Changes - A different perspective

[BatteryTrader]

Hi

I am a Store Owner. While I try to fix things, I certainly am not a coder- probably not because I couldn’t be if I wanted to. I just do not have the time to learn it properly, so while I can see what's happening, I am probably more dangerous than helpful, and it's cheaper in the long run to buy those services in.

Had OSC Stores since 2.2, I expect more than 15 years.

While I would love to have never updated the website since the day I installed it, that is just not realistic for a number of reasons.

Firstly, because everyone else is, so you need to be in the race; clients' expectations change.

Secondly, because tech moves so fast- not only processor speeds but exploits too.

I have done two major revamps on my main site, from 2.2 to 2.3.4, then again to 1.1.0.1 /3, mainly because I hadn’t kept up with the updates, and the last server change was to php8 / 8.1 / 8.2 /8.3

Now these were painful; I would have loved it if there were no core changes, just the add-ons. Going to have to start thinking about going to 1.1.0.4 in time; I've been putting it off long enough. 95% of that will be with no core changes, which will make life easier.

The main selling point of Phoenix in my opinion, is speed and flexibility, I have two very close friends who both have sites, they used to have OSC, but they gave up on it and went to Shopify and Prestashop, they spend a considerably larger amount of money on renting their add-ons, cannot adapt them, they never work very well together, never do exactly what they say on the tin, slow and look crap, but they do not have to get their hands dirty, they both say thats more important, until you get them drunk.

It would be lovely if every add-on had a video, a 120-page manual, and lots of pretty pics, but that's not going to happen; add-ons are often more like ideas to build on.

The fact that I can take a basic add-on, change and adapt it exactly to how I want it to work, and then, when it's in the field, change it again depending on how customers react, is great.

In summary, websites need to be updated; customers expect it; SQL query processing has evolved for speed, so the back-end code needs to be modern and cutting-edge; server PHP minimum requirements change. So a core that does not change (or by very little) must be a plus.

But for me it's speed (have 20k products and tens of thousands customer accounts)and adaptability that clinches it; my site is not the same as everyone else’s, my requirements are not the same as everyone else's, and my customers' requirements are not the same as others either; if they was not then might as well just sell on Amazon (not a recomadation by the way, from this established prime seller), I could certainly not have the same features on an off-the-shelf Shopify website.

[ArtcoInc]

1. "No programming necessary"
Is this the same as "No coding needed".

Is "programming" and "coding" the same thing? While there probably is a dictionary definition difference ...

When I "set" my oven to cook at 350°F for 30 minutes, am I not "programming" it? When I pre-set my favorite TV channels, or enter your phone number into my cell phone, am I not "programming" them?

Every Phoenix installation needs to be "configured." Shop name, address, shipping methods, payment methods, etc. Are these configurations "programming"?

Same thing with entering products: name, part number, description, price, weight, pictures, etc. Is this "programming"?

If setting your oven is programming, than I'd say yes. Is it "coding"? I'd say No.

So No, I'd say that "no programming necessary" is not the same as "no coding necessary."


Every store owner can configure, or customize, their shop as they choose. It can be out-of-the-box, bare-bones stock. Or, the owner may mod it any way they choose. There have been threads here in the forum that demonstrate how easy it is to customize a shop with "no coding needed." I'm not challenging any of this.

My initial point was: Yes, it is a selling point that a Phoenix shop can be customized without "coding" (using the above definition). There are reasons why a shop owner may choose to not alter core code. But, arguing that it is so that "no customization will be overridden when the shop software is updated" is, in most cases, a moot point.

2. "A shop owner doesn't have to know programming (or hire a programmer). Simply upload the hooked files."
Who makes those hooked files.

My second point was that, for some shop owners, it may be faster, easier, and result in cleaner code to edit a core file than it is to write a hook. For example:

In Admin, while there is an admin/includes/stylesheet.css file, there is no user.css file. If I wanted to add some css styling to something in Admin, my choices are:

1) Add inline css code to every admin file I want changed

2) Edit the admin/includes/stylesheet.css file

3) Write (or pay someone to write) a hook to load a user.css file

4) Add one line of code to admin/includes/template_top.php to load a user.css file

Right now, I don't have the skill (nor the time to learn) to write a hook. So, for me, right now, in my shop, the best choice is #4.


But, if add-on developers were to keep with the "no core changes" philosophy, add-ons can use hooks that make it easy for shop owners to expand their shops with "no coding necessary." This is a good thing

[bonbec]

Like many of us, I also come from the osCommerce world, having been involved since 2006.
I am a moderator for the French-speaking osC forum—which is now defunct, though it did allow me to observe two distinct groups:
- A majority of store owners who wanted to update their shops only when their hosting provider stopped supporting the PHP version they were using. Nine times out of ten, they knew nothing about coding and would turn—with varying degrees of politeness—to active forum members for help.
- A minority who closely followed PHP version changes and shared the necessary modifications.

For a store owner with the time and/or money to invest in improvements, the process is relatively straightforward.
For those lacking the time and/or funds to improve their store, it is considerably more complicated. I believe this is one reason why PhoenixCart versions aren't updated regularly. And when you realize you have five or ten versions to catch up on, it becomes a disaster—especially if you aren't aware of the fantastic add-on that simplifies the process.

In my view, PhoenixCart offers three key advantages:
- It is lightweight and takes up very little server space.
- The template/override system allows you to modify files without touching the core code if you aren't comfortable using hooks.
- Hooks, which—if you know how to use them—allow you to significantly boost the engine's power.
I am fully aware that hooks and templates/overrides can often complement each other.

Regarding hooks—which I feel deserve greater prominence alongside the FAQ—I think a dedicated forum section could be set up specifically for them, featuring a pinned topic listing all available hooks.

[BatteryTrader]

Regarding hooks—which I feel deserve greater prominence alongside the FAQ—I think a dedicated forum section could be set up specifically for them, featuring a pinned topic listing all available hooks.

I think the concept behind hooks is great.

My understanding of them is growing, but very slowly, so more info on them would certainly be nice for me.

[burt]

A super interesting thread so far, thank you to all who are getting involved.

Do note that I am keeping a list of potentially actionable things (eg having a dedicated hooks area in the forum).

--

Two more simple questions - again open to anyone;

setting an oven is 'programming.'

If that's the case, what word do we use for writing the PHP that powers Phoenix itself - the actual code that makes the store function, processes payments, and handles security? Is that also programming, or is that something else?

Hooks Conceptually

When a shopowner uploads a hooked file that someone else has written is that file the result of someone programming?

[bonbec]

... setting an oven is 'programming.'

To me, "programming" means using a remote control or buttons to trigger an action that will take place later.
To me, "coding" means writing code using a specific language.
However, given the richness of the French language, some people use the word "programming" to mean writing a computer program.
So, one can either use the word "code" in its strict sense or use everyday language—though the latter can sometimes lead to misunderstandings, depending on who you are talking to.

Hooks Conceptually

No, there is no button to press or remote control to use; it is simply an add-on to be incorporated into existing code. It consists of lines of code.

[ArtcoInc]

Programming
Programming is entering 'data' into pre-defined fields ...

VCR -- time, date, channel, duration (remember those?)
Oven -- temperature, time
Customer -- Fname, Lname, address, phone, email, ...
Product -- Part #, name, description, weight, cost, ...

Coding
Coding is writing (or editing) instructions in a specific 'programming language' (yes, I see the irony)

PHP, SQL, Basic, Fortran, C++, ...

Hooks Conceptually
When a shopowner uploads a hooked file that someone else has written is that file the result of someone programming?

Using the above definitions, no. The hook was coded. Uploading is neither programming nor coding.

[burt]

Super TY. This reply knocks me off the main tree of my flowchart and into a branch. On this branch, I am seeing a missing link, and I will try to explain why I believe 3 different words are so much closer to what you want;

In the latest post, you (correctly, in my opinion) separate programming and coding.

a/ Programming = the softcore, insert a product name, make a configuration change, save.
b/ Coding = the hardcore, literal typing out of code to make a hook, module whatever.

In your original post, you would like Phoenix to shout out loud "no programming necessary". Yet, going by what we see later on in the thread, we now know that programming includes things such as setting a store name, max values, turning modules on and off etc (and turning an oven to ping after 40 minutes ). Right?

Here's the fatal flaw; Both of these positions can't be true at the same time.

If Phoenix shouts out "no programming needed"...and then others users also view changing a module from col-sm-12 to col-sm-8 as programming (as you do), then we are misrepresenting what Phoenix is all about.

In my opinion, "no coding needed" is so much closer to your position. This is what I thought far earlier in the thread and tried to make you see - framed as a `simple` question - it wasn't some devious trap. If you re-read the thread, that question is an off ramp for you to take advantage of - all of what you say - about programming in that first thread...just swap the word programming for coding - and more or less every word then makes sense.

--

Those words take me back into the main branch of my flowchart and there is more questions, but it all depends on how the above words, well, if they make sense at all to anyone.

[ArtcoInc]

In my opinion, "no coding needed" is so much closer to your position. This is what I thought far earlier in the thread and tried to make you see - framed as a `simple` question - it wasn't some devious trap. If you re-read the thread, that question is an off ramp for you to take advantage of - all of what you say - about programming in that first thread...just swap the word programming for coding - and more or less every word then makes sense.

Guilty as charged.

I believe I was more focused on the concept than on semantics.

[burt]

If we all agree that something like "NO CODING NEEDED!" is just about right...for Phoenix to `shout out loud`..here's the next Q, but it needs a Scenario that I think will make sense to everyon...

--

Baseline Assumptions - the Scenario

1. Hooks are made of code
- I'm certain we all agree on this.
2. Shopowner doesn't need to look at the actual code
- if he doesn't want to, right
3. Shopowner downloads a Hook Addon where the README says something like
- a. Upload all (except this README).
- b. The install is complete

For a shopowner to enable this hook ... he reads readme, see he just needs to upload it ... and it starts working ... shopowner uploads, see it in action and thinks wow, this is great... <---- this "wow", I think, is the end goal that we all want.

Shopowner gets to go "wow, this is amazing" (even though the hook might do something quite mundane)...
Developer wants to give shopowner that "wow" moment as now the shopowner knows the dev does good work...
Phoenix gets a good rep for being the cart that gives easy "wow" moments...

--

Question: to achieve that `wow` that hook must simply `plug in` to core code with 100% predictability. Fair?