Sneak Peek: OpenCart 1.5.0 *ALPHA*

MISSING!
Guernsey
Jersey
Isle of Man

And now for something completely different

Regarding SEO URLs, can we get out of the hierarchical tangle that we have now, and have something simple like:
domain.com/opencart/language/product/product-id/seo-keywords
e.g. domain.com/opencart/en/product/1231/ipod-shuffle-8gb
instead of the current domain.com/opencart/language/category-name/subcategory-name/seo-keywords&language=XX

similarly for category it could be domain.com/opencart/language/category/category-id/seo-keywords

The advantages are:

• In the proposed schema, OC doesn't really have to care about what comes after the product ID.
  domain.com/opencart/en/product/1231/ipod-shuffle-8gb
  domain.com/opencart/en/product/1231/abrakadabraboomboomshack
  both lead to the same page. Hence, if for any reason, the user has to change SEO keywords, this won't break anything.
• There is one URL for a product page. No duplicate content issues, real or imaginary
• The URLs are short and less likely to be truncated. Also easier to tweet.
• The URLs are simple (ok, maybe this is somewhat debatable )

sooskriszta wrote:If I understand it right, you are saying modules should supply the content, not how it looks...

Yes, basically. I understand there will be extra markup, but it should be only what is needed for the module, not to make it match a specific theme, unless that module intends to be made to be used for just a specific theme. I think by removing the extra divs that are specific to the default theme, you create modules that are more flexible and adaptable to whichever template you are using, instead of leaving people wondering "Why are there all these unnecessary divs in my module's template file that I just downloaded?" Furthermore, if the modules that come with OpenCart also followed these guidelines, then users that aren't exactly web developer savvy won't be left wondering "Why doesn't this module I just downloaded automatically match my template like the default modules do?"

You can't make every module be automatically converted to match a template, I understand that, also. But with the release of 1.5 I am hoping the QUALITY of templates and modules gets better, so we should look to encourage smarter, and more cleaner ways of doing things from our module and template developers. There is a severe lack of guidelines in "what is right" when developing modules and themes at the moment

Xsecrets wrote:so a mod maker should code his module to some undetermined schema to match what you one person may want that you are not even sure of from project to project rather than code them so that most of their customers who are not theme makers can simply upload them and they look right in the default template? Is that what you are saying?

No. Thats not what I'm saying

hbuchel wrote:

sooskriszta wrote:If I understand it right, you are saying modules should supply the content, not how it looks...

Yes, basically. I understand there will be extra markup, but it should be only what is needed for the module, not to make it match a specific theme, unless that module intends to be made to be used for just a specific theme. I think by removing the extra divs that are specific to the default theme, you create modules that are more flexible and adaptable to whichever template you are using, instead of leaving people wondering "Why are there all these unnecessary divs in my module's template file that I just downloaded?" Furthermore, if the modules that come with OpenCart also followed these guidelines, then users that aren't exactly web developer savvy won't be left wondering "Why doesn't this module I just downloaded automatically match my template like the default modules do?"

You can't make every module be automatically converted to match a template, I understand that, also. But with the release of 1.5 I am hoping the QUALITY of templates and modules gets better, so we should look to encourage smarter, and more cleaner ways of doing things from our module and template developers. There is a severe lack of guidelines in "what is right" when developing modules and themes at the moment

In principle, I agree with the objective.

However, the modules are so varied that the theme may not even be catering for the output of some modules - therefore it's not so cut and dry (not that you are saying it is).

There may be an opportunity to move towards that goal though, with the understanding that not all modules can achieve that...

sooskriszta wrote:And now for something completely different

Regarding SEO URLs, can we get out of the hierarchical tangle that we have now, and have something simple like:
domain.com/opencart/language/product/product-id/seo-keywords
e.g. domain.com/opencart/en/product/1231/ipod-shuffle-8gb
instead of the current domain.com/opencart/language/category-name/subcategory-name/seo-keywords&language=XX

similarly for category it could be domain.com/opencart/language/category/category-id/seo-keywords

well I proposed a similar solution only it would was just domain.com/opencart/product-name which can easily be done with the current system and eliminates the duplicate urls, but the SEO experts had a cow because they lost the category names which they think helps with the page ranking.

