No Core Changes - A different perspective

[burt]

If the addon creator actually marketed and sold their addons to users rather than just upload the minimum a store owner would have a better idea of what an addon does and how it will benefit them, but that's another thing.

The one & only Golden Rule for addons that is absolutely inviolable and immutable;

Addons Must Not Change Core Code

Other than that, anyone uploading to the addons area, can do as much or as little as they want. Simple code, complex code, Images, Video, Screenshots, a 10 page PDF of usage instructions etc. Or not.

I don't want to police the addons area; perhaps potential users of addons can do that - by asking addon creator for video, more images, screenshots, etc.

--

• The merchant facing mantra needs to be "no coding needed".
• The developer mantra needs to be "no core changes".

As Daniel @Kofod95 pointed out very early in the thread, these two things are different face of the same coin. Without one...the other is void.

[azpro]

using a hook will allways be kind of tricky - that's why the switch is so important IMHO

Good idea on the switch if scoped correctly, but I'm unsure on exactly your meaning, because it's too vague as a concept right now. Let's see it holds up;

a/ does the switch protect a shopowner from two hooks conflicting with each other
- or -
b/ does it protect them from a hook conflicting with a core file the shopowner has personally edited?
- or -
c/ something else. What exactly, I wonder?

If a shopowner has changed something in a core file, and then flips the switch `off` for a hook that isn't working - does `off` actually take them back to a known, predictable state? Or does `off` just take them back to their own modified core, which the hook developer never tested against and has no way of knowing about?

Isn't the perfect switch simply;

1. upload = turn on
2. delete = turn off

There is a nuance to this; there already is a mechanism in Phoenix to allow Hooks on/off, but hardly anyone has explored it as the few creators who make hooks prefer the usual easier way. The mechanism is just more complication when a Hook is fairly considered as "always on" if it exists (which is the real, durable norm).

For me (developing the store) I found it annoying after download an add-on and uploading hook file(s) - just for testing - I have to delete again on server. Next week I think "Oh it might be useful after all" - again upload - test again with specific task in mind - yes this can work but I need to create new hook - so delete again from server .... It's more a wish for development - altough not totally unimportant for this discussion.

There is a nuance to this; there already is a mechanism in Phoenix to allow Hooks on/off, but hardly anyone has explored it as the few creators who make hooks prefer the usual easier way.

... I have never seen it So if you can point to an example - thanks!

[14Steve14]

The only thing I currently dislike with the hooks system is that they are not sortable. I know the names can be changed. It would be nicer if they could have a sort order, but that may lead to a lot more work. No coding required and fully customisable. Plus plus.

[burt]

Look into Database Hooks. You can turn them on/off by simply removing from the hook table.
It's all there ready for you to deep dive.

--

The thread has gone a little bit off piste from the intent of Malcolms first post which was about Marketing and "programming / no programming", so I leave this conversation now as I think we covered everything in that great post. Many thanks to everyone who posted in this discussion, I think we're all on the same team, more or less wanting the same thing.

--

The people who build add-ons for a living - the people whose livelihoods depend on the architecture - didn't feel the need to defend it. That tells me something, I think quite positive, maybe.

--

I'm looking into the idea of a dedicated `More Technical` forum area. I am willing to build that table, but I do not want to be the only one serving the food.

[ArtcoInc]

First, I want to thank everyone that participated in this discussion!

It is generally accepted that "no core changes" is a good thing, and that if a shop owner wishes to edit core files (of which I have been guilty), than they assume any compatibility issues with "well written" add-ons. No arguments here.

That said, I would like to loop back to the initial point of this thread ....

No core changes "to prevent problems with future software updates"

As discussed earlier, most shops do not update very often. Given that, the "prevent problems with future software updates" is a moot point.

If I were to advertise that my product "reduces the chances of radiation exposure when on the moon", that benefit would be of no value to 99.99% of the people here on Earth! If so, then what's the point of promoting it that way?

Again, I'm not suggestion that "no core changes" isn't good. Just that don't promote it as a cure for a problem that doesn't exist.

Again, thanks to everyone that participated!

Malcolm


PS: I'll probably start a separate thread with questions regarding the file override system.

[burt]

I'm looking into the idea of a dedicated `More Technical` forum area. I am willing to build that table, but I do not want to be the only one serving the food.

I have added a Technical Area - hopefully everyone can see them if I have added them correctly.

I do not want to be (and honestly, can't be) the only one serving the food.