Yes, you're right on choosing a prefect or well-coded theme to fit every sides of a website.
In that case can you or anyone suggest some themes near 'well-coded' for me?
Thanks again,
Daniel
http://www.smartebuy.com.au/ http://www.myleathers.com.au/ http://www.cctv4oz.com.au/ http://www.origreen.com.au/
It's been a while, but somebody pointed me to this long overdue discussion between Opencart and theme developers. I thought I should share my opinion too..
We used to run an Opencart theme shop called Themedisk. All our themes were coded from scratch, because the HTML used on the default theme was simply not good enough. It did not validate, it was full of tables, and other HTML elements used incorrectly. The obvious option was to redo the HTML completely. Now I know it was naive to hope we can keep updating all our custom themes every time a new Opencart version is released, so after a year or 2 we had to close Themedisk down. It wasn't just because of our custom HTML. It was also because every new Opencart release had its HTML changed a lot and we would have had to update all our themes constantly anyways, and the fact we were getting half finished updates and therefore loads of them didn't help either.
I am happy to see something is finally being done about this, and I really hope the front end of Opencart finally gets sorted and everyone can stick to the default HTML. It will make everyone's lives much easier, especially theme developers. I can see the front end is already looking much more up to date, and mostly is valid HTML, but I am sure the structure of CSS/HTML can still be improved. Also, the default theme should be responsive by now..
Kind Regards,
Igo
To everyone stick to the default HTML makes no sense at all. There're a lot of situations that you got to change the outputted HTML.lvcoded wrote: I am happy to see something is finally being done about this, and I really hope the front end of Opencart finally gets sorted and everyone can stick to the default HTML. It will make everyone's lives much easier, especially theme developers. I can see the front end is already looking much more up to date, and mostly is valid HTML, but I am sure the structure of CSS/HTML can still be improved. Also, the default theme should be responsive by now..
The main problem - that remains unsolved even in the 2.0 version - in my opinion is this fragile, laborious and inflexible templating system. It's not the devs faults or the designers fault, but it's the system fault's.
In Joomla, wordpress and other CMS's you can change everything in the theme/template and there aren't any problem with any extension. I know they are completely different systems, but no system should have this kind of problem where a template/theme brings problems to any extensions.
Unfortunately this not only won't be solved with the 2.0 version but will get a lot worse with the use of bootstrap. Devs will rely even more in the HTML and anyone who doesn't stick to bootstrap (like me) will have a lot of issues with a lot of extensions because the HTML is different from the default.
OC is a great system, but has a really troublesome theming system.
The Joomla's theme system is simple, direct and extreme powerful. The overriding system is just awesome (mainly the modules and components overrides) and the theme can be just as simple or as complex as you need.
This should be the way to go (and of course, iron out any framework dependencies that make the life of a lot of people harder).
Curious: Could you briefly explain how the Joomla theme system works, and why it is supposed to be better than Opencart's theme engine?Qphoria wrote:Yea I'd love to see something like the Joomla theme system in opencart.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
OpenCart itself seems weighted much more for designers than developers. A designer only needs to know some very simple PHP and they can do just about whatever they want. Developers who want to easily override/add template elements are out of luck.
I looked a little through Joomla 3.1. I believe it's supposed to be MVC but the separation between controller and view isn't very strict. There's a good amount of HTML in the controller files and a designer is going to have to be competent with both PHP and OOP to theme.
-Ryan
No way opencart is better to designers. It's a bloody amount of work to get a full theme developed. And to make things worse, any HTML we change can affect an extension or mod.rph wrote:I'd be interested also. I've been doing a lot of research on template and modding systems lately.
OpenCart itself seems weighted much more for designers than developers. A designer only needs to know some very simple PHP and they can do just about whatever they want. Developers who want to easily override/add template elements are out of luck.
I looked a little through Joomla 3.1. I believe it's supposed to be MVC but the separation between controller and view isn't very strict. There's a good amount of HTML in the controller files and a designer is going to have to be competent with both PHP and OOP to theme.
Of course a designer just need basic PHP, it should be this way. PHP is not a front-end language so this should not be required to know it to get a theme developed.
I'm no developer but I can say that develop a template for Joomla is just easier and more consistent than in opencart. You don't need to know a penny about PHP to make a template. Good old HTML is what it takes, unless you want something more.
I usually make a whole template in Joomla in one or two days, but in Opencart it takes 1 or 2 weeks. How can this be good for a designer?
Code: Select all
<html>
<body>
<div class="header">
<?php echo getHeader(); ?>
</div>
<div class="main">
<?php echo getMain(); ?>
</div>
<div class="sidebox">
<?php echo getSideModules(); ?>
</div>
<div class="footer">
<?php echo getFooter(); ?>
</div>
</body>
</html>
One thing that annoys me with opencart modules is that overall "box wrapper" html is inside EACH module tpl file. Instead the module should only hold the html that is specific to the module itself. The theme itself should maintain the "wrapper" code so that all modules match with the current theme. The way it is now, if I using the default "box" wrapper in my module tpl file, and another theme uses a completely different box design, it doesn't match.
So the column_right.tpl file should be specific to the theme and instead of this:
Code: Select all
<?php if ($modules) { ?>
<div id="column-right">
<?php foreach ($modules as $module) { ?>
<?php echo $module; ?>
<?php } ?>
</div>
<?php } ?>
Code: Select all
<?php if ($modules) { ?>
<div id="column-right">
<?php foreach ($modules as $module) { ?>
<div class="box">
<div class="box-heading"><?php echo $heading_title; ?></div>
<div class="box-content">
<?php echo $module; ?>
</div>
</div>
<?php } ?>
</div>
<?php } ?>
Perhaps flexible is a better term. Plus a huge amount can be achieved through CSS changes.intersect wrote:No way opencart is better to designers. It's a bloody amount of work to get a full theme developed.
PHP's templating lineage is still very much there. But my point is that Joomla seems to require you not only know more PHP, it requires you to know object-oriented programming too.Of course a designer just need basic PHP, it should be this way. PHP is not a front-end language so this should not be required to know it to get a theme developed.
I might be looking in the wrong spot but the files in /templates/[TEMPLATE]/html/ are a heavy mixture of PHP and HTML, including stuff like instantiating objects in the HTML block and a lot of controller-like functionality at the head of the file. I know how designers complain about simple echo statements so I can't imagine areas like this:
Code: Select all
<p class="readmore">
<a href="<?php echo $link; ?>">
<?php if (!$params->get('access-view')) :
echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE');
elseif ($readmore = $this->item->alternative_readmore) :
echo $readmore;
if ($params->get('show_readmore_title', 0) != 0) :
echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
endif;
elseif ($params->get('show_readmore_title', 0) == 0) :
echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE');
else :
echo JText::_('COM_CONTENT_READ_MORE');
echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
endif; ?></a>
</p>
-Ryan
Two advantages I see are that it makes it easier to look for errors if HTML for a single element isn't split up in multiple locations plus it allows more flexibility for module developers. An idea I really like is having required id/classes in themes like "oc_box". That way a developer knows they'll be using the same style while allowing for their own customization.Qphoria wrote:One thing that annoys me with opencart modules is that overall "box wrapper" html is inside EACH module tpl file.
-Ryan
Oc's templating is not flexible, believe me. CSS has its limits, there're just a certain amount of modification that you can do without have to resort to hacks, which is a really bad idea. Also, if you try to modify just the CSS you'll not get to use something like inuit.css or even some jQuery plugins. The HTML got be flexible.rph wrote: Perhaps flexible is a better term. Plus a huge amount can be achieved through CSS changes.
The HTML folder keeps the overrides for the template, it's optional and you'll just need something as complex as this if you're changing something like a behavior of the system. 98% of the cases you won't need nothing more complex thanrph wrote: PHP's templating lineage is still very much there. But my point is that Joomla seems to require you not only know more PHP, it requires you to know object-oriented programming too.
I might be looking in the wrong spot but the files in /templates/[TEMPLATE]/html/ are a heavy mixture of PHP and HTML, including stuff like instantiating objects in the HTML block and a lot of controller-like functionality at the head of the file. I know how designers complain about simple echo statements so I can't imagine areas like this:
are particularly comprehensible.Code: Select all
<p class="readmore"> <a href="<?php echo $link; ?>"> <?php if (!$params->get('access-view')) : echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE'); elseif ($readmore = $this->item->alternative_readmore) : echo $readmore; if ($params->get('show_readmore_title', 0) != 0) : echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit')); endif; elseif ($params->get('show_readmore_title', 0) == 0) : echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE'); else : echo JText::_('COM_CONTENT_READ_MORE'); echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit')); endif; ?></a> </p>
Code: Select all
<?php if($this->countModules('any-module-position')) : ?>
Do whatever you need
<?php endif; ?>
Here the whole code of a template I've done in Joomla:
Code: Select all
<?php
/**
* @copyright Copyright (C) 2013 Intersect. All rights reserved.
*/
defined('_JEXEC') or die;
$app = JFactory::getApplication();
$doc = JFactory::getDocument();
$this->language = $doc->language;
$this->direction = $doc->direction;
// Unset Unused Scripts
unset($this->_scripts['components/com_k2/js/k2.js?v2.6.6&sitepath=/
']);
// Add Stylesheets
$doc->addStyleSheet('templates/'.$this->template.'/stylesheet/style.css');
// Add Scripts
$doc->addScript('templates/' . $this->template . '/javascript/custom.modernizr.js', 'text/javascript');
?>
<!DOCTYPE html>
<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <![endif]-->
<!--[if IE 7]> <html class="no-js lt-ie9 lt-ie8" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <![endif]-->
<!--[if IE 8]> <html class="no-js lt-ie9" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"><![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <!--<![endif]-->
<head>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<jdoc:include type="head" />
</head>
<body>
<!-- Header -->
<header>
<div class="row">
<div class="small-9 large-4 columns">
<!-- Logo -->
<div id="logo">
<a href="<?php echo $this->baseurl ?>" id="taximud" title="TaxiMud do Brasil">TaxiMud do Brasil</a>
</div>
</div>
<div class="small-3 large-8 columns">
<!-- Menu -->
<div class="menu-container">
<div class="menu-icon"><a href="#"><i class="icon-menu"></i></a></div>
<nav>
<jdoc:include type="modules" name="menu" style="none" />
<ul id="search">
<li class="heading-flyout"><a href="#"><i class="icon-search"></i></a>
<div class="content-flyout"><jdoc:include type="modules" name="search" style="none" /></div>
</li>
</ul>
</nav>
</div>
</div>
</div>
</header>
<!-- End Header -->
<div class="message" id="message">
<jdoc:include type="message" />
</div>
<?php if($this->countModules('tools')) : ?>
<div id="tools">
<jdoc:include type="modules" name="tools" style="well" />
<div class="tool-icon">
<a href="#" class="close-tools" title="Ferramentas"><i class="icon-menu"></i></a>
</div>
</div>
<?php endif; ?>
<?php if($this->countModules('slideshow')) : ?>
<!-- Slideshow -->
<aside id="slideshow">
<jdoc:include type="modules" name="slideshow" style="well" />
</aside>
<!-- End Slideshow -->
<?php endif; ?>
<?php if($this->countModules('highlight')) : ?>
<!-- Highlight -->
<div class="row" id="highlight">
<div class="small-12 large-12 columns">
<article>
<jdoc:include type="modules" name="highlight" style="none" />
</article>
</div>
</div>
<!-- End Highlight -->
<?php endif; ?>
<!-- Content -->
<div class="row">
<div class="small-12 large-12 columns">
<section class="content">
<jdoc:include type="component" />
</section>
</div>
</div>
<!-- End Content -->
<?php if($this->countModules('clients')) : ?>
<!-- Bottom Modules -->
<section>
<div class="row" id="clients">
<div class="small-12 large-12 columns">
<jdoc:include type="modules" name="clients" style="well" />
</div>
</div>
</section>
<!-- End Bottom Modules -->
<?php endif; ?>
<?php if($this->countModules('news')) : ?>
<!-- Bottom Modules -->
<section>
<div class="row" id="news">
<div class="small-12 large-12 columns">
<jdoc:include type="modules" name="news" style="well" />
</div>
</div>
</section>
<!-- End Bottom Modules -->
<?php endif; ?>
<!-- Footer -->
<footer>
<div class="row">
<div class="small-12 large-4 columns" id="footer1">
<jdoc:include type="modules" name="footer1" style="well" />
</div>
<div class="small-12 large-4 columns" id="footer2">
<jdoc:include type="modules" name="footer2" style="well" />
</div>
<div class="small-12 large-4 columns" id="footer3">
<jdoc:include type="modules" name="footer3" style="well" />
</div>
</div>
<!-- Login Button -->
<div id="login-button">
<a href="index.php/login" title="Login"><i class="icon-user"></i></a>
</div>
<!-- End Login Button -->
</footer>
<!-- End Footer -->
<jdoc:include type="modules" name="debug" style="none" />
<script src="/taximud/templates/taximud/javascript/jquery-1.9.1.min.js"></script>
</body>
</html>
You make a good point.. I hadn't dug that far to realize there was a deeper structure.rph wrote: I know how designers complain about simple echo statements so I can't imagine areas like this:
are particularly comprehensible.Code: Select all
<p class="readmore"> <a href="<?php echo $link; ?>"> <?php if (!$params->get('access-view')) : echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE'); elseif ($readmore = $this->item->alternative_readmore) : echo $readmore; if ($params->get('show_readmore_title', 0) != 0) : echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit')); endif; elseif ($params->get('show_readmore_title', 0) == 0) : echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE'); else : echo JText::_('COM_CONTENT_READ_MORE'); echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit')); endif; ?></a> </p>
We'll just have to agree to disagree. Having so much of the view locked in the controller is limiting to me. (Commingling of controller elements in the template isn't ideal either.) I'd also add the large variety of OpenCart themes at themeforest.net shows significant versatility in what can be achieved.intersect wrote:Oc's templating is not flexible, believe me.
The main template is very nice but it still requires solid PHP and OOP knowledge so I'm not sure why you'd disagree there. It's dangerous inserting code you don't understand. The simple areas doesn't change the fact there are highly complex ones, too.Here the whole code of a template I've done in Joomla
-Ryan
Just because people can do various kind of templates doesn't mean it's a good or even flexible system. The are (were?) a lot of people that use OSCommerce, so is it good?rph wrote:We'll just have to agree to disagree. Having so much of the view locked in the controller is limiting to me. (Commingling of controller elements in the template isn't ideal either.) I'd also add the large variety of OpenCart themes at themeforest.net shows significant versatility in what can be achieved.intersect wrote:Oc's templating is not flexible, believe me.
The main template is very nice but it still requires solid PHP and OOP knowledge so I'm not sure why you'd disagree there. It's dangerous inserting code you don't understand. The simple areas doesn't change the fact there are highly complex ones, too.Here the whole code of a template I've done in Joomla
Maybe the oc's templating system is good for devs, but for designers it's not. It's over complex and extremely laborious. There're a lot of code repetition, which is bad and prone to error, the most used modification system (vQmod) makes a complicated situation when you need to change the HTML and you can only override the default template and not the template in use (this is a really useful resource).
When a designer/front-end coder is building a template, he/she is not meant to mess with the controller or model, he/she is supposed to change just the view, or am I missing something?
Isn't this one of the points of the MVC(L)?
Why Joomla's template need solid PHP and OOP knowledge? As you can see the template itself need as few php as possible, you're just echoing the component and modules. Why is this dangerous? I'm really not understanding... Take just some overrides as example is not the best way to evaluate it, as this is not required or even needed. And Joomla 3.x you can override a lot more than the modules, you have to use and understand the system to have a position about it.
To be honest, I use Joomla a lot and it has a lot of problems, really, but to the day I found few systems that has a templating system as pleasant and powerful to use as Joomla. Even Wordpress requires a lot more work and php knowledge than Joomla.
2) Developers have no template override method. The high flexibility of the view also encourages designers to change things they shouldn't. That in turn can make overriding with an unofficial system like vQmod difficult for developers. I'll also add that vQmod has been able to make changes to multiple templates through wildcards for a long time now.
3) Because of OpenCart's fallback system you can build an entirely unique theme with CSS changes and a couple custom template files. The default template does need some rewriting and standardization to help further facilitate this but the system itself is sound. If you're rewriting everything from scratch you're doing it wrong.
4) I could understand if Joomla had a simple, dedicated display object for designers with output properties (along the lines of $display->title or $display->link['url']) but it does all kinds of crazy stuff like instantiate objects and run methods in the template. That means designers have to laboriously ensure everything is exactly copied over and must be able to troubleshoot OOP programming issues. This also has the side effect of making code refactoring a complete nightmare since it's not the controller building the output. Start changing methods and now everyone's templates have to be updated.
-Ryan
Ok, I can't argue with you because I don't have that much knowledge in development. I don't know if you're looking a Joomla's "default" template or a template framework. If it's a template framework, you should avoid it. People tend to over complicate things and even change the behavior of the system. Don't ask me why....rph wrote:1) OpenCart is flexible because there's separation of view and controller. This means there's no area a designer can't change, if they choose to (with the exception of a very minor bit of pagination code). Joomla does not have complete separation. Not even close. Saying "I don't want to change those areas" isn't an argument against that. It's just saying you're happy to ignore it.
2) Developers have no template override method. The high flexibility of the view also encourages designers to change things they shouldn't. That in turn can make overriding with an unofficial system like vQmod difficult for developers. I'll also add that vQmod has been able to make changes to multiple templates through wildcards for a long time now.
3) Because of OpenCart's fallback system you can build an entirely unique theme with CSS changes and a couple custom template files. The default template does need some rewriting and standardization to help further facilitate this but the system itself is sound. If you're rewriting everything from scratch you're doing it wrong.
4) I could understand if Joomla had a simple, dedicated display object for designers with output properties (along the lines of $display->title or $display->link['url']) but it does all kinds of crazy stuff like instantiate objects and run methods in the template. That means designers have to laboriously ensure everything is exactly copied over and must be able to troubleshoot OOP programming issues. This also has the side effect of making code refactoring a complete nightmare since it's not the controller building the output. Start changing methods and now everyone's templates have to be updated.
But let's get back to Opencart. I know you can build a oc's theme just with few overriding and focusing mainly in the CSS, that's as clear as possible, but it's not always enough. There are a lot of situation where you have to change HTML. 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"? You've got to put the breadcrumb html (the variable output in this case) in the bottom. Now, just do that to more 10 tpl files and you're done. What if I want the search module in the footer? I can't to that unless I add some code outside of the View. I can't call the modules I need in the places I need. Isn't this a limitation? A pretty big one, to be honest.
How about using OOCSS in oc? Or BEM? How can I do that without change the HTML? I'll probably even have to remove some id's for the sake of consistency and good (front-end) code... If I do this, will the majority of vQmods work? Probably not.
Why can't I build a theme from the scratch? It's the same as saying you can't build a module from the scratch. This is not fair to front-end coders. Why just the developers can have good code?
I like to build my own code because I know how things work and I need good and consistent code. When you have to make pages work in almost every browser out there, mobile or not, you have to get to change the html as you need. I can't reuse the default's code in most of the situation because it's outdated, is really messy, has no comments and is not even indented.
I don't know what developers think about this, but in my experience, a templating system should allow a designer or a front-end coder to do whatever they need to, as long as they don't change the core of the system. It shouldn't deny changes in html. It shouldn't limit where they could put the elements. It shouldn't be as laborious as have to change more than 10 files just to change a small detail.
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. It's great that the inwards of the system work as they should, but there're a lot of things that should be optimized so we can build really awesome theme, with good (front-end) code, without have to resort to hacks. The sad thing is that the new version (2.0) won't have any improvement in this area, it's just the same old oc's theme with Bootstrap and a bit better code. It'll just make things worse for the ones who doesn't use it or doesn't like it. Now you'll have to clean up the code, just to make things work the way they should...
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.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"? You've got to put the breadcrumb html (the variable output in this case) in the bottom. Now, just do that to more 10 tpl files and you're done. What if I want the search module in the footer? I can't to that unless I add some code outside of the View. I can't call the modules I need in the places I need. Isn't this a limitation? A pretty big one, to be honest.
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".intersect wrote: How about using OOCSS in oc? Or BEM? How can I do that without change the HTML? I'll probably even have to remove some id's for the sake of consistency and good (front-end) code... If I do this, will the majority of vQmods work? Probably not.
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.Why can't I build a theme from the scratch? It's the same as saying you can't build a module from the scratch. This is not fair to front-end coders. Why just the developers can have good code?
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 theI like to build my own code because I know how things work and I need good and consistent code. When you have to make pages work in almost every browser out there, mobile or not, you have to get to change the html as you need. I can't reuse the default's code in most of the situation because it's outdated, is really messy, has no comments and is not even indented.
Code: Select all
<td><select>
</select></td>
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.I don't know what developers think about this, but in my experience, a templating system should allow a designer or a front-end coder to do whatever they need to, as long as they don't change the core of the system. It shouldn't deny changes in html. It shouldn't limit where they could put the elements. It shouldn't be as laborious as have to change more than 10 files just to change a small detail.
The php code for price is
Code: Select all
<?php echo $price; ?>
Code: Select all
<?php echo '<b>' . $price . '</b>'; ?>
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.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. It's great that the inwards of the system work as they should, but there're a lot of things that should be optimized so we can build really awesome theme, with good (front-end) code, without have to resort to hacks. The sad thing is that the new version (2.0) won't have any improvement in this area, it's just the same old oc's theme with Bootstrap and a bit better code. It'll just make things worse for the ones who doesn't use it or doesn't like it. Now you'll have to clean up the code, just to make things work the way they should...
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>
Code: Select all
<div class="boxLeft">
<p><?php echo $heading_title; ?></p>
<div>
--module_code_call_goes_here--
</div>
</div>
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.
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
template/common/header.tpl
template/common/footer.tpl
stylesheet/stylesheet.css
I edited the header so OC uses my new stylesheet and not the default. I also added a wrapper div round the left, right and center columns. The wrapper div is opened at the bottom of the header.tpl file. I edited the footer file so it closes the wrapper div before actually reaching the footer. In total I have spent 20 minutes working with HTML, and roughly 3-4 hours on styling and moving things around on the CSS file.
I think it's safe to say that building for templates for OpenCart is pretty effortless unless you complicate it.
Attachments
preview.png (554.88 KiB) Viewed 15847 times
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
Users browsing this forum: No registered users and 26 guests