osCommerce Online Merchant v2.3.3.1

[quetevendo]

This release is in preparation of v2.3.4 containing additional improvements.

 

Changes

• Who's Online
  Parse REQUEST_URI with tep_db_prepare_input() before storing the value in the database. Replace REMOTE_ADDR with tep_get_ip_address().
  
• Administration Tool -> Catalog -> Categories/Products
  Fix product price gross tax calculations when adding or editing products.
  
• Session
  Register a shutdown function to close and write the session data. Also check for and allow , (comma) and - (minus) characters in the session ID.
  
• tep_redirect()
  When redirecting from HTTPS -> HTTP and replacing the url with a HTTPS version, also take DIR_WS_HTTPS_CATALOG into consideration which may differ from DIR_WS_HTTP_CATALOG.
  

 

More info: http://www.oscommerce.com/index.php?Us&News=144

[MrPhil]

Why is this 2.3.3.1 rather than 2.3.4 beta (or even just 2.3.4)? It's just going to confuse the hell out of everyone to introduce a new numbering system. So is this thing really a beta/RC, or is it a full production-ready release? If the latter, why isn't it 2.3.4 and whatever follows it (the original 2.3.4 target) is 2.3.5? "One button" installers and packagers are really going to be confused by how to handle this.

 

I don't mind alphas, betas, and release candidates, but they should not be around for more than a month or two, to be replaced by something more advanced.

 

If 2.3.4 is/was supposed to be a Great Leap Forward, make this one 2.3.4 and follow it up with 2.4.0. Don't go making up new numbering systems! What's next, 2.3.3.1.1?

[burt]

Next would be 2.3.3.2 of course.

Bugfixes are an important aspect of any software.

Bugfixes do not warrant a full release.

 

Small updates will get a X.X.X.y release

Full Updates will get a X.X.Y release

 

Whatever we do won't please everyone.

You should expect more regular releases now that more people are contributing to the effort.

 

To clear it up: 2.3.3.1 is a bug fix release of 2.3.3. Not more, not less.

[♥kymation]

And 2.3.1 was a bugfix update of 2.3, as was 2.3.2 and 2.3.3. So that means that 2.3.3.1 is a bugfix to a bugfix. Yes that's confusing.

 

Regards

Jim

[burt]

But now you have new people on the Team, bringing new ideas to the table.

It'll pan out, guaranteed.

[Harald Ponce de Leon]

We're actually considering experimenting a rolling release scheme with pushing out regular v2.3.3.x releases that is then packaged into a final v2.3.4 release, with the v2.3.4 release announcement clearly stating what has been fixed in which point release.

 

This is to get the code already ready in Github out in production use. We are already working with v2.4.0 and v2.3.4 versions so we are contemplating this experiment instead of delaying security and bug fixes until a final release is ready.

 

All releases are stable unless labelled as beta (none so far and none planned) or as under development (v3.0).

 

This experiment was not mentioned in the v2.3.3.1 release notes as we are still considering it, and take this opportunity to ask for feedback on the idea.

[♥kymation]

I agree with the rapid release idea. It is good to get security fixes out quickly, and there's nothing wrong with pushing out regular bugfixes quickly as well.

 

However, I think you're too stuck on the idea of 2.3.4 as the next big release. The last digit has always been the bugfix number. Just call this one 2.3.4, the next one 2.3.5, etc. It doesn't matter if the last release in this series is 2.3.4 or 2.3.44.

 

Regards

Jim

[♥joli1811]

Well Thanks for the new release just read the new release this afternoon and do not think that it warrants a new number v2.3.3.1 is fine

 

but v2.4.0 should be given an extra space as development with impending / next release

 

just below the 2.3 series and before the v3.0 development version LARGE LETTERS if people can not read they will not get far anyway

 

Online Merchant to be used for live merchants / stores or whatever!!!

 

Only problem I see is the upgrade from fancy box has not been included any one using / trying to use the latest of jquery will have problems ???

 

Replace bxGallery and FancyBox with PhotosetGrid and ColorBox

 

https://github.com/osCommerce/oscommerce2/tree/master/catalog/ext

 

or is it only me that has these the fancy box problem where the latest version is now commercial

 

http://creativecommons.org/licenses/by-nc/3.0/

 

and is needed if used with the latest jquery (jquery-1.10.1.min.js)

 

Anyway the color box had a lot more possibility's I have been using as independent pop up / iframe etc to show google maps and pdfs so like it

pity it did not make into this release.

 

Regards

Joli

[♥kymation]

The Fancybox problem has been fixed with jQuery Migrate everywhere I have tried it. It would be good to add this to a future release, as long as the project is using jQuery UI/bxGallery/Fancybox.

 

Regards

Jim

[♥joli1811]

Call the ball, Maverick ........ thanks to germ luv the term

 

@Mention

 

Replace bxGallery and FancyBox with PhotosetGrid and ColorBox ???

 

Has been on the git hub for a while now I think it is important.

 

