This is something I was doing for chromiumcart too actually... "Layout Type". This would be a good way to change layouts dynamically for each product/category/information item, etc.Jan R wrote:Jan Here...
I like the ideal of flexible layouts.
Here is a thought...
what if you had multiple 'layout' files
something like..
layout_01 = default
layout_02 = no left pain
layout_03 = no right pain
layout_04 = no side pains
etc...
Thanks for including stock tracking for product variations. I tested out the functionality in this release and some of the logic doesn't quite make sense... the main product stock variable seems to still function independently from the options stock variables rather than being overridden. For example, even if there is stock of a product option, if the stock number of the main product is zero then the product page will display out of stock. Furthermore, if you select don't subtract from stock on an option but subtract from stock is set on the main product (via the general cartwide settings) then the main product stock number still subtracts, which doesn't make sense.
Anyway I think that the "subtract from stock" option should be settable per product in addition to having a cartwide default; my preference would actually be to have an unlimited stock option since that makes more sense logistically for some types of items.
Having product variations with their own stock means the stock number displayed on the storefront product page and also the product listing in the admin isn't going to be that useful even if you manually ensure the variations always add up to the main product stock; really I'd like to see a better solution. Ideally there'd be some way to display stock of the various options. I've seen it done one way where right in the dropdown next to each option, it displays how much stock is left. It would also make sense to have the product variations display on their own line in the admin product listings; this way we could sort the listing by stock to quickly see which product variations may be low/out of stock.
Anyway I think that the "subtract from stock" option should be settable per product in addition to having a cartwide default; my preference would actually be to have an unlimited stock option since that makes more sense logistically for some types of items.
Having product variations with their own stock means the stock number displayed on the storefront product page and also the product listing in the admin isn't going to be that useful even if you manually ensure the variations always add up to the main product stock; really I'd like to see a better solution. Ideally there'd be some way to display stock of the various options. I've seen it done one way where right in the dropdown next to each option, it displays how much stock is left. It would also make sense to have the product variations display on their own line in the admin product listings; this way we could sort the listing by stock to quickly see which product variations may be low/out of stock.
This is...."Magento-ie"Qphoria wrote:This is something I was doing for chromiumcart too actually... "Layout Type". This would be a good way to change layouts dynamically for each product/category/information item, etc.
Although I don't have a lot of experience with shopping carts, I've used a lot of content management systems with different templating systems.
MODx is by the far the best I have come across. Templates are stored in the database and then cached. This gets you around the problems mentioned above. The templates simply reference files...the files can be anywhere! By using placeholders [drawcart] etc...you could insert the dynamic elements.
Just an idea....MODx has the most brutally simple templating system I have ever seen (that said I was quite happy with the one in 1.3.2!!)
On the SEO side: 66 characters is far too short, I agree 200+ is better. There should be a field for META Keywords that can be set per page also.
This is the ideal solution for myself. I have worked with Magento and although i hated their templating system initially i grew to it because of the mass flexibility it has.Jan R wrote:Jan Here...
I like the ideal of flexible layouts.
Here is a thought...
what if you had multiple 'layout' files
something like..
layout_01 = default
layout_02 = no left pain
layout_03 = no right pain
layout_04 = no side pains
etc...
Then either in the admin area or on the top of each top level .tpl you could set a 'layout variable' that told OCart what layout you wanted.. the possibilities would be endless.
New layouts could be created by anyone and interchanged as needed.
Thats my 2 cents.. Thanks Daniel for the hard work...
-=:@:=-
I'm preparing to build a new e-commerce site using the OpenCart System and just keeping up-to-date on changes before it begins and noticed this. I have not worked with OpenCart previously, but from the posts in this forum it sounds as though there is 1 Layout.tpl file for the entire site?
What do you do if you want for example, the Basket page to have no columns, or the Checkout page to have a left column, but no right.
Using Conditional IF Statements to determine these pages is surely very poor practice?
It sounds as though the way Daniel has re-worked the templating system is much better than the previous one for its flexibility, although yes, it requires more updating if you want to make a global change, but if you forget about how the system used to work and look at how it works now, Do you not see how much better it can be? Since this means i can work my templates on a zone-based area, such as having a different layout for shopping basket, and checkout.
A simpler solution to suite all may be as Jan posted above, such as having a 1-col.tpl, 2-col-left.tpl, 2-col-right.tpl, 3-col.php template files, and setting them individually in the admin panel with the default obviously being the 3-col layout?
OK, so if I understand it correctly, the main reason for Daniel to remove the former layout.tpl was to be able to use different layouts for different kind of top-level templates.A simpler solution to suite all may be as Jan posted above, such as having a 1-col.tpl, 2-col-left.tpl, 2-col-right.tpl, 3-col.php template files, and setting them individually in the admin panel with the default obviously being the 3-col layout?
Though I still think most top-level templates will have the same overall layout. This is what most good websites do: Keep a common layout and theme throughout the pages of a website. A deviating layout for a few pages on the same website is usually the exception, and for such cases we could create a simple lookup table in the database listing alternative layouts, along with an appropriate admin interface.
Also, as Qphoria pointed out, a good fallback mechanism in the templating system would be quite useful. This way, a new webtheme isn't required to replicate all the template files, rather just the ones which need changes, be it the top-level layout.tpl or any lower-level tpl file.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Actually I was thinking more like Zen-Cart's "product type"... only less suckyjusmeig wrote:This is...."Magento-ie"Qphoria wrote:This is something I was doing for chromiumcart too actually... "Layout Type". This would be a good way to change layouts dynamically for each product/category/information item, etc.
Well I'll just say the closer you get to a magento type sytem the more you will run people off. I've done one store on magento and only one because of their templating system(shame too cause the cart functionality is fairly nice). To me it seems much quicker to use a conditional in the main template file for the rare occasion where you want one page different than it would take to mirror every global change you want to make to every page. This whole idea of all the multiple layouts that you can attach to pages might be nice, but it just seems like an awful lot of work at this point I would think there are other places the effort could be spent.
Your presuming that it will be a rare occasion, based on your own experience and designs. When i design E-Commerce sites i vary the design to continually make it look fresh...and not like a template. Therefore i have alot of pages that vary from 2 column, to 1 column.Xsecrets wrote:Well I'll just say the closer you get to a magento type sytem the more you will run people off. I've done one store on magento and only one because of their templating system(shame too cause the cart functionality is fairly nice). To me it seems much quicker to use a conditional in the main template file for the rare occasion where you want one page different than it would take to mirror every global change you want to make to every page. This whole idea of all the multiple layouts that you can attach to pages might be nice, but it just seems like an awful lot of work at this point I would think there are other places the effort could be spent.
For me, using a conditional If on the template file itself to judge where you are is very tacky. Like i said - I have not used OpenCart as of yet, only tested it myself so I'm not experienced with how it works.
MWS,
I completely agree with you. True, it is possible to insert some conditions to show or not to show columns but the idea of design variations for different pages is better done without a fixed layout.
Some examples:
The home page should, like magento does, show promotions or some specials or new products or product banners. For the customer entrance we do not need the whole colum left, column right stuff. That can go into other pages. And in the checkout process, especially if ssl is enabled, we do not need boxes with external links, which give browser warnings or deflect from the purpose. It is better to design the checkout pages a little bit different to give the customer an easy guide through the checkout proceeding.
I am not a web designer, so I give such work to somebody, who is qualified to do that. There are a lot of online shops in the www and a lot of them look all somehow the same. In most cases you even can say what shopping cart is used. They have no unique selling position, there only selling position is trying to sell by discount. And sorry to say the most payed templates for OpenCart give the impression, that someone did take the default template and changed a few colors in the css file. A shopping cart should invite customers to stay inside and feel fine and not having the impression to buy at a low level discounter.
I completely agree with you. True, it is possible to insert some conditions to show or not to show columns but the idea of design variations for different pages is better done without a fixed layout.
Some examples:
The home page should, like magento does, show promotions or some specials or new products or product banners. For the customer entrance we do not need the whole colum left, column right stuff. That can go into other pages. And in the checkout process, especially if ssl is enabled, we do not need boxes with external links, which give browser warnings or deflect from the purpose. It is better to design the checkout pages a little bit different to give the customer an easy guide through the checkout proceeding.
I am not a web designer, so I give such work to somebody, who is qualified to do that. There are a lot of online shops in the www and a lot of them look all somehow the same. In most cases you even can say what shopping cart is used. They have no unique selling position, there only selling position is trying to sell by discount. And sorry to say the most payed templates for OpenCart give the impression, that someone did take the default template and changed a few colors in the css file. A shopping cart should invite customers to stay inside and feel fine and not having the impression to buy at a low level discounter.
I like the ideal that Jan and Qphoria spoke about and here is why.
1. It still allows for Daniel's realization of flexibility. Something I believe is very forward looking.
2. It would allow for all the current available public 1.3.x templates and all the ones painstakingly created for very picky clients (Boy could I tell you stories
) to still work without change because without the code they would just fall back to the default layout.
Something I would like to see is a template option for the product page as well so that different product layout could be chosen on a product by product basis with of course the default as a fall back for compatibility.
Thanks Daniel for all the work you keep putting in to what I think is one of the best fresh carts to surface in a long time.
1. It still allows for Daniel's realization of flexibility. Something I believe is very forward looking.
2. It would allow for all the current available public 1.3.x templates and all the ones painstakingly created for very picky clients (Boy could I tell you stories
) to still work without change because without the code they would just fall back to the default layout. Something I would like to see is a template option for the product page as well so that different product layout could be chosen on a product by product basis with of course the default as a fall back for compatibility.
Thanks Daniel for all the work you keep putting in to what I think is one of the best fresh carts to surface in a long time.
I've been porting over some of my ever popular 
free themes for 133.
Took me about 15 min each. Did 5 of them.
When I first looked at the the no layout.tpl structure, I wasn't sure I liked it.
After porting over the themes, and pondering this idea the whole time, I realized how flexible this is.
As a designer this really gives a lot, and with php being modular in nature the layout options are endless.
In terms of cutting down on repeated coding tasks, group pieces into small chunks and call them in with includes.
I think one might want to give this a chance and maybe ponder it more, it really is better.
I endorse this new idea in 133.
Small bug: when in setting, the theme drop-down list defaults to the first theme in line instead of the currently selected theme. What happens if you go to settings make a contextual change and save it you ask, Your theme will change to the first theme in line, unless you remember to select the one you had set.
free themes for 133.Took me about 15 min each. Did 5 of them.
When I first looked at the the no layout.tpl structure, I wasn't sure I liked it.
After porting over the themes, and pondering this idea the whole time, I realized how flexible this is.
As a designer this really gives a lot, and with php being modular in nature the layout options are endless.
In terms of cutting down on repeated coding tasks, group pieces into small chunks and call them in with includes.
I think one might want to give this a chance and maybe ponder it more, it really is better.
I endorse this new idea in 133.
Small bug: when in setting, the theme drop-down list defaults to the first theme in line instead of the currently selected theme. What happens if you go to settings make a contextual change and save it you ask, Your theme will change to the first theme in line, unless you remember to select the one you had set.
I'd still like to hear more about what makes it "better"CodeBits wrote:When I first looked at the the no layout.tpl structure, I wasn't sure I liked it.
After porting over the themes, and pondering this idea the whole time, I realized how flexible this is.
As a designer this really gives a lot, and with php being modular in nature the layout options are endless.
In terms of cutting down on repeated coding tasks, group pieces into small chunks and call them in with includes.
I "get" the design of having the controller be the parent and all the modules as the children... that on paper is a great concept. But as others have said, that means if you want a consistent flow of a 2 column template, you have to edit every single controller file and remove the "hardcoded" child. Which now means that you need to edit the controller to design a template, which defeats the design of MVC, as now your template depends on the controller.
I just don't see what arena this would be good for. I mean, sure if you are planning on always hiding the sideboxes on the product page but showing them on other pages, then yea, removing the sidebox children would be simple.. tho still editing the controller.
I suppose it's less "hacky" than adding a simple conditional to the layout.tpl template
Code: Select all
if ($this->request->get['route'] == 'catalog/product') {
.....
}Perhaps as I said earlier if there was a layout manager in admin that used database entries for each controller, but then you limit yourself from the item level. Unless you add the layout choices to each individual product, info page, category, etc. But that seems like a lot of work for something that rarely changes. At least with the "hacky" way it is possible and quite simple.
OpenCart 1.3.3? Three questions..
Is Authorize.net ever going to be implimented into this shopping cart?
I noticed that it said something about UPS, is this going to be using UPS Real-Time Rates to give accurate calculations?
When is OpenCart 1.3.3 go9ing to be available for download?
Is Authorize.net ever going to be implimented into this shopping cart?
I noticed that it said something about UPS, is this going to be using UPS Real-Time Rates to give accurate calculations?
When is OpenCart 1.3.3 go9ing to be available for download?
OpenCart 1.3.3? never heard of it. This is PrestoCartrpotterjr wrote:OpenCart 1.3.3? Three questions..
When is OpenCart 1.3.3 go9ing to be available for download?
Yes I have Authorize.net and UPS here
Hey Daniel (and other OpenCart members!)
I just upgraded my dev version of my new store to 1.3.3 from 1.3.2 and then unfortunately read this thread completely
Should I try and roll back to 1.3.2 or is there a quick way I can put the layout.tpl back from the upcoming release. If you could PM me a link to the corrected 1.3.3 theme dir then that would be awesome.
Any help here would be great as I need to get the html merged by next week!
Best regards
cdm
I just upgraded my dev version of my new store to 1.3.3 from 1.3.2 and then unfortunately read this thread completely
Should I try and roll back to 1.3.2 or is there a quick way I can put the layout.tpl back from the upcoming release. If you could PM me a link to the corrected 1.3.3 theme dir then that would be awesome.
Any help here would be great as I need to get the html merged by next week!
Best regards
cdm
Who is online
Users browsing this forum: No registered users and 49 guests
