OpenCart Community

So I know we are only nearing OpenCart 1.5.0, but that doesn't stop my mind from thinking forward.

So I have a few ideas for the future that I think would be great conceptually that I'll mark down here.

MVC and Namespace Restructure
Currently a big annoyance with the way MVC is laid out in opencart is the fact that it spread all over the place. This is especially true for extensions. It would be nice if they were grouped better. So looking at only the catalog side only for now, a module typically has 3-4 files. This is simply a difficult structure to maintain, not only because they are spread across multiple directory trees, but also since other files intermix with each of the separate files, so it is hunt trying to find them. Uploading the files can be done somewhat easily because of the way file copying works, but removing a module is quite difficult knowing where each file is, and has to be done one file at a time.

So one idea I had was to use the folder as the namespace and let each module folder have its own MVC layout. Some possible naming conventions:

1. Folder Namespace
2. File Namespace & type
This would also change the directory structure completely of course. So some possible structures: This keeps all the files for a module in its own folder, separate from other modules and files. Adding, removing, and maintaining is much simpler. I used "page" for things like category, product, search, manufacturer, etc because those are full landing "pages". But that is another area I'd like to change too... more on that later

I've thought this for a while. Personally, I think the last structure you suggest:
would be good. Hopefully we don't have to wait years to see this happen.

My next idea...

Keep core functionality out of extensions
I've mentioned this a few times before....
Currently the extension system puts too much expectation of control and responsibility into the individual extensions.
- Geozone's should be set at the store level, not the extension level.
- Tax class should be set at the store level, not the extension level.
- Status should be set at the store level, not the extension level.
- Sort Order should be at the store level, not the extension level.

Only the main functionality of the extension should be in the extension. The rest is all common stuff that the store should control. If a mod maker decided to leave these fields out, then you lose conformance. And the developer shouldn't have to add this stuff anyway. It is the extension's job to add the specific functionality to the cart, not handle all the mundane steps.

This also means additional filters could be added in the future like allowed customer groups, days of the week, whatever.

Example:

so are you proposing a new page in the admin to set those options on the extensions, because it's very common for someone to want to allow say USPS for US zone and other shipping options for international zones, and that functionality really needs to be available. If you remove it from the extensions you have to put it somewhere.

Xsecrets wrote:so are you proposing a new page in the admin to set those options on the extensions, because it's very common for someone to want to allow say USPS for US zone and other shipping options for international zones, and that functionality really needs to be available. If you remove it from the extensions you have to put it somewhere.

Do you not see the words "extension manager" in the image above?

Split your topics. Will be easier to follow and comment on

A.) file structure
You're gonna run into problems with that. What happens when you have a module that is actually several components?
You are on the right track to reorganize things a bit better and do see that it could make cloud based plugins possible but there are just some areas that have an module and also a normal page.
What do you do then?
I guess you could make them smarter

B.) general extension variables
Definitely a plus but I'd imagine an over-ride system would be better and would solve X's point.

C.) more ways to reduce all those copy/paste/small edit areas would be very useful too!
as along the lines like http://forum.opencart.com/viewtopic.php?f=24&t=19000

SapporoGuy wrote: C.) more ways to reduce all those copy/paste/small edit areas would be very useful too!
as along the lines like http://forum.opencart.com/viewtopic.php?f=24&t=19000

This is already planned for 1.5.x
1.4.9.4 settings file has this

Perhaps you could clean up the source some for the .tpl pages.. as I'm picking through them to mess with the CSS I am noticing a handfull of things are styled without classes or ids, but by inline styling.

Just nitpicking, as it's easy to fix, but I figured I'd let you know

ClickNEasy wrote:Perhaps you could clean up the source some for the .tpl pages.. as I'm picking through them to mess with the CSS I am noticing a handfull of things are styled without classes or ids, but by inline styling.

Just nitpicking, as it's easy to fix, but I figured I'd let you know

that is supposedly fixed in 1.5 so shouldn't be an issue for 2.0

Don't forget about installing an extension from admin. Both module and "page" like you say above.

Qphoria wrote:Currently the extension system puts too much expectation of control and responsibility into the individual extensions.
- Geozone's should be set at the store level, not the extension level.
- Tax class should be set at the store level, not the extension level.
- Status should be set at the store level, not the extension level.
- Sore Order should be at the store level, not the extension level.

I'm sure you've already thought of this as well, but there needs to be an "Extensions" area for non-modules as well. I'm currently using the "Modules" area for some of my extensions because there's no other place to give access to their settings without modifying the core code, but it would be clearer if there was a "Modules" (i.e. side modules) area, and an "Extensions" area.

SapporoGuy wrote:Split your topics. Will be easier to follow and comment on

A.) file structure
You're gonna run into problems with that. What happens when you have a module that is actually several components?
You are on the right track to reorganize things a bit better and do see that it could make cloud based plugins possible but there are just some areas that have an module and also a normal page.

I don't see a problem with this. It's just reorganizing the controller/module, language/module, and view/module folders into one area. You could still place other files in other places if you needed to. It's just better organized.

removing, adding, editing, isntalling and uninstalling new modules/extensions from admin

