Post by Qphoria » Fri Oct 12, 2012 2:31 am

It is becoming a full time job trying to get the simplest mods to work with many of these drastically revamped themes. (Shoppica, Sellegance, Spicylicious, Clothing, Tees, etc. Most of the themes from Themeforest...)
I appreciate that your themes are beautiful on the outside, but the choices of coding underneath can push even the more reserved person into a homicidal rage! :bash: Image

Ridiculous things like
  • moving the product heading <h3> tags and other non-form context inside the <form> tags on the product page.
  • renaming the buttons ONLY for the sake of renaming them
  • changing the class names from simple things like "button", "price", "special"
    to something ridiculous like "s_but_clear_tran_xyz", "s_price_format_plus", "s_price_extra_super"
  • moving the radio <label> tags to fully wrap the radio button unnecessarily
  • Moving the dynamic addScript tags to the top of the <head> area, so that they load before the core jQuery scripts and end up being useless and broken.
  • including the "payment" template folder in your theme (instant fail!)
  • etc
Many of these changes are completely unnecessary and many of them are just wrong.

I do understand that many of you may not find the existing html class/id/etc tags to be prevalent enough. And that is where we need to get some feedback going.

Let me first reference a website I mention quite often when referring to themes. CSS ZenGarden. For those who don't know.. this site is community driven example of how the same html code can be AMAZINGLY revamped and styled with major theme overhauls.. using nothing by css and images.

On the site, the right hand navigation shows a handful of possible changes to the same content, and if you click "View All Designs" you will see over 200 user submitted themes for this same content... proving the resourcefulness of css based theming without changing the html.

I would love to see OpenCart reach this level. And I think a lot of the themes made now are just making changes for the sake of making changes. First of all, I understand that there may not be enough class/id tags.. but that should be as simple as adding new ones. Renaming the existing ones is unnecessary and a recipe for failure.

It is also important to follow the basic Theme developing guidelines for opencart and understand the concept of the "cascading fallback system" that the themes use. Including the "payment" folder in your theme means that any future updates to those files in the default folder will be ignored because the copy in your theme is overriding them. Payment tpl files should always fallback to the default folder so that it always has the latest updates.

Then there are those that port their themes across multiple sites... Shoppica is on Drupal, OpenCart, Blogger, and while I can appreciate the themer doesn't want to have to make different versions of the code for each one separately... there has to be some sort of compromise.

So I'd like to hear some feedback from theme makers on
- What is missing from OpenCart's existing html that you'd like to see?
- What are some ideas to improve transparency across themes for mods and modules
- Why such drastic code changes that often result in the same "layout" as the default

I've tried the best I can to make many of my mods as transparent as possible to themes, using only a single reference tag like "#image", and yet even that simple tag is often removed from custom themes for no good reason. I spend at least 3 hours per day going through support emails that start with

Code: Select all

"I bought your mod, but it isn't working.. I am running Shoppica......"
or sellegance, or shopcart, or some <fill-in-the-blank> extravagant themeforest theme.

I just can't do it anymore, and I know many other code devs feel the same. Many have already sworn off support for Shoppica and other themes. So I think we need to work together and avoid a full developer boycott.

So any feedback is appreciated.
Last edited by Daniel on Wed Jul 24, 2013 12:00 am, edited 11 times in total.
Reason: Made Global

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by d_koev » Sat Oct 13, 2012 8:25 am

Hello Q,

you're generally right. It's really not a good practice. Unfortunately sometimes we are forced to make changes in order to give the theme more uniqueness and compete against each other (theme authors). The main problem is that the system itself have a lot more power than it actually use and we must find a way to use it for our needs. It is really stupid to change the class of a button when you could simply add new one and keep the original, but sometimes we need to make layout changes as this is the only thing that would make realizing our ideas possible.

Other problem in theme development and it is 100% valid for every system, not only OC is that theme buyers want customization options. The purpose of themes is to stand out and be unique. Otherwise everybody would be happy with the default theme. In order to make our themes customizable, we must sometimes change something OR dynamically assign new properties and values. This is where some of the mods fail.

