No Core Changes - A different perspective

[bonbec]

Yes.

Just a little thing : a "- c" is missing in the point 3.

- c. Uninstall instructions.

It is worth noting that some hooks (and more frequently, add-ons) lack screenshots showing the expected result. As the saying goes, "a picture is worth a thousand words." Visuals help clarify the written explanation, especially for those who are not fluent in English. Web-based translators can yield inconsistent or even misleading results; for instance, both "coding" and "programming" translate to the same French term, *programmer* (as noted in the previous discussion).
Consequently, it can be frustrating to have to install a hook just to see what it does, without knowing how to uninstall it if it fails to meet expectations.

[ArtcoInc]

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

Absolutely!

And, is there any way to un-install a hook, short of just deleting all of the files initially uploaded?

Maybe include a batch file with the code that deletes all of the new files?

A 'no coding required' un-installation

[azpro]

- c. Uninstall instructions.

Or just a switch (on/off) stopping the hook from working ?

[bonbec]

Or just a switch (on/off) stopping the hook from working ?

Great idea and the hooks becomes plug-and-play

[burt]

Fantastic. We are all completely aligned: 100% predictability of the core code is the mandatory baseline required to give the merchant that 'wow' experience and protect the 'No Coding Needed' promise.

Which brings us to the final question on this branch of the flowchart:

If a shopowner manually edits code in a core file... how can any creator guarantee 100% predictability for the next hook shopowner uploads. And if we can't guarantee it, hasn't the 'No Coding Needed' promise just been broken by the core change?

[azpro]

If a shopowner manually edits code in a core file... how can any creator guarantee 100% predictability for the next hook shopowner uploads. And if we can't guarantee it, hasn't the 'No Coding Needed' promise just been broken by the core change?

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

[bonbec]

... If a shopowner manually edits code in a core file... how can any creator guarantee 100% predictability for the next hook shopowner uploads. And if we can't guarantee it, hasn't the 'No Coding Needed' promise just been broken by the core change?

A hook creator cannot know what is inside a user's files. They therefore assume that the file calling the hook has not been modified—which is likely the case for the majority of users.

If a user has modified the source code and the hook causes an issue, they must be able to adjust their file modification to accommodate the hook.

[burt]

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).

[14Steve14]

If a shopowner manually edits code in a core file... how can any creator guarantee 100% predictability for the next hook shopowner uploads. And if we can't guarantee it, hasn't the 'No Coding Needed' promise just been broken by the core change?

I think this is a risk that the shop owner takes when they modify core code so perhaps a warning in the core file instructions somewhere, or even a brief instruction type message explaining how to create files and not alter core. Even if its a link to a help guide page.

Personally though, how many store owners actually modify core code. Surely most of them have no idea what they are doing and would either get someone to code them something, or install a ready to go addon from the addons area. 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.

I quite like the simplicity of uploading a hook and it should work, and remove it if its not what I want, or does not do what I wanted it to. That's really simple and having to either switch them on or off could cause problems such as what would happen in the hook was turned on, then uninstalled. When that happens to module sit causes problems so would it be the same with hooks.

[burt]

If a user has modified the source code and the hook causes an issue, they must be able to adjust their file modification to accommodate the hook.

I agree. And this links back to post 1 in this thread in a beautiful way, TY.

Modification of core files breaks the "No Coding Needed" contract, not only in Core but also in Addons <--- that contract is the central theme of this thread, I think?

User breaking that contract is perfectly fine, no one has ever told a user what they must (or must not) do.
But User must then understand the consequences.