SEO URLs in OpenCart

Sheldmandu wrote:there's no reason an OpenSource off-the-shelf solution should be inferior to a custom built solution or a purchased one.

It's not about one product being inferior to another. It's that a cart - commercial, GPL, or otherwise - can't be all things to all users. It can only provide the framework they need to create it.

What I'm doing here is pointing out that it needs a bit of work in a few key areas and asking how I can get these changes we make to make it into the core product, as I feel these changes could benefit all users and that's our way to give back to the project which gives our project a kickstart.

Then why a whole thread on SEO URL structure? There are already other threads on getting code merged into the OPC core.

http://forum.opencart.com/viewtopic.php?f=24&t=8888

Sheldmandu wrote:You should however have proper rewriting and 301 redirection in place if you don't want to have duplicate content issues with google.

With products able to exist in multiple categories developing a canonical URL system would be much smarter.

http://forum.opencart.com/viewtopic.php ... 98&p=47751

rph wrote:It's that a cart - commercial, GPL, or otherwise - can't be all things to all users. It can only provide the framework they need to create it.

Outside of this topic, I think this comment is the most accurate thing ever said about any carts. This should be the main slogan of the cart.

Qphoria wrote:

rph wrote:It's that a cart - commercial, GPL, or otherwise - can't be all things to all users. It can only provide the framework they need to create it.

Outside of this topic, I think this comment is the most accurate thing ever said about any carts. This should be the main slogan of the cart.

May work from a purely preaching idealism sense (easy to do), but when it's used as an excuse to not do database optimisation that someone has determined is an area the cart could be improved, it's a bit rich (go back and look at it in context). The things the cart does do, it should do well. Not this 'half ass implement, add it to the features list and move on' that is happening at the moment.

These points pop up again:
1. Issues with getting code into the main source tree because Daniel is busy etc. and he does all the edits directly (I think at minimum QPhoria should be able to do commits too)
2. Complete lack of direction with the project so people concerned this may derail the timeframe for the tested production release
3. People not being able to raise valid issues with the code base without being shot down by 'idealism' and preaching.

If Sheldmandu has discovered an area in the code that could possibly be optimized it should be discussed and investigated. He hasn't come here to piss people off, he obviously has some valid points that the community could benefit from.

As for the fork, if someone forks and develops with more visibility, direction and using SVN/git they will get far more community momentum and contribution from skilled developers.

Fork again QPhoria (at 1.3.4), you know you want to.

SuperJuice wrote:May work from a purely preaching idealism sense (easy to do), but when it's used as an excuse to not do database optimisation that someone has determined is an area the cart could be improved, it's a bit rich (go back and look at it in context).

No one's arguing against optimization.

There seem to be a few who constantly defend things the way they are. Substantial changes that will improve the long-term function of the cart are blown off, but little "I'd like this" or "It would be nice if it would that" get immediate attention.

Several core improvements have been suggested. Why not just get a stable release that seems just around the corner - or around the weekend, then put the Burmese Postal Service integration off, along with some of the other "it would be nice" things that would be nice for one or two users and accept the help of someone who seems to know what he is talking about and is volunteering to help?

What is wrong with doing this? Free help, knows what the situation is, why not accept it and have a stronger package.

Seems like a no brainer to me.

SuperJuice wrote: Fork again QPhoria (at 1.3.4), you know you want to.

LOL. I wouldn't use 1.3.4. I hate the new template design (removing layout.php) and renounce its existence. 1.3.2 is where it all veered off course in my eyes.

peteVA wrote:then put the Burmese Postal Service integration off

Isn't it Myanmar now?

Qphoria wrote:

SuperJuice wrote: Fork again QPhoria (at 1.3.4), you know you want to.

LOL. I wouldn't use 1.3.4. I hate the new template design (removing layout.php) and renounce its existence. 1.3.2 is where it all veered off course in my eyes.

I think it went off the rails when the checkout went super-ajaxed when it was working perfectly fine.. think that was 1.3.4 too.

Agreed then, post the URL for your fork and i'll start porting my mods

Guys, all forking will achieve is lots of little carts here and there. It's better to come together as a community and all work on the one project. Obviously the project and community has now outgrown a one man band and we as a community need to work out a way to tackle this in a way that's best for everyone. Forking is the easy thing to do but I don't it will achieve the result everyone wants... i.e. A great shopping cart with great features.

Boy oh boy, I just had a look at v1.4.1 and implementing SEO URL rewriting in the way I intended would be pretty much impossible because all URLs are no longer being constructed through a central class, so it seems if that's the way it goes I will just have to take v1.4.0 and roll with that.

Also having looked through the changes I gotta say that adding multi-store support is a pretty major change which should be a minor release i.e. 1.5 not a 1.4.1. I've let Daniel know and I'm hoping that he'll reconsider as firstly the thought of stopping piping all URL construction through a single point just scares the hell out me.

