OpenCart Community

intersect wrote:Suppose you need for some reason the breadcrumbs in the bottom part of the content's container. How do you do that without any css "hack"?

I can't call the modules I need in the places I need. Isn't this a limitation?

Why can't I build a theme from the scratch?

I don't know if you have ever needed to build a whole theme in oc, but if you did or do you'll see how troublesome, tedious, inflexible and time consuming it is.

Qphoria wrote:The biggest issue I see with OpenCart theming is like I said above where the individual module code should only have the "module" code in it and not the box structure. That should be controlled by the theme and the module data should be theme agnostic.

Qphoria wrote: I'm no theme expert. But I know that the <div class="breadcrumb"> exists and why can't you use CSS to move that? Forget the fact that you and I both know that the breadcrumb appears at the top of the html, when the page is rendered, it is all considered one-piece. You can move it around all you like using CSS and positioning or margins. Changing 10 tpl files or a few lines in CSS seems like a no-brainer.

Qphoria wrote: Then why do it? First off BEM and OOCSS are like completely different frameworks. You could say "what if I code in ASP instead of PHP".. What if I used Smarty? There is no need to use OOCSS ... it doesn't give you any better options than standard css. It is a personal preference in trendy coding but It only works if you are designing a personal site or building your own blog or ecommerce system and starting with that as your foundation. You said it yourself, when people try to make their own frameworks in Joomla it turns out badly... That is because it is unnecessary and goes against the grain for the sake of being different. It gives no benefit in the end result. In the end, everything comes out as standardized HTML and CSS. That's like adding Prototype or Mootools instead of just sticking with jQuery.. there's just no need to mix or switch to different frameworks just because it is trendy at the moment. In the end plain ol' html and css are still the foundation of any web page and don't get "old".

Qphoria wrote: Because like any platform you need to follow the standards that are already set up. I'm not saying the default theme is perfect, but it has a good level of id and class tags. It follows the rules of a single id name per page. It may not be semantic but that is not a show stopper and being semantic is almost always impossible for more complex setups and is typically considered as more of an ideal than a usable practice.

Qphoria wrote: Well If there is one thing to be said about Daniel's code, it's that it is mostly ALWAYS indented. php files have a single tab, tpl files have 2 spaces, but they are almost all indented at the html level (ignore the php in the tpl files as that is purposely non-indented because it follows the html as the master). The only places I've seen it a little off is on some of the

Code: Select all

<td><select>
</select></td>

being on the same line. But even still, the indents are there.

Qphoria wrote: I'll agree that some recent changes (like moving the breadcrumb from the common header into each individual page... ridiculous) weren't the best ideas. But again, most of them are classed correctly and can be adjusted with CSS. But the bigger focus on this topic was the themes that change the actual standard tag name to something similar or use poor coding practices. Things like the product page, id="price" as you can guess would be a pretty important factor in a lot of mods. Changing it to "s_price" or "priceStandard" or "normalPrice" is just unnecessary.
The php code for price is

Code: Select all

<?php echo $price; ?>

Changing it to

Code: Select all

<?php echo '<b>' . $price . '</b>'; ?>

is just ridiculous. But it is this type of ridiculous code that I have to deal with all the time when people have issues with my options mods and price update mods. I spend at least 2 hours a day logging into people's ftps to find out that the price tag was changed or the class or they changed it from id="price" to class="price" or id="image" was removed or changed to id="mainImg" or some other unnecessary change.

Qphoria wrote: Well now see, bootstrap is a popular theme framework. It requires ALL elements be classed and I would assume would force good theming practice. Why wouldn't this be better? Aside from the overall theme structuring issues (like the breadcrumb issue I mentioned) the end result of css and html should be a lot cleaner and lot easier to use more CSS changes.

Qphoria wrote: OpenCart's theme framework of having separate controller code is a lot like phpbb, wordpress, etc.There is a header.tpl file that handle's the code from the header controller. There is a column left, right, footer all matching their associated controller files. This isn't something new. It is standard MVC style theming. As rph said, Joomla appears to be adding html directly into controller files and then loading that data with a function call. But that defeats the purpose of MVC.

The biggest issue I see with OpenCart theming is like I said above where the individual module code should only have the "module" code in it and not the box structure. That should be controlled by the theme and the module data should be theme agnostic. That would allow one theme to have a wrapper like this:

Code: Select all

<div class="box">
   <div class="boxTop"><?php echo $heading_title; ?></div>
   <div class="boxMid">
  
  --module_code_call_goes_here--

   </div>
   <div class="boxBot"><?php echo $heading_title; ?></div>