Me for example had the new code copied and used on a dev site without even realizing it was commercial until foxp2 pointed out I just went to git hub to get the code to solve / debug a jquery problem.

 

Read link

 

Just thought that should have had a priority with any updates ?

 

Regards

 

Joli

[Harald Ponce de Leon]

The v2.3.3.1 release is a minimal maintenance bug fix release to make it easier to apply the security fix.

 

The Photoset Grid / Colorbox replacement requires a little bit more work for existing users to apply, and will be included in the next point release (v2.3.3.2) or in the final v2.3.4 release.

 

Photoset Grid's license is MIT:

 

https://github.com/stylehatch/photoset-grid/issues/13

[Harald Ponce de Leon]

The jQuery libraries and Photoset Grid/Colorbox changes will arrive in the final v2.3.4 release as the current jQuery version and bxGallery/FancyBox combination works fine in the v2.3.3 release.

 

Next week we'll have v2.3.3.2 with PHP 5.5 compatibility updates, bug fixes, and new and updated modules.

[MrPhil]

All I'm begging for is consistency in the numbering system. If you acknowledge that you're going to a new system, and it's clear what goes into what level, how often a level is expected to change, and it's held to, it could work. It's just that we were at 2.3.3, talking about an imminent 2.3.4, and out of the blue comes 2.3.3.1.

 

2.x.x.x major version 2 (don't change more often than every 5 years or so) -- major incompatibilities

x.3.x.x minor version 3 (could change maybe a couple times a year at most) -- major new features

x.x.3.x minor revision/patch 3 (change as often as monthly) -- minor features/enhancements, bug fixes

x.x.x.1 I don't know what to call this -- what's in it? emergency patch?

 

The first three can be scheduled in advance, while any 4th level might be for emergencies only. This (at least, the first 3 levels) are industry standard and what people expect. I'm concerned that those who provide bundled applications (Fantastico, Softaculous, etc.) are going to be confused and might hold off offering up to date versions of osC because they can't figure out what's what.

 

Then where do alpha, beta, and release candidates fit in here? If used, they must have very short lifetimes, say, no more than 30 to 60 days before they're replaced with the "next" or "final" versions.

[Harald Ponce de Leon]

Since v2.3.0, we no longer release alpha, beta, milestone, or release candidate releases. All of our releases are stable and production ready unless otherwise labelled (eg, v3.0.x are development releases and are labelled as such).

 

The v2.3.3.x releases are building up to the final bundled v2.3.4 release. The v2.3.4 release will include the v2.3.3.x changes in its release guide and clearly note which change was pushed in which release version.

 

We have bug fixes and improvements in our development repository at Github that are waiting to be released, however we are still working on finalizing what we would like to call the "v2.3.4" release. Instead of delaying what is already ready, the bug fixes and improvements are being rolled out in batches as v2.3.3.x releases.

 

We could have labelled the releases v2.3.4, v2.3.5, v2.3.6, ... however we have already marketed the ideas of what we wanted in v2.3.4 that releasing a half complete v2.3.4 version would require a rewiring of our brain circuits .. so we're passing that burden onto you :D

 

Forget the notion of point point point point point, even versions production, odd numbers development, OMG up to v30.0 already; .. a new release has been made - it's detected in the Administration Tool Version Checker - don't worry about the version number - just go ahead and use it.

 

Those companies bundling applications know what they're doing - it's their job.

[♥joli1811]

The jQuery libraries and Photoset Grid/Colorbox changes will arrive in the final v2.3.4 release as the current jQuery version and bxGallery/FancyBox combination works fine in the v2.3.3 release.

 

Next week we'll have v2.3.3.2 with PHP 5.5 compatibility updates, bug fixes, and new and updated modules.

 

Unless I am very much mistaken the 2.33 version with bxGallery/FancyBox combination and updated jquery does not work with ext/jquery/jquery-1.10.1.min.js .

 

Can test again if you want on a standard install ?

 

As far as I remember the jquery-migrate-1.2.1.min.js also did not solve this problem the image pop up did not work until I changed the fancy box script.

 

Maybe my configuration but lost the pop up effect

 

 

Regards

Joli

[Harald Ponce de Leon]

Unless I am very much mistaken the 2.33 version with bxGallery/FancyBox combination and updated jquery does not work with ext/jquery/jquery-1.10.1.min.js .

 

You are correct - it doesn't work with the latest jQuery version, however they still work with the jQuery version included in the release (1.8.0).

 

There's a bit of work involved with the change to PhotosetGrid/Colorbox:

 

https://github.com/osCommerce/oscommerce2/commit/e9d53b009b6ed4538af65f6dca975161d9308b4f

https://github.com/osCommerce/oscommerce2/commit/4ad20abc8e8b35d22c4d5e14f0dafa1468e025e6

https://github.com/osCommerce/oscommerce2/commit/859559e306b8114577ebbce4d98c68b234f646d4

[♥joli1811]

Moin,

 

Well great work with the new quick release guess that Bear with the Fez who thinks he is Monkey is keeping everyone busy in development (w00t)

 

Ok will do a bit of testing on my own site just updating ( never finish haha ) as I really like this colour box

Thanks for the links.

 

Been using a few extra features from colour box the last few months just like it sort of cool B)

 