Honestly, while I really appreciate your efforts and contribution to the OC community, I don't really like the concept behind the VQmod approach. From my point of view I would always prefer to use a stand-alone module that doesn't interfere with the basic theme html structure. Don't get me wrong - I am just saying that this coin have two sides. When I am adding a new functionality in my themes, I am always trying to ADD and not CHANGE, but it's not always possible. This is the reason on ThemeForest we clearly state: Theme is sold AS IS and no guarantees for compatibility with already modified systems or plug-ins which doesn't doesn't really "plug in", but trying to brute force the code instead.

Once again, I really hope you don't get me wrong... No one needs a boycott or developers war.

Last but not least - while talking about Shoppica theme, I can assure you it was built especially for OC and ONLY for OC. Any other ports were made by other people who saw the potential of the best selling OC theme and it's great functionality. I know the guys behind Shoppica theme personal and I am sure their only concern is to offer complete user experience without problems if possible.

In two words - may be we must cooperate and find a way to establish standards and good practices for theme AND extension development, but no one can give us 100% guarantee that there will be no problems after all. Also, may be this is a normal period in every system's life-cycle. I can remember there were same problems with WP themes and plug-in compatibility, but everything is now fine and there are standards that no one breaks. I am sure, while OC is gaining popularity, new and new trends would come up and finally solution would be found.

Jeezzzz... my english was seriously tested here, and while it is really not perfect, I hope everything I said is clear and no one get's me wrong. :)

Уеб дизайн и SEO услуги от metaGraphics Design Studio
Check my ShopperLand Premium theme
Check my ModernStore Premium theme


New member

Posts

Joined
Thu Jan 14, 2010 8:03 pm

Post by settysantu » Sat Oct 13, 2012 10:22 am

Hi Qphoria,

Well i agree with you on this, well we designers/developer always will be in hurry to make unique themes but never try to follow rules.

I think all my theme's obey guide lines but will once again have a look at them, are my theme's are also in the sinner box?

User avatar
New member

Posts

Joined
Mon Jan 03, 2011 11:59 am
Location - Hyderabad, India

Post by rph » Sat Oct 13, 2012 12:19 pm

d_koev wrote:Last but not least - while talking about Shoppica theme, I can assure you it was built especially for OC and ONLY for OC.
That makes all the unnecessary, non-standard changes in it that much worse.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by qahar » Sat Oct 13, 2012 4:00 pm

I write a paragraph until decide to delete it, it's not good to cornering each other in this case. So, lets back to the topic :)
Qphoria wrote:So I'd like to hear some feedback from theme makers on
- What is missing from OpenCart's existing html that you'd like to see?
- What are some ideas to improve transparency across themes for mods and modules
- Why such drastic code changes that often result in the same "layout" as the default
I want to suggest few things for short term approach.
  1. Create and publish a consist HTML and CSS ID/ Class attribute that used by OpenCart as part of the "standard approach". So whatever theme, the attribute is available. Just please not to strict with this :)
  2. Provide standard "class suffix" in the body tags represent of useful refference. Some cms do this so it isn't hard to get example.
  3. Introduce "class suffix" input in all OpenCart feature like category, product, information, modules etc. Honestly, this is very useful. Because with single class in the category page we can provide different design. I use this approach in my extension.
  4. Suggest for theme dev, use LessPHP if you want to change stylesheet value dynamicly instead of doing complicate thing.
For long term approach, I'm sure there is more idea from other community user.. ;D

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia

Post by max2tall » Sat Oct 13, 2012 4:34 pm

Found myself looking for the 'like' button ;)

New member

Posts

Joined
Fri Sep 28, 2012 4:19 pm

Post by ogun » Sat Oct 13, 2012 9:42 pm

Qphoria wrote:- What is missing from OpenCart's existing html that you'd like to see?
Personally, I'd like to see the default template use PHP's alternative syntax:

http://www.php.net/manual/en/control-st ... syntax.php

Have been using this in templates (for all sorts of projects) for years and had far less trouble than I used to with regular syntax. It's especially useful when you're working with people who are unfamiliar with PHP, HTML or (more often than not) both - and it's also useful for developers because you can spend less time identifying blocks of code and more time editing it. Here's a quick example:

Regular syntax:

Code: Select all

<div id="welcome">
    <?php if (!$logged) { ?>
        <?php echo $text_welcome; ?>
    <?php } else { ?>
        <?php echo $text_logged; ?>
    <?php } ?>
</div>
Alternative syntax:

Code: Select all

