Yes -- give it a try and you'll see how it works. You don't have to use an entire line in vQmod, you can also add code after the line by using the "after" position and just a piece of the line.pedro1993 wrote:Even if all the tabs are confined within the one line?Johnathan wrote: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: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.
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>
This is what I was saying earlier in the thread.. this is how opencart USED to be in 1.2.9 and older. There used to be a common "layout.php" file instead of the "build-by-children" method. Here's an old PDF file I created back then that breaks it down: http://forum.opencart.com/download/file.php?id=3786intersect 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:Did I made myself clear? If there's any doubt about the proposal, please tell me if there's any.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>
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?
it was changed because it technically allowed greater template designing. The problem is the more bells and whistles you add, the more robust you make it, the harder it becomes to adapt to it. The layout system in OpenCart currently is extremely complex because of the power you have to override layouts and stuff. You can't do that with a common layout.php file like joomla has unless you keep multiple copies of the layout.php... which is what we used to do. But it was very static and not dynamic like the current system.
I personally was against the new (current) children based design back then. But I'm not a themer. Other themer's found that they liked the new layout system so it stuck. I almost convinced Daniel to change it back in 1.5.0 and he did for an early alpha build... but then he said it wouldn't work right so he changed it back before release. I'm not sure what wasn't working but que sera, sera
Good to know.pedro1993 wrote:It wouldn't compromise the MVC structure as the Controller only calls on the view, and defines the variables sent to the View.
It would be pushing OpenCart to a more HTML5 and less traditional framework. My only concern would be that too much change in OpenCart's template will cause an outbreak in extension, modules and vQmods breaking.
It's a toughy
I'd say a more modern and HTML5 compliant framework
This would be good and in my opinion needed. A platform has to modernize itself.
If it were implemented in a sub-version (like 2.1.x) it would be a huge problem, but in a whole new version, I don't think so. The new 2.0 version will be incompatible with most of the extensions and no theme from the 1.5.x will work in it anyway. So this wouldn't be a problem if it were discussed and planned.
Sorry, forgot to mention that it looked as you mentioned. I did not know the whole story neither that the system was easier to deal with. I started to use oc in 2011 in the 1.5 branch.Qphoria wrote: This is what I was saying earlier in the thread.. this is how opencart USED to be in 1.2.9 and older. There used to be a common "layout.php" file instead of the "build-by-children" method. Here's an old PDF file I created back then that breaks it down: http://forum.opencart.com/download/file.php?id=3786
it was changed because it technically allowed greater template designing. The problem is the more bells and whistles you add, the more robust you make it, the harder it becomes to adapt to it. The layout system in OpenCart currently is extremely complex because of the power you have to override layouts and stuff. You can't do that with a common layout.php file like joomla has unless you keep multiple copies of the layout.php... which is what we used to do. But it was very static and not dynamic like the current system.
I personally was against the new (current) children based design back then. But I'm not a themer. Other themer's found that they liked the new layout system so it stuck. I almost convinced Daniel to change it back in 1.5.0 and he did for an early alpha build... but then he said it wouldn't work right so he changed it back before release. I'm not sure what wasn't working but que sera, sera
I don't understand why this happened and why this is still as it is now. Honestly, I never saw any theme that uses different layouts per pages, at least not in a relevant way. Add a class to the body of the page with the kind of page is much more useful. Something like this:
Code: Select all
<body <?php echo $pagename ?>
The only way for this to not violate MVC would be to rewrite the controllers to dump every module into the view.pedro1993 wrote:It wouldn't compromise the MVC structure as the Controller only calls on the view, and defines the variables sent to the View.
There's no reason to replace a flexible, dynamic system with an inflexible, bloated one.
-Ryan
Well as it is now, people do like the have side modules on their home page, and maybe no modules on the checkout page.intersect wrote: I don't understand why this happened and why this is still as it is now. Honestly, I never saw any theme that uses different layouts per pages, at least not in a relevant way.
But yea this could still be done the same way with a layout style page. I guess it's just preference. Wordpress, phpbb, and a few others use same method that OpenCart uses... multiple pieces combined together by calling them as children from the main controller content.
The old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.rph wrote: The only way for this to not violate MVC would be to rewrite the controllers to dump every module into the view.
There's no reason to replace a flexible, dynamic system with an inflexible, bloated one.
Reasons please, we need to understand why it would be inflexible, not dynamic and bloated.rph wrote: There's no reason to replace a flexible, dynamic system with an inflexible, bloated one.
The reasons I think it would be nice is not only because it would be fast to deploy a theme and much easier to deal with, but also to make it easier to built completely different templates without have incompatibilities with mods because of the changes.
With the old/new system proposed, it would require just a well thought html structure for the outputted HTML of the pages (contents) and modules, in a way that anyone would hardly need or want to change them. When needed, one could just override them with vQmod or any other system and it wouldn't cause any harm or incompatibilities.
Also, themes would be much more compatibles with different versions because the custom parts would be all in the main template page and modifications to the system between versions wouldn't affect them. In every (or almost) update in the 1.5 branch you had to update your theme too because of a change of variable or anything else. That's far from being efficient and shouldn't happen at all.
Sorry, but the current scheme is not efficient and makes everyone's life harder. Just because it seems more flexible doesn't mean that it's better or even optimized.
But just some "if" could solve that in an easy way... No need for complicated solutions.Qphoria wrote: Well as it is now, people do like the have side modules on their home page, and maybe no modules on the checkout page.
Yeah, it is preference indeed, but Wordpress is really different from Opencart, it doesn't have so much "parts", is not a MVC based system and it doesn't have a vQmod or something like that. My idea is to try to minimize the problems related to oc that has a totally different scenario from any CMS, cart system, forum system or anything else. It's pretty uniqueQphoria wrote: But yea this could still be done the same way with a layout style page. I guess it's just preference. Wordpress, phpbb, and a few others use same method that OpenCart uses... multiple pieces combined together by calling them as children from the main controller content.
I'm still not convinced that the current theme system is good for oc. It really should be rethought.
I knew it was possibleQphoria wrote: The old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.
Nice thread by the way, I'm learning a lot
When did OC ever hardcode modules in the template? Unless I'm missing something that's what's being advocated.Qphoria wrote:The old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.rph wrote:The only way for this to not violate MVC would be to rewrite the controllers to dump every module into the view.
There's no reason to replace a flexible, dynamic system with an inflexible, bloated one.
The conversation has been going in circles for a while now.
-Ryan
Never.. but the layout.php method was similar to Joomla's template system but kept things properly dynamic and MVC. So even tho Joomla does it wrong, it doesn't mean it couldn't be done correctly using that method.rph wrote:When did OC ever hardcode modules in the template? Unless I'm missing something that's what's being advocated.Qphoria wrote:The old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.rph wrote:The only way for this to not violate MVC would be to rewrite the controllers to dump every module into the view.
There's no reason to replace a flexible, dynamic system with an inflexible, bloated one.
The conversation has been going in circles for a while now.
Johnathan wrote:Yes -- give it a try and you'll see how it works. You don't have to use an entire line in vQmod, you can also add code after the line by using the "after" position and just a piece of the line.pedro1993 wrote: 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:
Even if all the tabs are confined within the one line?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>
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
Now it is mid 2015, a good 2 years after the start of this discussion, can somebody please update this topic now and tell the readers what is present situation, what all has changed, improved, standardised or degraded in OC in 2015 and what is vision of the developers for the future of opencart.
Thank You.
Regards,
Sun Systems
Industrial Electronics and Instrumentation
Now it is 3 years after your comment, 10 years since the original post and our experience is that lots of OpenCart merchants are still attracted to these massively over-complex themes that cause more problems than they're worth.sunsys wrote: ↑Tue May 12, 2015 2:03 amNow it is mid 2015, a good 2 years after the start of this discussion, can somebody please update this topic now and tell the readers what is present situation, what all has changed, improved, standardised or degraded in OC in 2015 and what is vision of the developers for the future of opencart.
Even when our client gives us the option of finding a theme for them that we can work with, it's hard to find well-coded themes that also look good and suit their brand so we often have to build our own.
Discussing with the other developers in our office in the UK, we think it would be amazing if it were possible to make a theme just be changing the CSS file, just like www.csszengarden.com.
1. What do others think about this issue 10 years on?
2. Does anyone have any advice for where to find good quality themes?
UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk
That might be one idea. Although, how would this strategy be dealt regarding Google Analytics and code replications among websites based on what the view source provides aside from CSS?1. What do others think about this issue 10 years on?
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Code: Select all
<link href="catalog/view/theme/default/stylesheet/stylesheet.css" rel="stylesheet">
And then we have the issue of extensions which need to modify certain template files. For this, most template developers still use VQmod or OCmod rather than event handlers. We need to get away from VQmod or OCmod!
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Well, I am creating new Themes by use of stylesheets and Pictures only for the past coupleThe ideal web theme should only consist of CSS and image files, nothing else.
of weeks, and with the help of a couple of Admin Tools, one can easy modify existing Theme
Coloring, to make it look unique. It just took a while, to find matching versions, since OC
regularely changes stylesheet content as well. But, lucky me, for the v.2.0 - 2.1.x Versions, a
good range of Themes already exists, and some of the designs use very near default code,
wich make it relatively easy to make such work. A typical Theme then only consists out of
a Header and Footer File, a Stylesheet and some images. Just to have it mentioned...
Ernie
---
my latest sample: http://www.opencart.li/shop/
---
My Github OC Site: https://github.com/IP-CAM
5'200 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.
Users browsing this forum: No registered users and 2 guests