Regards

Joli

 

PS:

 

Rewiring of our brain circuits .. so we're passing that burden onto you :D 2.3.3.Phily :D 2.3.3.Jan named after member of the month

 

simple really may as well have fun!!

[greasemonkey]

No comments from me on the version numbers... I promise.

 

Just a question/comment about the update instructions here; http://library.oscommerce.com/Online&en&oscom_2_3&release_notes&v2_3_3_1

 

Is there a reason the 2 changes to includes/functions/general.php are split into 2 completely separate set of instructions, separated by the changes to includes/functions/sessions.php?

 

Change # 4:

includes/functions/general.php

change tep_exit() from:

 

Change # 5:

includes/functions/sessions.php

change tep_session_start() from:

 

Change # 6:

includes/functions/general.php

change tep_redirect() from:

 

For "us" less/non experienced programmers the update instructions could have looked like;

 

Change # 4:

includes/functions/general.php

change tep_exit() from:

 

Change # 5:

includes/functions/general.php

change tep_redirect() from:

 

Change # 6:

includes/functions/sessions.php

change tep_session_start() from:

 

Or even;

 

Change # 4:

includes/functions/general.php

change tep_exit() from:

 

 

includes/functions/general.php

change tep_redirect() from:

 

Change # 5:

includes/functions/sessions.php

change tep_session_start() from:

 

Not a huge deal breaker in any way... however, it just makes more sense to me to have all the instructions for each file grouped together.

 

Thank you - everyone who is involved in providing this update!

[Harald Ponce de Leon]

Is there a reason the 2 changes to includes/functions/general.php are split into 2 completely separate set of instructions, separated by the changes to includes/functions/sessions.php?

 

Yep, it's because we're human.

 

Here's the robot version:

 

https://github.com/osCommerce/oscommerce2/compare/v2.3.3...upgrade2331.diff

 

We hope the human version is preferred as it gives you time to perform the changes and ensures one changeset does not include parts of another changeset that would unknowingly lead to a broken store until the rest of the other changesets were performed.

[burt]

Here's a real email conversation regarding these point releases, between myself and a guy who is a self confessed non-coder but is happy to take his time copy and pasting where required;

 

Now onto upgrading to 2.3.3.2...

 

My reply

 

2.3.3.3 is out monday so you might as well wait for that and do it in one shot.

 

These "point" releases are a build up to 2.3.4 - so you could just as

easily wait for 2.3.4 and then make the changes...

 

EG:

2.3.3 (full)

2.3.3.1

2.3.3.2

2.3.3.3

and so on

lead up to

2.3.4

 

All changes in the 2.3.3.x releases will be in 2.3.4

 

Make sense ?

 

His reply:

 

Sure does make sense. However for a guy of my "skill" level (or should I say lack of skill) it's less daunting to upgrade in smaller chunks.

 

It took a lot out of me to do the upgrade from 2.2.... So for me keeping on top of it will be a much safe plan.

 

 

That conversation is part of a larger conversation (most of which was to do with something else than point releases) and shows that for some people having these mini releases is a good thing as it allows them to make the changes in bite size chunks.

 

I know that others would prefer to see a full release every year or two, but I do believe that having more regular releases allows people to see that the Team is working as hard as possible to make osCommerce great again.

[♥altoid]

I know that others would prefer to see a full release every year or two, but I do believe that having more regular releases allows people to see that the Team is working as hard as possible to make osCommerce great again.

 

Definiitely

[MrPhil]

Definiitely

 

Definitely NOT. It gives the impression that osC's situation is extremely fluid and unsettled. People aren't going to trust it if it doesn't settle down a bit. They're not going to want to invest the time in upgrading now if in a week they'll feel they have to upgrade again. Finally, the bugs I've seen reported on this forum give a clear impression that the weekly releases aren't getting tested enough before going out the door. If they were "beta" or "release candidate", that could be excused -- but these are supposed to be production-ready releases you can build your business on.

[Harald Ponce de Leon]

The switch to mysqli in v2.3.3.2 would have caused problems with some Add-Ons regardless which release version the change was made in and only affects Add-Ons that were not using the standard tep_db_*() functions.

[♥14steve14]

The switch to mysqli in v2.3.3.2 would have caused problems with some Add-Ons regardless which release version the change was made in and only affects Add-Ons that were not using the standard tep_db_*() functions.

 

Maybe then the core development team should spend time and check that the addons are going to work, and if they dont they should alter them, or at least add something to these addons that will let people know that they do not work as designed. It will mean more work, but then they are creating the extra work.

[Harald Ponce de Leon]

No, that's not our job, it's yours - the community.