<div id="welcome">
    <?php if (!$logged): ?>
        <?php echo $text_welcome; ?>
    <?php else: ?>
        <?php echo $text_logged; ?>
    <?php endif; ?>
</div>
Both of those are pretty clear - but if you imagine that if/else structure spread out around two large blocks of HTML that also contain lots of other PHP statements and control structures, then the alternative syntax becomes much more readable and easier to debug. For new users or light users (people who want to edit templates but not code), it also gives them a reminder of what sort of control structure they're currently working with and lessens the chances of accidentally deleting/moving those mysterious "<?php } ?>" tags.

I appreciate that some more technical users prefer the familiarity and brevity of regular syntax, but they're a minority heavily outnumbered by people who know just enough about Dreamweaver to be dangerous.
Qphoria wrote:- What are some ideas to improve transparency across themes for mods and modules
I agree with everything qahar said apart from point 4 because I don't know anything about 'LessPHP'. And a documented version of the stylesheet that explained the purpose and position of each id/class would be fantastic - Actually, if it was documented then from that information, someone could even knock up a JS editor for it and themes could be created online.

Bit off-topic, but Opencart's come a very long way since 0.7 (which is when I last saw it). The single ''stylesheet.css' is much clearer and easier to work with than the whole folder full of stuff that was there before - the default template looks great and the admin panel is tons easier to work with.
Qphoria wrote:- Why such drastic code changes that often result in the same "layout" as the default
I think a big part of it is familiarisation - when people are finding their way around a new template for a new project, they often have to modify it to make it fit however they learned (or are learning) to edit HTML/CSS. Personally, I have OCD for accessibility - that usually means rebuilding pages from scratch until I'm happy with the order of the page - which really annoys whoever gave me the page to edit.

Another issue might be people not reading the link Qphoria already posted (which deserves posting again):

http://www.opencart.com/index.php?route ... h=77_43_44

Haven't looked at the templates forum and only just started looking at making (or buying) a template - what sort of problems are the most common? Is there anything that could be done with automated testing - or maybe a series of standard tests/checks that theme authors could run through before releasing?