The advantages are:

• In the proposed schema, OC doesn't really have to care about what comes after the product ID.
  domain.com/opencart/en/product/1231/ipod-shuffle-8gb
  domain.com/opencart/en/product/1231/abrakadabraboomboomshack
  both lead to the same page. Hence, if for any reason, the user has to change SEO keywords, this won't break anything.

well now that will anger the duplicate content gods because you now have an infinate number of pages pointing to the same page.

[*] There is one URL for a product page. No duplicate content issues, real or imaginary

this is in direct conflict with what you just described if more than one url points to the same page that is the definition of duplicate content.

[*] The URLs are short and less likely to be truncated. Also easier to tweet.
[*] The URLs are simple (ok, maybe this is somewhat debatable )[/list]

If you are worried about short urls you should go the route I mentioned above and drop the language and the word product and the product id.

sooskriszta wrote: I knew nobody would read it

I just did. IMHO the Action envelope example looks best.

hbuchel wrote:

sooskriszta wrote:If I understand it right, you are saying modules should supply the content, not how it looks...

Yes, basically. I understand there will be extra markup, but it should be only what is needed for the module, not to make it match a specific theme, unless that module intends to be made to be used for just a specific theme. I think by removing the extra divs that are specific to the default theme, you create modules that are more flexible and adaptable to whichever template you are using, instead of leaving people wondering "Why are there all these unnecessary divs in my module's template file that I just downloaded?" Furthermore, if the modules that come with OpenCart also followed these guidelines, then users that aren't exactly web developer savvy won't be left wondering "Why doesn't this module I just downloaded automatically match my template like the default modules do?"

You can't make every module be automatically converted to match a template, I understand that, also. But with the release of 1.5 I am hoping the QUALITY of templates and modules gets better, so we should look to encourage smarter, and more cleaner ways of doing things from our module and template developers. There is a severe lack of guidelines in "what is right" when developing modules and themes at the moment

ok well now you are talking about something different. Before you were talking like the current mod makers were doing something wrong when they are just working within the confines of the current system. Now you are saying the system should be changed which the devs know and it will happen I'm just not sure it will happen in 1.5.0. Q has expressed a couple of times the desire to have a single module template that all modules use that way the theme makers can change that one module file instead of having to change every module, but within the current system since every module has to have a tpl file mod makers have no choice but to make that tpl file match the default theme as that is the only constant they have to work with.

hbuchel wrote:

Xsecrets wrote: not really sure what you are expecting mod makers to do. It makes perfect sense for them to use the standard box class as in 99% of ecommerce applications you want all your modules to look the same and have consistency throughout your site. By reusing this standard class it allows the module to look the same as all the other modules and have consistency so when you create your new theme and stylesheet you only have to change the box class once and it applies to every one. If you absolutely need that box to look different you can create your own tpl in your theme folder which may be a bit of a pain, but when you are in the minority you sometimes have to deal with things like that.

I am expecting module makers to leave the containing div and extra markup out of their module and let the template take care of that. Obviously you are going to have to customize any module's template files anyways to match your theme completely, but I think some general guidelines should be in place. I can give on the box class. Can't give on the other classes like left, right, center, bottom that are specific to just the default theme. I guess I prefer a cleaner, more minimal way of coding. And I'm not sure I'm in the minority for that.

This was a topic I brought up here and recently discussed with daniel as well. I agree with hbuchel, but not sure of the best way to handle it.

There are 2 issues that I see:
1. If the module tpl file includes the box wrapper:
- it can break custom themes that use a different wrapper
- but it allows the module to be made without a wrapper for things like ads, banners, etc
2. If the module tpl file DOES NOT include the box wrapper
- it can work better with custom themes as it only delivers the "content" and the template itself handles the wrapper
- but it doesn't allow the module to be made without a wrapper for things like ads, banners, etc

I think that method 2 is correct way to do it, but I think then that there needs to be an configuration option to include/exclude box wrapper. Daniel has currently kept method 1

Xsecrets wrote:... but within the current system since every module has to have a tpl file mod makers have no choice but to make that tpl file match the default theme as that is the only constant they have to work with.