Sheldmandu wrote:I'm hoping that he'll reconsider as firstly the thought of stopping piping all URL construction through a single point just scares the hell out me.

I agree 100%. I don't know why it was removed, I suppose it's because of the multishop thingie? It's just one big mess in 1.4.1 in my opinion.

Oh, and I also agree on your original topic.. This stuff needs attention.

A month ago I was so fired up on OC. I began recommending it to clients and others on a number of forums where my recommendations are taken seriously. Now, I am sorry I have done so.

I have gotten to the point where I feel this is Daniel's hobby, that he enjoys the challenges of coding, but has no real interest if having a stable product, only continuing challenges / changes to keep him burning the midnight oil.

The fact that half a dozen people mentioned multi-shops sent him off on a tangent. Honestly, I would love to have it myself. But, installing dozens of demos and seeing there are only a handful of multi-shop offerings, usually paid scripts, I had no doubt this was going to be a considerable detour from the just released v1.4.0.

I believe he is off on his own course and nothing said here is going to matter. You all talk about forking. I'm no coder, I know nothing about it. But, I'd say the time for someone with a serious, business related attitude towards a stable, reliable, USABLE package to step up and set up something designed from the eye of a real user running a successful business, not a coder off on a lark for a hobby and pocket change.

First need - a stable V4 without multi-shop using the existing, semi-proven database structure. Get that done, then incorporate the SEO and indexing suggestions for a long-term solid base on which to and additional features.

Well the 1.3.4 guest checkout was not a winner for me. 1.4.0 improved it greatly, but there is no reason the 2 checkout paths can't be combined into 1 path.

I think the latest method of passing the $address array to the shipping modules is much better than passing only the country/zone/postcode that 1.3.4 did. I don't think that will be changing again. So that was an improvement... more or less.

There is still room for a one-page-checkout system, but I have been putting it off until the checkout system stabilizes.

I really don't want to fork anything. I'd rather make a full-fledged patching system that allows easy changes to the core so that it can be whatever it needs to be.

A one page checkout system would certainly be nice, but once again that's an enhancement that people can live without in the short term.

In terms of version, I don't think I've ever seen any product make significant DB changes in a point release, and I have let Daniel know about it. He certainly had the best intentions at hand, but that's quite a serious change and should have been a 1.5.0 alpha, not a 1.4.1.

Generally accepted practice is:
Major Release Increment (1.x to 2.x) - When there is a major rewrite with a significant architectural change
Minor Release Increment (1.4.x to 1.5.x) - When there is a fairly major change to either the code or the schema
Point Release Increment (1.4.0 to 1.4.1) - When there are bug fixes, minor enhancements and so on.

This is fairly well accepted across the board.

It is also often that there are multiple releases running in parallel (e.g. 1.4.x and 1.5.x) and this usually happens when the new release needs a lot more love before its adopted. A good example of this stuff is Asterisk, Joomla, Drupal, jQuery and many other mature OpenSource projects.

You're not really covering any new ground, this has all been discussed ad nauseam with little impact to the release method.

Not only DB changes in point releases, but major internal code structure changes too.

It has happened as recently as 1.4.0 -> 1.4.1. We're all saying the same thing, but every release seems to be "we will standardise on the next release".

I have been told Magento and Ubercart on Drupal are worth looking at in the meantime.

As I mentioned, it seems all of this is falling on deaf ears.

Lots of talk from people genuinely interested in helping, no reply from the principal, Daniel.

Seems to go on his own way, playing with code, having a good time fixing things, but ending up with something that is more like 5% of what people continue to ask for.

It seems a shame to see it go to waste, but I know I have had clients simply move on, rather than wait for a sort of complete single user package that works.

Maybe we ought to get Danto involved and encourage him to work on his fork - DantoCart

Both Magento and Ubercart are really heavy and if you actually want to change something it's somewhere between difficult to downright impossible for the large majority of people. If anything, you'd be better of looking at prestashop, although there's just some things about that just don't feel right.

OpenCart is well architected and designed lean and mean, without using heavy general purpose third party packages like smarty, which simply aren't needed, personally I like that and I don't believe there is currently another cart out there written using the latest development methodologies without being bloated. Having said that I certainly disagree with major changes being put into point releases. When you've got a decent core system, why keep tuning it? Just build out functionality and fix bugs first without undergoing major architectural changes. These kind of major changes will simply put break pretty much every single module written out there. It's just not something that you do. I will wait for a short while and see where things go, but chance are if 1.4.1 ends up being multi-shop with a few other major architectural changes, I might just take v1.4.0 as the base and do the things that I want to do on top of that for my own purposes. That way it's a simple lean and mean single shop system, which is what a good cart needs to be first and foremost.

One page checkouts are never really one page though. They normally have one page with 5 tab pages attached to them.

I think the multi shop will work well. I am changing it though so its 1 admin interface fpor many shops. there won;t be 1 main shop. what you saw was not the finished thing. also the reson for the currently delay is because some one has paid me to add a order editor. i found out this is not so easy to do.