Also (and hopefully I'm not putting my foot in it by saying this), are the theme authors not supporting their themes? If devs are feeling that they have to spend time on supporting themes, then maybe the extensions/themes library needs an UNSUPPORTED tag so that users can see the theme they're downloading is effectively dead to its author.

One last related thing before I stop rambling - in the admin templates that use tabs (e.g. product editing), could the tabs be on separate lines in the HTML? It would make it much easier for VQMod authors if they only had to add in a new line instead of replacing one.

Active Member

Posts

Joined
Tue Aug 14, 2007 6:04 am

Post by JNeuhoff » Sun Oct 14, 2012 12:49 am

d_koev wrote: Honestly, while I really appreciate your efforts and contribution to the OC community, I don't really like the concept behind the VQmod approach. From my point of view I would always prefer to use a stand-alone module that doesn't interfere with the basic theme html structure. Don't get me wrong - I am just saying that this coin have two sides. When I am adding a new functionality in my themes, I am always trying to ADD and not CHANGE, but it's not always possible. This is the reason on ThemeForest we clearly state: Theme is sold AS IS and no guarantees for compatibility with already modified systems or plug-ins which doesn't doesn't really "plug in", but trying to brute force the code instead.
I wholeheartedly agree with Q's original post, and I wouldn't touch Shoppica for this reason unless the customer is willing to pay good money for adjusting all the other addons he has to use with this theme.

Having said that, quite often a web theme has a need to offer additional features, which usually means that additional controller variables are to be added from e.g. DB queries, and then to be used in the new web theme's template files. This then means to modify controllers and other classes. In fact, almost all my web themes are a bundle of OpenCart core class modififications, plus the templates (only those that have to be different from the default theme!), and modified CSS and images. I am now using my new Override Engine for the task of modifying core classes, as needed for the web theme.

Many OpenCart addons use VQmod and try to cater for non-default web themes for their changes, too. This is bound to break things if a new web theme goes beyond merely changing CSS and images and tries to use its own template files. So I would urge addon contributors to only cater for the default theme and clearly document what needs to be changed when they want to use it with another web theme.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member
Online

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by mandamexico » Sun Oct 14, 2012 8:28 am

I am going to start adding disclaimers on my extensions that read "shoppica theme users will require an additional customization fee".

My Extensions

OpenCart Developer (OCD) Tools

Donate - If I ever helped you.


User avatar
Active Member

Posts

Joined
Mon Jun 29, 2009 10:14 am
Location - Los Angeles, CA

Post by opencart-templates » Sun Oct 14, 2012 5:43 pm

My ideas are:

1. As other has said the default theme could have more class/id to allow more control in CSS without making template changes . Like @Qphoria said csszengarden is a perfect example.
Not to the extent of adding class="p1,p2,etc" but this could make a big difference.

2.

Code: Select all

<br />
these should NOT be used for positioning >:D because it can be impossible to overwrite in CSS, instead give it a class with a margin/padding. A br should be for text line breaks only. The worst pages for this are checkout/cart/login forms. Last time I check the default theme has 300+ <br />

3. Adding a main template which everything inherits from and removing all the duplicates from other templates. A few examples why what we have now doesn't work well:
- Lets say for the design I need to change the positions of the breadcrumbs so that they are below the <h1>. I can't see any way to doing this without copying all of the templates.
- Or for some reason this design needs to change the 3 columns layouts by changing the order that they appear or adding extra <divs> for styling.

I suggest adding a "template/main-page.tpl" that gets included with every page. So something like this:

Code: Select all

<?php echo $header; ?>

<?php echo $column_left; ?>

<?php echo $column_right; ?>

<div id="content">

	<?php echo $content_top; ?>

  	<div class="breadcrumb">
    	<?php foreach ($breadcrumbs as $breadcrumb) { ?>
    		<?php echo $breadcrumb['separator']; ?><a href="<?php echo $breadcrumb['href']; ?>"><?php echo $breadcrumb['text']; ?></a>
    	<?php } ?>
  	</div>

  	<h1><?php echo $heading_title; ?></h1>

        <?php echo $page; ?> // this gets replace by the current template: home.tpl order_list.tpl etc 

  	<?php echo $content_bottom; ?>

</div>

<?php echo $footer; ?>
- This would solve the issue where if a theme wanting to make big changes it would be much easier and only needs to be done in 1 file, not 50+
- I have built my email template extension so work in a similar way to what I am suggesting here.
- In know this idea wont be favourite because it will break compatibility.

4. Another idea not mentioned would be for the opencart team to "check" any new themes/extensions. If approved then they get added to a list of certified extensions or even only available for purchase after approval.
Last edited by opencart-templates on Fri Apr 19, 2013 5:40 am, edited 1 time in total.

Advanced Professional Email Template
Customers Pre-Sale. Inc abandoned cart email
Order Follow-Up Email. Inc request review
Email Validation with ZeroBounce


User avatar
Active Member

Posts

Joined
Mon May 16, 2011 7:24 pm
Location - UK

Post by dunks » Tue Oct 16, 2012 3:04 am

wow very usefull information.. the css validation :)

Ingat Gadget, Ingat DroidLime https://www.droidlime.com/


User avatar
Active Member

Posts

Joined
Wed Apr 20, 2011 1:19 pm
Location - Jakarta - Indonesia

Post by Avvici » Tue Oct 16, 2012 12:55 pm

"I bought your mod, but it isn't working.. I am running Shoppica......"
Good one. Yes, this is true.

Q, I honestly don't think these questions are even warranted:
What is missing from OpenCart's existing html that you'd like to see?
- What are some ideas to improve transparency across themes for mods and modules
- Why such drastic code changes that often result in the same "layout" as the default

Why? Because even if Open Cart was lacking in certain elements to aid in seamless ERROR FREE theme creations when it came to developing themes that worked it's still the developers responsibility to have enough knowledge of an MVCL, javascript, css, and html to make sure things aren't breaking.

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by OpenCart Addons » Tue Oct 16, 2012 10:28 pm

After more than 4 years now in the engineering industry, I see this all the time between the designers (Architects) and the developers (Engineers).

It happens in every industry.

It would be nice to have a more standardized approach. The worst is when you're attempting to add support for a particular theme, and there are inconsistencies between the template files of that theme. It can become very frustrating.


Cheers,
Joel.

Canada's Leading Expert In OpenCart Development & Certified OpenCart Development Partner Image


User avatar
Active Member

Posts

Joined
Thu Nov 24, 2011 10:51 am
Location - Canada