I don't think we require a single module template, and I apologize if I am just confusing you, as the module files have really just been a part of an overall bigger issue with me and OpenCart which is the quality of themes and modules available (both free and paid, however there ARE some good ones out there), and the lack of guidelines for creating them. So maybe I am skipping around a bit.

I guess another example I could give is: You don't see WordPress developers creating widgets to specifically match the TwentyTen theme. They follow guidelines that are basically set forth by people active in the WordPress community, using their own classes and stylesheets that are specific to their widget if needed. Perhaps that is just what developers are doing now and I just feel it needs improvement and hopefully v1.5 brings that along with it. /end somewhat indecipherable rant.

Edit for Q's post. #2 is basically what I meant.

Xsecrets wrote:

sooskriszta wrote:Regarding SEO URLs, can we get out of the hierarchical tangle that we have now, and have something simple like:
domain.com/opencart/language/product/product-id/seo-keywords
e.g. domain.com/opencart/en/product/1231/ipod-shuffle-8gb

well I proposed a similar solution only it would was just domain.com/opencart/product-name which can easily be done with the current system and eliminates the duplicate urls, but the SEO experts had a cow because they lost the category names which they think helps with the page ranking.

Well, you idea for shortening the URL is bang on. I am completely with you on that. I don't understand why the *experts* have issues with that.

However, the way proposed above has certain advantages over the, admittedly simpler, way proposed in the past.

• The new way is provides language information right at the beginning...this means there can be URLs like
  domain.com/opencart/en/product/1231/ipod-shuffle-8gb
  domain.com/opencart/de/product/1231/ipod-shuffle-8gb
  domain.com/opencart/fr/product/1231/ipod-shuffle-8gb
  All lead to same product, but different languages...so the content is different and effectively the page is different..it just seems more elegant than passing parameters...and provides a permalink for the product in each language
• I like to use the words "category" or "product" in the URL - just makes it easier for a human to understand what the URL is about
• Because the ID is included in URL, changing SEO keywords doesn't break the link
• Also because the ID is included in URL, using same SEO keywords for multiple products won't make OC gag and choke
• If the *experts* really want to include category title in URL of a product page, they can simply append that at the end, without affecting the rest of us

Xsecrets wrote:

sooskriszta wrote:In the proposed schema, OC doesn't really have to care about what comes after the product ID.
domain.com/opencart/en/product/1231/ipod-shuffle-8gb
domain.com/opencart/en/product/1231/abrakadabraboomboomshack
both lead to the same page. Hence, if for any reason, the user has to change SEO keywords, this won't break anything.

well now that will anger the duplicate content gods because you now have an infinate number of pages pointing to the same page.

No it won't. Just because multiple URLs are possible, doesn't mean there will be multiple URLs There would actually just be one URL. But this URL would be unshakable and unbreakable, because even if the last part gets messed up, it will still show up the correct page. In effect it's very similar to the PHP dynamic URLs, with just some keywords added to the end for SEO.

To be absolutely clear, OC will generate (and put in sitemap) only one URL with a certain set of SEO keywords, and this will be modified if the SEO keywords are modified. However, OC will be able to read/interpret infinite number of URLs for the same page.

sooskriszta wrote: No it won't. Just because multiple URLs are possible, doesn't mean there will be multiple URLs There would actually just be one URL. But this URL would be unshakable and unbreakable, because even if the last part gets messed up, it will still show up the correct page. In effect it's very similar to the PHP dynamic URLs, with just some keywords added to the end for SEO.

Yes this has never been discussed here because so far with the other problems it's been irrelevant, but I have worked with other systems, and the SEO "experts" do not like that it is even possible to have multiple URL's that will go to the same content. I have seen some pretty crazy solutions put in place to keep this from happening on other systems because of the outcry of SEO "experts"

Qphoria wrote: This was a topic I brought up here and recently discussed with daniel as well. I agree with hbuchel, but not sure of the best way to handle it.

There are 2 issues that I see:
1. If the module tpl file includes the box wrapper:
- it can break custom themes that use a different wrapper
- but it allows the module to be made without a wrapper for things like ads, banners, etc
2. If the module tpl file DOES NOT include the box wrapper
- it can work better with custom themes as it only delivers the "content" and the template itself handles the wrapper
- but it doesn't allow the module to be made without a wrapper for things like ads, banners, etc