Johnathan wrote: I'm sure you've already thought of this as well, but there needs to be an "Extensions" area for non-modules as well. I'm currently using the "Modules" area for some of my extensions because there's no other place to give access to their settings without modifying the core code

Yep.. that was another thread where I discussed moving "Reports" to the extension area to make that extensible and was also adding a "tools" menu to extension as well for things like:
- Import/export
- backup/restore
- csv import/export
- Batch edit
etc

So Tools is planned for 1.5.x actually

Code model etc., is all well and good for ease of maintenance but more fundamentally, the database schema needs a serious rework around the Product->Options->Values area which doesn't sound as though it has been addressed in 1.5

Having multiple Product-Option-Values is an enormous plus but having no relationship between them means that stock control is impossible (the old 'How many large, blue, shirts are in stock' chestnut).

You can reorganise the code all you like but Opencart is effectively is single Product Option system which makes it very limited.

+ + +

Something like Wordpress plug-ins with simple Admin controlled Search-Install-Activate-DeActivate-Uninstall is also pretty essential. Together with automatic updates.

+1 for module installation hooks

I'm not sure how often this has been said maybe not at all maybe once every week but here goes.

In Magento and some mods I made for zen cart, you can create configurable products which are essentially single products with an option say "large, brown" or another "small , brown" each with their own stock level.

Then a parent product groups all the single products and displays them as one product on the shop side of things. This allows for stock control on products such as shoes etc which many people seem to require.

Just a thought but I think as the cart grows so should the power for adding more complex product solutions to the site.

fix SEO breadcrumb issue that means when you are currently on an information page, the breadcrumb url uses SEO and not default url, so you dont have two links to 1 page.

Qphoria,

You have spoken out about my concerns similarly as well.

As I was removing the additional modules that I tried to customise earlier -- ie Weight, it just gives me the creeps that I have to go to separate folders to look for the related files and delete..

Its inconvenient from a user standpoint -- ever heard of usability studies in IT terms? This would be a bummer as its slightly tedious to manipulate around for users.

It would have been wonderful if its .like Wordpress, you can have every module/ extension related files inside one folder only..

And one additional thing I think Opencart could learn from Wordpress too is that a 'delete' function is programmed into the main code as well.. so that the user do not have to go to FTP and find the files to delete.

That's the only gripe I have so far... with regards to the MVC directory structure.

Thank you.

Qphoria wrote:So I know we are only nearing OpenCart 1.5.0, but that doesn't stop my mind from thinking forward.

So I have a few ideas for the future that I think would be great conceptually that I'll mark down here.

MVC and Namespace Restructure
Currently a big annoyance with the way MVC is laid out in opencart is the fact that it spread all over the place. This is especially true for extensions. It would be nice if they were grouped better. So looking at only the catalog side only for now, a module typically has 3-4 files.

Code: Select all

model/module/file.php
view/module/file.tpl
controller/module/file.php
language/english/module/file.php

This is simply a difficult structure to maintain, not only because they are spread across multiple directory trees, but also since other files intermix with each of the separate files, so it is hunt trying to find them. Uploading the files can be done somewhat easily because of the way file copying works, but removing a module is quite difficult knowing where each file is, and has to be done one file at a time.

So one idea I had was to use the folder as the namespace and let each module folder have its own MVC layout. Some possible naming conventions:

Folder Namespace

Code: Select all

/module
    /latest
        /controller.php
        /model.php
        /view.php
        /language.en.php

File Namespace & type

Code: Select all

/module
    /latest
        /latest.controller.php
        /latest.model.php
        /latest.view.php
        /latest.language.en.php

This would also change the directory structure completely of course. So some possible structures:

Code: Select all

/catalog
    /page
    /module
        /latest
            /controller.php
            /model.php
            /view.php
            /language.en.php
        /cart
            /controller.php
            /model.php
            /view.php
            /language.en.php
    /payment
    /shipping

This keeps all the files for a module in its own folder, separate from other modules and files. Adding, removing, and maintaining is much simpler. I used "page" for things like category, product, search, manufacturer, etc because those are full landing "pages". But that is another area I'd like to change too... more on that later

well I think that most of the file layout issues will be a non issue if we just get a good mod/plugin manager in the admin so that users never have to look at the files.

First and sorry for this: when OC 1.5 will be available? ;)

Now I have a few ideas here related to DB, Mail, Template, Graphics and so on.
1) Why not integrate a ORM like Propel or Doctrine or other something?
2) Why not use a template system like Twig or Smarty or someone else?
3) Why not user a better graphics library like pChart?
4) Why not use SwiftMailer to send emails?

For a long time I was trying to integrate this libraries and I do but changing a lot of things in CORE and this is not a nice solution.

Right now I'm try to change the admin theme and I lost because did not know hoe template system works in OC and it's not documented in any place like a API. This two additions will be better for programmers like me because allow a better way to make changes based on needs. This is only my IMHO I don't know if will be nice or not.

Also I would like to have a better invoice management. For example suppose that I have a virtual store and also a local physic store. Previously a client was registered on site but didn't like to buy trough it so it goes to the local store and try to buy the product there. How can I generate the invoice for this user? How I can remove the quantity of the product sell? Maybe this are presented in actual OC but I did not founded yet.

Is just a few comments :P