</div>

and another theme could have

Code: Select all

<div class="boxLeft">
  <p><?php echo $heading_title; ?></p>
  <div>

  --module_code_call_goes_here--

  </div> 
</div>

and the actual mod contents will display correctly on both themes because it only has its own code to worrry about. The way it is currently in opencart means each theme requires its own tpl file with the box wrapper code specified and it's a pain for module devs. So we have to adapt module tpl files to each crazy ass custom theme which means more work for us.

But theme devs need to follow the standards of the platform, even if you don't like it. Module makers also have to follow the standards. You think we wouldn't prefer a single file for a module instead of a minimum of 6? When you are making car parts for a Chevy then you can't expect the Honda parts to fit.

JNeuhoff wrote:pedro1993: I totally agree with you, creating Opencart themes is easy and does not take excessive amount of time. Only poorly implemented themes like shoppica will break 3rd party extensions.

rph wrote: It's doable with CSS positioning as others have mentioned. I don't think you'd find many people that disagree breadcrumbs should get their own template and currency, language, and search should be set up as true modules instead of the half-state they're in. These are simple matters of implementation rather than architecture, though. They're also a tiny part of any theme.

rph wrote: No, that's how MVC works. It's the controller which decides the view. Joomla really blurs the lines here which would confuse a lot of people. If it was the template which decided what to display then there would be no way to remove or add a module without editing template files.

There's an argument to be made for a layout install system so users don't have to manually set up all their modules with a template (if it needs it), but the layout system itself is a good one since it keeps the modules nicely decoupled and portable.

rph wrote: I guess I don't follow what the limitation is here. You can rewrite all the HTML/CSS you want. (Weren't you just saying it was too much work rewriting everything?)

rph wrote: If a designer is experienced with the system and can't get a customized OpenCart theme made in a day or two they should probably re-examine their workflow.

intersect wrote: I totally agree with you. A good front-end developer will even avoid using id's for style and will use them just for js. But if this happens a lot, shouldn't we being discussing (as we are ) what can be changed or improved in the system itself, so it wouldn't happen anymore? I don't think this is a problem where just the theme developers are guilty, I think that this is a big situation where people are just point fingers at each other without seek any (real) solution. Maybe improve the theme system in a way the theme developers don't feel the need to to such strange thing? Or that would make this almost impossible to do... I don't know.

rph wrote:

Qphoria wrote:The biggest issue I see with OpenCart theming is like I said above where the individual module code should only have the "module" code in it and not the box structure. That should be controlled by the theme and the module data should be theme agnostic.

Why not enforce mandatory class/id names instead?

intersect wrote: If you're just "skinning" it, it's really easy. Try to change a bit of the page's structure and you'll see how bad this can be. Anything that is not in the footer or header and has to be changed in the HTML will be a lot of work. Try it yourself and you'll understand...

JNeuhoff wrote:

intersect wrote: If you're just "skinning" it, it's really easy. Try to change a bit of the page's structure and you'll see how bad this can be. Anything that is not in the footer or header and has to be changed in the HTML will be a lot of work. Try it yourself and you'll understand...

I normally use the Override Engine for this kind, as it also involves changes to the controllers and possibly language files for e.g. the header or footer. In future projects, I'll also consider the usage of DOM or other HTML modifying tools in the overridden controller (the latter does needed changes to the HTML output). If my web theme is more than a simple skinning, I usually create a whole bundle of overriden controller and model classes and language files, along with the theme's CSS, images, and TPL files.

However, in general a web theme is not supposed to do deep structural changes to Opencart.

intersect wrote: I'm not referring to behaviors of the system or anything else, just plain "old" HTML (of course, with the proper variables, functions and so on...). As an example, the product page can have the image in the top with full width, the title right under the image, the price in the middle and so on. You can do a lot of things with just HTML. That's the structure that I'm referring to, the page's structure.

JNeuhoff wrote:

intersect wrote: I'm not referring to behaviors of the system or anything else, just plain "old" HTML (of course, with the proper variables, functions and so on...). As an example, the product page can have the image in the top with full width, the title right under the image, the price in the middle and so on. You can do a lot of things with just HTML. That's the structure that I'm referring to, the page's structure.

I see. Plain old HTML structure change is usually just a matter of including the structually modified product.tpl file in the theme's product.tpl. I make sure to keep id="..." or class="..." attributes when they are needed in Javascript/JQuery. Never considered this to be a time-consuming or difficult issue.

