Document BC breaks

[cmfcmf]

BC breaks

• every call to a system module (API, modvars, etc.) must now use ZikulaXXXModule.
• $this->request->files syntax changed, the old way will not work anymore.
• sluggable doctrine extension has to be refactored 🆗
• request filter method signature has changed - see Guite/MostGenerator@dfeb811
• usage of D2 native paginator (not part of the core, but still a change for modules) 🆗
• etc.

Why this list? To collect all the BC breaks at one place, move them into changelog / UPGRADING all together, and see if @Drak's promise with almost no BC breaks is true.

• 🆗 The bc break now is documented
• strike through The bc break is fixed

[ghost]

This ticket is unnecessary. Just open a PR on UPGRADING-1.3.6 to document whatever is missing. So far, everything is in there. See my list below.

every call to a system module (API, modvars, etc.) must now use ZikulaXXXModule.

This is not a BC break, the system translates this internally here

$this->request->files syntax changed, the old way will not work anymore.

This is too bad, we just have to document this.

sluggable doctrine extension has to be refactored

This is already documented here

usage of D2 native paginator (not part of the core, but still a change for modules)

Already documented here

"ztemp" moved

This is not a BC break

js, css of system modules moved (effects auth modules for example, which are stealing the style sheets of the users module)

These are handled and rewritten internally, so these are not a BC break.

[cmfcmf]

This ticket is unnecessary. Just open a PR on UPGRADING-1.3.6 to document whatever is missing. So far, everything is in there. See my list below.

I just wanted to avoid so many small PRs. And as you see I was wrong with the module API point.
I guess you did not read that the second list is not to be seen as BC breacks.

[ghost]

@cmfcmf I am explaining why I don't see it as a BC break: temporary files and their location are something Zikula uses internally. The location is controlled by an API (CacheUtil), therefor it's not a BC break at all.

Also, if things change internally but the system provides a BC layer (like referencing the old core module names), this is not a BC break. It's a change with BC compatibility..

[cmfcmf]

Yes, @Drak, I don't see this as a bc break either!

[ghost]

@cmfcmf - cool, just being clear. Let's keep the ticket open but edit the top with strikethrough for everything that is documented. If anyone has a cool idea to reduce the BC breaks then that is excellent. For files, one could replace the ParameterBag with a proxy class and magic methods for example. The request object is supposed to be created only once in the front controller btw.

[cmfcmf]

I'll add 🆗 behind everything documented and strike through everything wrong.

[ghost]

@cmfcmf If you do that you would need to replicate all the changes in the UPGRADING-1.3.6.md document - that's the wrong way round. It's basically up to date now.

[ghost]

Breaks with hacky implementations (not to be seen as BC breaks)

This is just plain wrong. The thing about CSS files moving is just like most of the other changes, Something changed, the change is transparent. You cannot call it a "break" by any stretch of the imagination - you cannot call it a hacky implementation either since the handling is the BC layer itself. That's not hack, that's what BC is. The ticket content is very confusing because of this. You should edit out things that were not true to start with.

[cmfcmf]

Hmm yes, I'm understanding your point. but I see the bc breaks mentioned in the upgrading document as "accepted and well documented", whereas this ticket shall encourage people to think about further bc breaks, which weren't mentioned nor discussed, like the request filter one.

I'll remove the "hacky" section, if it is that confusing :)

[ghost]

@cmfcmf agreed: to clarify the request->filter was unexpected and unseen - if someone cares enough it might be possible to handle with a proxy. Sluggable was unavoidable - pain now with almost zero adoption or pain later when adoption is greater.

[craigh]

Sluggable change -> craigh/Tag@f4fb25f for reference

[Guite]

Bootstrap components and HTML5 validation could cause problems with themes using no html5 doctype (see #1181 and #447 also).

[ghost]

@craigh - already documented here

[ghost]

Bootstrap components and HTML5 validation could cause problems with themes using no html5 doctype (see #1181 and #447 also).

This needs to be proved first. As far as I know, browsers are pretty forgiving but someone needs to demonstrate this is a problem first. I don't believe it is. Would someone like to test? Also it might be better to call this "HTML5 client side validation" so as not to confused with HTML validation which is a different beast.

[ghost]

Closing. We just simple document as we go as part of PR approval process. It should be noted in the UPGRADING-1.3.6.md as usual. It serves the same purpose.

[craigh]

don't you mean UPGRADING-1.3.7.md ? 😀