I think that method 2 is correct way to do it, but I think then that there needs to be an configuration option to include/exclude box wrapper. Daniel has currently kept method 1

I replied to the other thread, but I will post some comments here as well since it's more active.
I do not see a problem with having the .tpl handle the wrapper. If it's just one .tpl for all modules. A theme maker will only have to change the one, and lets face it once we have this in place I can't see the structure of it changing enough that it affects upgrades.

so when a theme maker creates a new theme he creates the new folder and overrides the header.tpl footer.tpl stylesheet, and module.tpl (if the default semantic markup doesn't fit with their theme) I don't see that being a big deal.

with the proposed solution from the other thread the module.tpl will handle with or without wrapper which will be determined by the module controller.

hbuchel wrote:You don't see WordPress developers creating widgets to specifically match the TwentyTen theme.

that is because the template system works differently in wordpress. More like what we are discussing above where you are not forced to handle all the way up to the box markup you just do the content.

Xsecrets wrote:Yes this has never been discussed here because so far with the other problems it's been irrelevant, but I have worked with other systems, and the SEO "experts" do not like that it is even possible to have multiple URL's that will go to the same content. I have seen some pretty crazy solutions put in place to keep this from happening on other systems because of the outcry of SEO "experts"

Good that you used the quote marks when saying experts because they sound more like zealots and morons

sooskriszta wrote: Good that you used the quote marks when saying experts because they sound more like zealots and morons

well yes you pretty much just described that entire field, and they are very boisterous zealots and morons.

Xsecrets wrote: I do not see a problem with having the .tpl handle the wrapper. If it's just one .tpl for all modules.

Yes, that is where the common tpls would handle it.. "column_right" and "column_left" at this point would be the single tpl where the box code would be for all modules, then with that other plan of wrapper true or false, then this could work.

sooskriszta wrote: Good that you used the quote marks when saying experts because they sound more like zealots and morons

There's a fine line

Qphoria wrote:I think one thing is clear... everyone has different preferences for menus so the megamenu will need to be made modular so that it can be disabled/modified easily. It is hardcoded at the moment, against my wishes. So that is something we will have to do.

Please, please leave the mega menu in as an option at least. As I said before I am not keen on them as a shopper but as a store owner I want to look as much like the UK retail 'big boys' as I can and they have mega menus.
http://www.johnlewis.com/
http://www.marksandspencer.com/
http://www.harrods.com/
http://www.selfridges.com/

Qphoria wrote:

Chones wrote:From a usability point of view I think the mega dropdowns aren't intuitive. In the demo the top level sub-categories with no sub-sub-categories are listed under the "Browse" link, then top level sub-categories with sub-sub-categories are listed alongside. This makes them look like a different type of category from those without sub-categories.

I think top-level sub-categories should be listed horizontally - no need for a "Browse" link as the top-level navigation takes you there anyway.

I don't much like the design of the new mega-dropdowns on the Habitat site, but they do get the category > sub-category > sub-sub-category thing right:
http://www.habitat.co.uk/

I am loving the fact that products are laid out using divs rather than an un-semantic table though - good work.

Yea I like the one on http://www.target.com and http://www.walmart.com better.... maybe with some more styling it can look better

I hate mega menus ( just found out that's what they are called ) except when there is a timer that prevents them from instantly showing when you are moving your mouse over it while on your way to another place!

Qphoria wrote:...will release the code shortly ...

Too much time Q! Too much time!.... and don't tell Daniel but I like the original template with orange and yellow buttons, do you have it? in such case, include in it!

philbydevil wrote:

UNDECIDED:
Left/Right columns disappear on category/product/etc

For those that aren't understanding the concept of a layout designer... YOU choose what shows on which page. You create the layouts. Then you decide which modules show on which layout. So if you want columns on your product pages, enable it for the column. If a column has no modules to show, it auto-hides itself

That's a great way to do it. Doing my Christmas shopping, a lot of the stores I was buying from had a kind of splash page in their "home" area that didn't have a right/left column (just an enticing pic/banner), and then once you actually got past that stage the columns showed.

I've done this to my current site but it involved editing code.