Hi, these methods were introduced as private, because in near future we want to implement more elegant solution. In case you are overwriting method without calling parent, you would still need to update modules even if methods would be protected. As methods are private now, you will have to copy contents and add to your modules.
Mantas Vaitkunas Software Engineer mantas.vaitku...@oxid-esales.com<mailto:mantas.vaitku...@oxid-esales.com> Fon +49 761 36889-0 Fax +49 761 36889-29 www.oxid-esales.com<http://www.oxid-esales.com?campaign=emailsignatur/oxid-esales-com&adword=OXSIG_Startseite> [OXID Commons]<http://www.oxid-commons.de/> Review OXID Commons 2016 02.06.2016, Freiburg www.oxid-commons.de<http://www.oxid-commons.de/> Picture gallery<https://www.flickr.com/photos/oxid-esales/sets/72157668976133352> OXID eSales AG Bertoldstrasse 48 79098 Freiburg Germany Executive Board: Roland Fesenmayr (Chairman), Dr. Marcus Klosterberg Chairman of the Supervisory Board: Michael Schlenk, Headquarter: Freiburg County Court Freiburg i. Br. / Germany, HRB 701648, Tax-identification-number: DE231450866 ________________________________ From: dev-general-boun...@lists.oxidforge.org [dev-general-boun...@lists.oxidforge.org] on behalf of Tomas Kvietkauskas [tomas.kvietkaus...@nfq.com] Sent: Monday, June 20, 2016 7:36 PM To: dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] Private methods in current security patch Ah ok, checked the code, you are talking about cleanBillingAddress and cleanDeliveryAddress methods. You are right, this could affect extended createUser method functionality, just because its one huge mess and I assume nobody calls parent on it’s extended method and this core patch becomes useless. And of course think about other implementation cases .. On 20 Jun 2016, at 19:23, Tomas Kvietkauskas <tomas.kvietkaus...@nfq.com<mailto:tomas.kvietkaus...@nfq.com>> wrote: Hi Dirk, thanks for your insights, could you please name methods that were changed from protected to private? - Thanks On 20 Jun 2016, at 17:36, Dirk Mueller <dirkmuelle...@yahoo.de<mailto:dirkmuelle...@yahoo.de>> wrote: Hi, be aware that the two new implemented methods in oxcmp_user class at the previous security patch have been declared as "private functions". Is there any reason to use "private functions" instead of "protected functions"? Current situation could kill modules which are overwriting "createUser()" and "_changeUser_noRedirect()" methods in oxcmp_user class as private methods do break the inheritance chain. So, whenever you are updating your shops or adding the current security patch you should also check all modules in your shop which are overloading or overwriting the oxcmp_user class. @OXID devs: What's you opinion about this? Do you think we can change a.m. methods to protected functions? Best regards, Dirk Müller _______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general _______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org<mailto:dev-general@lists.oxidforge.org> http://dir.gmane.org/gmane.comp.php.oxid.general
_______________________________________________ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
