Actually, creating twig-templates is harder, and for Opencart offers no major advantages.
It's easy enough to add support for the PHP template engine to the OC frontend.

It's not harder to create twig templates (you just have to get used to with twig), but I agree that twig doesn't offer any advantages for Opencart.

If anybody knows any real advantages of twig for OC please post them here, because IMO twig is not suitable for OC, because most extensions do changes in templates and now they must support 2 different versions: one for tpl (OC 1.5.x and OC 2.x) and the other for twig (OC 3.x +). And I still believe, based on the few tests I made, that twig slows down OC.

Last edited by ovi on Thu Jun 29, 2017 6:35 pm, edited 1 time in total.

I would like to ask some clarifications about the cloud version in order to decide the best approach for migrating my extensions.
1) It is not clear to me how/what will be stored in the cloud. Is there a document/link that explains in more detail this new app model?
2) Will there be a special "OC3 cloud version" or are we talking about the same software?
3) An extension of mine adds a new column (i.e. a new property) in the products table and an additional property for each product option. If I were to create new tables (instead of altering existing ones) for my extension that would be used with joins, I would have to create new tables to store the relations product_id-<new_property> and product_option_id-<new_option_property>. Since the products are the main concept of the app, these tables will replicate rather a lot of information for databases with a lot of products/product options. Is this the correct way to go?

Having the above clarifications would help me migrate my extensions respecting this new spirit of the cloud philosophy.
Thanks in advance
Best regards

I would like to ask some clarifications about the cloud version in order to decide the best approach for migrating my extensions.
1) It is not clear to me how/what will be stored in the cloud. Is there a document/link that explains in more detail this new app model?

Basically the hosting, no need to download and install on your own webhost. There is also the online marketplace for extensions for simple extension installs, though at the moment there's hardly any extensions listed in there.

3) An extension of mine adds a new column (i.e. a new property) in the products table and an additional property for each product option. If I were to create new tables (instead of altering existing ones) for my extension that would be used with joins, I would have to create new tables to store the relations product_id-<new_property> and product_option_id-<new_option_property>. Since the products are the main concept of the app, these tables will replicate rather a lot of information for databases with a lot of products/product options. Is this the correct way to go?

Any additional DB fields for e.g. the 'oc_product' or other tables would have to be stored in their own DB tables, and the model would have to be extended for the DB queries using SQL joins. Also the allowed folders for 3rd party extensions are more restrictive, too, you can see the list of allowed folders for extensions in file admin/controller/marketplace/install.php

So if I understand it correctly I could opt-out from the cloud version, right? My modules will be installable when a user uses his/her own webhost but will not be installable in the cloud version. If later I decide to support the cloud version I could create a new version of my module specifically for the cloud.

Also the allowed folders for 3rd party extensions are more restrictive, too, you can see the list of allowed folders for extensions in file admin/controller/marketplace/install.php

Actually there is an additional hidden restriction: while the admin/controller/extension/ folder is allowed to be written, the way the permissions are checked in the admin/controller/startup/permission.php do not allow to create a sub-folder in the extension directory i.e. extension/my_module/my_controller.php will result in a "permission denied" page, while extension/my_controller.php will work ok. This is the case only for the controller part of the extension, language, model and template parts do not have this issue.

Last edited by open4dev on Thu Sep 14, 2017 10:11 pm, edited 1 time in total.

Actually there is an additional hidden restriction: while the admin/controller/extension/ folder is allowed to be written, the way the permissions are checked in the admin/controller/startup/permission.php do not allow to create a sub-folder in the extension directory i.e. extension/my_module/my_controller.php will result in a "permission denied" page,

Thanks. Was shifting one extension and i created a folder as there were lot of files. But shall need to undo this.
Thanks for information.

Last edited by imdevlper18 on Thu Sep 14, 2017 11:47 pm, edited 1 time in total.

Actually there is an additional hidden restriction: while the admin/controller/extension/ folder is allowed to be written, the way the permissions are checked in the admin/controller/startup/permission.php do not allow to create a sub-folder in the extension directory i.e. extension/my_module/my_controller.php will result in a "permission denied" page, while extension/my_controller.php will work ok. This is the case only for the controller part of the extension, language, model and template parts do not have this issue.

Thanks for pointing that one out. I came across the same issue and had to restructure my extensions accordingly.

Including anything except upload folder and install.xml in archive is now restricted for cloud extensions.

Is it possible to allow keeping at least install.txt or readme.txt file there?

Cause now people are asking questions without reading installation instructions I filled on a module page. Seems they are used to look inside archive and to search instructions there, but not on a download page.

At least for now OC3 and OC Cloud means the same. Right? Modules can be purchased via admin area (at least it's planned) the same as via marketplace on opencart.com. And in the last case people can explore archives.

Is it planned that OC3 and Cloud extensions will be different and|or incompatible? Or "Cloud" that's just a name of a new admin area marketplace?

As you noticed they are now not allowing any files other than the upload folder and install.xml in the ocmod.zip file for the OpenCart Cloud version. The OpenCart site will soon be flooded with unneeded support requests because too many users won't find the online documentation on the OpenCart marketplace.

We may end supporting the OpenCart cloud installer and instead advise our customers to use the normal OpenCart extension installer.

Actually there is an additional hidden restriction: while the admin/controller/extension/ folder is allowed to be written, the way the permissions are checked in the admin/controller/startup/permission.php do not allow to create a sub-folder in the extension directory i.e. extension/my_module/my_controller.php will result in a "permission denied" page, while extension/my_controller.php will work ok. This is the case only for the controller part of the extension, language, model and template parts do not have this issue.

I created both "extension/my_extension.php" file and "extension/my_extension" folder.
Leaving my_extension.php empty.

As you noticed they are now not allowing any files other than the upload folder and install.xml in the ocmod.zip file for the OpenCart Cloud version. The OpenCart site will soon be flooded with unneeded support requests because too many users won't find the online documentation on the OpenCart marketplace.

We may end supporting the OpenCart cloud installer and instead advise our customers to use the normal OpenCart extension installer.

Ahaha!

It's better if they would restrict using AngularJS and other frameworks and selfwritten templates as Journal2 does