OXID eShop versions 4.7.11, 4.8.4, 5.0.11 and 5.1.4 published

Hi everybody,

OXID eShop version 4.8.4 (CE + PE) and 5.1.4 (EE) were published. As usual, you’ll find all important information on this page:

Additionally, we published an updated versions for the 4.7/5.0 series, that you’ll find here:

Please note that these patch releases contain a fix for two security issues, so a quick update is 100% recommended. We also prepared a fix for the security issues 2014-001 for version 4.6.8 that can be downloaded here:

We will publish the security bulletins including a workaround for older versions and for fixing 2014-002 in version 4.6 ~ March 11th.

Regards

I’m curious why the update to 4.8.4 has approx in the copy this / copy full folders there are 627 files.
Yet when you ignore files that have very very minor changes in the comments (ie this part * @package core deleted) there are just 20 files that actually have changes.

Why can the update not be published with the changed 20 files and not including the other unnecessary 607 files ?

following up with updates - why are things not updated ?
for example cloudzoom.js - oxid version = 1.0.2 from 2010
actual version = 3.1

this is just a question ?

…actually forget this, its seems also to have now become a comercial plugin

Hi,

I totally agree with soup that it is annoying to have these yearly header updates bundled with important (especially security) updates. So it is not easy to follow up your recommendation (quick update) because no one knows what really will be changed by this patch (or was this intended?). I think it would be much better to offer seperated patches which only updates the file headers for cosmetical reasons or why this may not be possible?

Further there seems to be no working download yet:

We also prepared a fix for the security issues 2014-001 for version 4.6.8 that can be downloaded here

Hi,

Further there seems to be no working download yet:

Thanks, I corrected the link.

About the changed files in copy_this/:
The update packages are built automatically. So if there’s any change in the header, all of the files will appear as changed just because of the (in this case) removed SVN notice. It has nothing to do with the change of the year in the copyright notice - this issue was resolved in the last year.
And nope - no security by obfuscation ^^ This behaviour appeared unintentionally. But actually it shouldn’t be a big problem: As this is a patch release and you guys keep your installations clean using the module system for functional changes consistently, you might simply copy & paste everything from the copy_this/ folder into the shop, right?

Regards

Hi Marco,
thanks for the corrected link! And yes, basically you should go right with:

But actually it shouldn’t be a big problem

But as you know, this only works perfectly in theory. Let’s have a look at the former patch (4.7.10/4.8.3). It has been announced as a sepa hotfix but what has happened? Some modules crashed because of the also included adodb changes. So, of course in general it is great to have modules, tpl overrides and all this stuff, but the more these are used inside a shop, the more work you have to accurately check if all individual modules/changes are still compatible with upcoming OXID patches/updates.
But you are right, in this current case it is as simple as only having to copy files over in most cases I guess. Unfortunately you have to try it before you will know that, but therefore we all maintain test environments of course! :wink:

Hi @Mitmacher,

I see. But to be honest - IMO, it is absolutely not practical to deliver patches for single bug fixes or enhancements. This would provoke the most perfect chaos at most likely all involved parties - so it turned out that these monthly patch releases are the most doable way.

Thanks for your feedback anyway!

so it turned out that these monthly patch releases are the most doable way.

Yes, of course, I don’t wanted to doubt this! I only wanted to mention, that it is not as simple as to blindly copy OXID patches into your shop only because you are using modules and overrides. They also may crash in some cases and imho there is missing a possibillity to check this first (oxchkversion offers no real help for this).
Some time ago I wrote a script to check which modules files are containing functions which will be changed by an update. That’s better than only comparing md5 hashes and saved me a lot of time but was still not perfect because you also need this for TPL overrides (and that would be even more difficult to implement)…

one more hint from me … would be nice to have 2 oxid versions … 1 normal as it is now… and 1 with minified java/css files.

kinda much work to minify everything again after update … (minify by removing comments, tabs, unneeded spaces etc)

and surely using an automated system, it is possible to say ignore comments.
Which in this case is what its all about - 600 files, only changes in the header comment.
And there is no way that can be ignored ?

Hi,

we want to update our shop from Version 4.7.11 to 4.8.4 but there are no cummulative Updates available? The last version from 4.7. to 4.8.4 is the 4.7.9!

When will be the Update package available?

cya

Hi Firefax,

apparently, there’s something wrong. We care about it.

Cheers!

Alright, now it seems to be fixed, thanks @martin.wegele :wink:
The patch for 4.7.11 --> 4.8.4 is not there yet, both versions were published the same day but these patches will come with the next update, stay tuned.

Cheers

Hi Marco,

many thanks for the information. No problem, I can wait for the next update in a few days. :wink:
cya

@Firefax: not sure if the next patch release will happen in a few days. As far as I see it, you could use 4.7.10 --> 4.8.4 either. Every change will be overwritten with the next one anyway :wink:

Cheers