Qphoria wrote: Also not using the fallback system. This is a huge feature that I personally added back in v0.7.9 and pleaded with Daniel to keep in 1.x. But it is so often ignored. There is plenty of documentation about it. But themers are again ignorant to developer notes. It results in a waste of space, and more work for the developer and end users to constantly patch the theme because a bug fix was made to the payment tpl file or some other less commonly altered tpl file that their theme is unnecessarily overriding because they blindly cloned the entire default folder instead of only the files that changed.

pedro1993 wrote:Can I make a small suggestion that really annoys me in OpenCart right now.

Although this doesn't have anything to do with the front end theme, the admin theme is quite irritating when trying to add a tab using vQmod.

<file name="admin/view/template/common/header.tpl" error="skip">
	<operation error="skip">
		<search position="replace"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
		]]></search>
		<add trim="true"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
			<a href="#new-tab">My New Tab</a>
		]]></add>
	</operation>
</file>

Johnathan wrote:

pedro1993 wrote:Can I make a small suggestion that really annoys me in OpenCart right now.

Although this doesn't have anything to do with the front end theme, the admin theme is quite irritating when trying to add a tab using vQmod.

I'm not disagreeing that the HTML is messy and could use some improvement, but you can still easily add a tab using vQmod in that block of code. You just have to do it like this:

Code: Select all

<file name="admin/view/template/common/header.tpl" error="skip">
	<operation error="skip">
		<search position="replace"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
		]]></search>
		<add trim="true"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
			<a href="#new-tab">My New Tab</a>
		]]></add>
	</operation>
</file>

intersect wrote:After much (good) discussion, I kept thinking in how the oc's theming system could be improved and I've made a little draft of how it could be to be easier to deal with, for designers and developers.
It's not extensive and is really far from perfect, but it has some ideas to make it better and less prone to problems:

Code: Select all

<!DOCTYPE html>
<html>
<head>
    <!--
        Why not simplify things up? This would echo all the metatags, css's and
        javascripts. This way the designer could add the scripts and styles
        manually or add directly to the system. Something like:
        $something->addStyleSheet('stylesheet/style.css').
        The second option would be great because someone could easily create some
        sort of extension that would merge and minify css's and scripts. It could
        even be built in into the platform itself.
    -->
    <?php echo $head; ?>
</head>
<body>
    <header>
        <img src="<?php echo $logo; ?>" alt="">
        <?php echo $search; ?>
        <?php echo $menu; ?>
    </header>

    <!--
        The breadcrumbs, search, menu and some other things would turn into
        modules. This way a designer could change its position, wrapper and
        anything outside the core output of it without affect anything and would
        make everyone life a lot easier.
    -->
    <?php echo $breadcrumbs; ?>
    <!--
        Everything that would be echoed should have the cleanest output possible.
        Just a div with the class to indicate the kind of element (like module),
        the class to identify it and maybe an ID when needed. This way all the
        wrappers, classes and so on    could be whatever the designer wants or needs,
        but everything could be    still reached by developers in any kind of
        extension.
    -->
    <aside><?php echo $column_top; ?></aside>
    
    <aside><?php echo $column_left; ?></aside>
    
    <!--
        All the pages tpl's would echo here, instead of have it's own full page;
        This by itself, would make things a lot easier and could avoid a lot of
        problems between extensions (vQmod or not) and themes.
        If an "one page model" is not possible, could there be a "content.tpl"
        file. This would not be the ideal situation, but would help a lot
        already.
     -->
    <article><?php echo $content; ?></article>

    <!--
        The modules could have the less code possible and should have just the
        class needed to have the basic style and the class to identify the module.
        For instence, take the account module. In the 2.0 version it would output
        like this:

        <div class="sidebar">
          <ul class="nav nav-tabs nav-stacked">
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        Instead it could be much simpler, like this:

        <div class="oc-module account">
          <ul>
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        This way, the designer could put the wrapper in the module position and target
        all the modules with basic styling and still have unique styles for the
        modules he/she wants. The developer would have no problem using vQmod or any
        modification system, because they would target the module itself and not the
        theme.
        Also, the theming system would be framework agnostic (css/javscript framework),
        even if it has any framework bundled.
    -->
    <aside><?php echo $column_right; ?></aside>
    <aside><?php echo $content_bottom; ?></aside>
    
    <footer><?php echo $footer; ?></footer>
</body>
</html>

Did I made myself clear? If there's any doubt about the proposal, please tell me if there's any.
I know that the oc itself would have to be changed to accomplish this and that if it would even be done, this would happen in version 2.5 or 3.0. Even that way, I would like to know if it is viable and if it wouldn't compromise the MVC structure or anything else in oc. What do you think? Would this help in this situation in your opinion?