Post by Johnathan » Mon Sep 23, 2013 9:52 pm

pedro1993 wrote:
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>
Even if all the tabs are confined within the one line?
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.

Image
Image Image Image Image Image Image


User avatar
Global Moderator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by Qphoria » Tue Sep 24, 2013 12:10 am

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?
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

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by intersect » Tue Sep 24, 2013 11:59 am

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 :P
Good to know.
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.
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
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.

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 ?>
For moddings (like vQmod) it would be much less troublesome the one file scheme because modders would target the tpl's files that would hardly be changed in any theme because of the clean and simple structure of it. For theme developers the old/new scheme would be much easier to deal with, and with well thought and simple solutions it could be as powerful as the current one.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by rph » Wed Sep 25, 2013 12:19 am

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.
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.

-Ryan


rph
Expert Member

Posts

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

Post by Qphoria » Wed Sep 25, 2013 12:27 am

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.
Well as it is now, people do like the have side modules on their home page, and maybe no modules on the checkout page.
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.
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 old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by intersect » Wed Sep 25, 2013 1:09 am

rph wrote: 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.

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.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by intersect » Wed Sep 25, 2013 1:25 am

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.
But just some "if" could solve that in an easy way... No need for complicated solutions.
Qphoria 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.
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 unique ;D
I'm still not convinced that the current theme system is good for oc. It really should be rethought.
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.
I knew it was possible 8)
Nice thread by the way, I'm learning a lot ;D

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by rph » Wed Sep 25, 2013 2:02 am

Qphoria wrote:
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 old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.
When did OC ever hardcode modules in the template? Unless I'm missing something that's what's being advocated.

The conversation has been going in circles for a while now.

-Ryan


rph
Expert Member

Posts

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

Post by Qphoria » Wed Sep 25, 2013 3:43 am

rph wrote:
Qphoria wrote:
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 old layout.php style in opencart still managed to be MVC. Joomla may not be doing it right, but it could be done.
When did OC ever hardcode modules in the template? Unless I'm missing something that's what's being advocated.

The conversation has been going in circles for a while now.
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.

OpenCart 2.0.x Mod Update Info

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by pedro1993 » Wed Sep 25, 2013 5:18 am

Thanks for that! I'll give it a shot next time I need to ;)
Johnathan wrote:
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:

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>
Even if all the tabs are confined within the one line?
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.

For professional OpenCart, HTML/CSS & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support
Follow me on Twitter!
Catch me on Facebook!
Watch YouTube OpenCart Tutorials and Extension Demos

Image


User avatar
Active Member

Posts

Joined
Tue Oct 18, 2011 4:31 am
Location - Glasgow, Scotland

Post by sunsys » Tue May 12, 2015 2:03 am

Hi, I have gone through all the 9 pages of this topic and I must say it was fascinating to read the views of designers and developers on this(though I personally tend to lean in Q's favour).

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


User avatar
Active Member

Posts

Joined
Tue Jan 27, 2015 5:19 am

Post by paulfeakins » Wed Mar 21, 2018 8:36 pm

sunsys wrote:
Tue May 12, 2015 2:03 am
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.
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.

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?

For quick, professional OpenCart support please email info@antropy.co.uk


User avatar
Active Member

Posts

Joined
Mon Aug 22, 2011 11:01 pm
Location - Reigate, Surrey, United Kingdom

Post by straightlight » Wed Mar 21, 2018 9:43 pm

1. What do others think about this issue 10 years on?
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?

The most generated errors being found on Opencart forum originates from contributed programming.

Regards,
Straightlight


Guru Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by JNeuhoff » Wed Mar 21, 2018 10:30 pm

@paulfeakins: The ideal web theme should only consist of CSS and image files, nothing else. However, some of the twig files, such as the 'common/header.twig', still have some hard-coded theme folder names in them, e.g. 'default':

Code: Select all

<link href="catalog/view/theme/default/stylesheet/stylesheet.css" rel="stylesheet">
thus forcing web themes to always use their own 'common/header.twig'.

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!

MHC Web Design
Override Engine * Integrated VQMod * Multilingual SEO * Instant Option Price Calculator * TrustPilot Reviews * Download Options * Free Download Buttons * Export/Import Tool * Template Switcher PHP/Twig


User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by IP_CAM » Wed Mar 21, 2018 10:53 pm

The ideal web theme should only consist of CSS and image files, nothing else.
Well, I am creating new Themes by use of stylesheets and Pictures only for the past couple
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... :D
Ernie
---
my latest sample: http://www.opencart.li/shop/
---

Ernie's OpenCart v.1.5.6.5 LIGHT + V-Pro + OpenShop Admin v.1.75 Test Sites
http://www.bigmax.ch - http://www.opencart.li/shop/ - http://www.velomech.ch/cart/
Image


User avatar
Guru Member

Posts

Joined
Tue Mar 04, 2014 1:37 am
Location - Switzerland
Who is online

Users browsing this forum: No registered users and 6 guests