Post by Qphoria » Tue Oct 16, 2012 11:07 pm

ogun wrote:
Qphoria wrote:- What is missing from OpenCart's existing html that you'd like to see?
Personally, I'd like to see the default template use PHP's alternative syntax:

http://www.php.net/manual/en/control-st ... syntax.php


Regular syntax:

Code: Select all

<div id="welcome">
    <?php if (!$logged) { ?>
        <?php echo $text_welcome; ?>
    <?php } else { ?>
        <?php echo $text_logged; ?>
    <?php } ?>
</div>
Alternative syntax:

Code: Select all

<div id="welcome">
    <?php if (!$logged): ?>
        <?php echo $text_welcome; ?>
    <?php else: ?>
        <?php echo $text_logged; ?>
    <?php endif; ?>
</div>
I personally completely disagree. PHP just causes its own confusion by adding alternative methods and the more commonly taught method is the default way that is currently used. There is no real benefit to the alternative method other than it spells out the word instead of using braces. Great for people who are used to visual basic and python, but it isn't the majority way and will just cause problems and more breakage in the long run.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Tue Oct 16, 2012 11:37 pm

A lot of designers just seem dead set against using standard PHP syntax. They always seem to want to use stuff like Smarty and short tags. I don't really get it.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by Avvici » Wed Oct 17, 2012 12:43 am

rph wrote:A lot of designers just seem dead set against using standard PHP syntax. They always seem to want to use stuff like Smarty and short tags. I don't really get it.
Standard Tags <?php ?>
Short Tags <? ?> / <?= $variable ?>
Script Tags <script language=“php”> </script>
ASP Tags <% %>
Standard tags are the de-facto opening and closing tags; they are the best solution for
portability and backwards compatibility, because they are guaranteed to be available
and cannot be disabled by changing PHP’s configuration file.
Short tags were, for a time, the standard in the PHP world; however, they do have
the major drawback of conflicting with XML headers and, therefore, have somewhat
fallen by the wayside. Their other advantage is the availability of the short form
<?=$variable ?> syntax, which allows you to print the result of an expression directly
to the script’s output.
Script tags were introduced so that HTML editors which were able to ignore
JavaScript but were unable to cope with the standard PHP tags could also ignore
the PHP code.

As for snotty ASP USERS ;D :
Nobody quite understands why ASP tags were introduced—however,
if you are so inclined you can turn on this optional configuration option, and you are
free to use them.

Short tags, script tags and ASP tags are all considered deprecated and their use is
strongly discouraged

User avatar
Expert Member

Posts

Joined
Tue Apr 05, 2011 12:09 pm
Location - Asheville, NC

Post by Qphoria » Wed Oct 17, 2012 1:48 am

The biggest problem with php short tags also seems to be that some hosts don't have them enabled so things just break and it isn't clear why.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Wed Oct 17, 2012 7:20 pm

A tad off topic but perhaps a formal coding style guide for developers similar to this would be useful for the community also.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by OCyvon2 » Wed Oct 17, 2012 9:17 pm

Fallback to default is great, but there are about 96 images in the default template files which refer to the default theme. Maybe it is possible to add a asteriks(*) instead of /default/ ?

Now

Code: Select all

<img src="catalog/view/theme/default/image/close.png" alt="" class="close" />
Suggestion

Code: Select all

<img src="catalog/view/theme/*/image/close.png" alt="" class="close" />
and add an alt text generated from language files e.g.

Code: Select all

<img src="catalog/view/theme/*/image/close.png" alt="<?php echo $alt_close; ?>" class="close" />

OpenCartstore
Gebruikersgids (admin handleiding)


User avatar
Active Member

Posts

Joined
Sun Jan 31, 2010 8:00 pm
Location - Zaandam, The Netherlands

Post by Qphoria » Wed Oct 17, 2012 10:40 pm

OCyvon2 wrote:
Suggestion

Code: Select all

<img src="catalog/view/theme/*/image/close.png" alt="" class="close" />
Well we should certainly update it to be

Code: Select all

<img src="catalog/view/theme/<?php echo $this->config->get('config_template'); ?>/image/close.png" alt="" class="close" />
as that will work as it is right now. Tho I'm thinking there's a smoother way to simply assign it to a shorter more convenient variable name.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 28 guests