2.0 Beta has been released!

JNeuhoff wrote:

we shouldn't be using FTP to upload the files for the installation feature on OC2. It's just like placing plain text password easily accessible to others..

It not hard to modify the admin/controller/extension/installer.php so that it doesn't use FTP, but rather, place the files directly to the server. And the session can be made secure by using SSL for the admin backend in general, including the installer.

Not our job.
What for as Daniel here?

James wrote:It’s taken some time to get here but we are pleased to announce that we are now in official beta stage. You can download the beta versions here

When is 2.0 going live?
We will be going live with 2.0 within the coming days, following more testing by the OpenCart team and community ..

For such a big move (from 1.5.x branch) do you (or anybody else) really expect to fix all and everything in a few days?
Daniel (and others) needed several months for OC.2

And now we should stop our daily work and test only OC 2 ?

What kind of release management is this??

And what about this:

We will be going live with 2.0 within the coming days, following more testing by the OpenCart team and community

As I read this, you are planning to publish a 'stable' release while knowing that bugs (serious or not) are in??
But .. you have the 'team' and the community ..
What for is there a 'testsuite' embedded when you need us?

Why this hurry now after wasting months over months?

You should fix the current bug reports before publishing a "stable" release.
There are problems with the default ("responsive") template and with the extension manager.

I think there will be more soon. Please view and review our bug reports.

All I can see is the Mother and Father of all screw ups. Visions of when Microsoft released Windows Millenium and windows 98 they had more bugs than a tramps overcoat. I'll get my coat as I've probably p*ssed off a few people but I speak as I find always have and was well paid for it too.

MarketInSG wrote:we shouldn't be using FTP to upload the files for the installation feature on OC2. It's just like placing plain text password easily accessible to others..

But that's the thing: it doesn't use FTP to upload the files. It uses it to move the unzipped *.ocmod.zip files/dirs that are already on the server. I'm not sure what the thinking is behind this. Perhaps an attempt to deal with permissions issues?

The problem is doing this securely is a lot of work. You'd have to set up a directory to serve OpenCart out of, invisibly redirect requests to that dir with htaccess, then set up a dedicated FTP account with access restricted to that OpenCart directory. I have a feeling most users will just put in their host FTP account info instead and be done with it.

OSWorX wrote:As I read this, you are planning to publish a 'stable' release while knowing that bugs (serious or not) are in??
But .. you have the 'team' and the community ..
What for is there a 'testsuite' embedded when you need us?

Why this hurry now after wasting months over months?

The test suite doesn't have much coverage. Unfortunately OpenCart isn't well suited for unit testing because of the way it's coded (e.g. cyclomatic complexity, large methods, minimal SRP). I wrote about it in the OpenCart code analysis and suggested improvements thread.

I do agree a long extended beta would be useful. We've had beta releases under a week before and there were issues with them.

I find it utterly incredible that OC 2 has persisted with OcMod - why ?

rph wrote:

MarketInSG wrote:we shouldn't be using FTP to upload the files for the installation feature on OC2. It's just like placing plain text password easily accessible to others..

But that's the thing: it doesn't use FTP to upload the files. It uses it to move the unzipped *.ocmod.zip files/dirs that are already on the server. I'm not sure what the thinking is behind this. Perhaps an attempt to deal with permissions issues?

Pretty sure you're spot on with this. I remember Wordpress having the same feature a long time ago for auto installs of plugins (assume it's still an option). Having files added via FTP rather than the web server directly means the files will be set with the same permissions they would with the upload originally, including user and group permissions. If the web server runs under it's own user it may not work correctly, or the ftp user may not have access to edit the file as is the case quite often on some of the poorer configured servers for things like log and cache files generated by php

It's welcoming to see an extension installer being integrated into OC 2.0, however currently it still is pretty raw.

Custom OpenCart extensions are not always modules, shippings, payments, order totals nor feeds, however they still would require (at least benefit a lot from) a proper install/uninstall framework similar to what the modules, shippings, ... and feeds have. Current extension installer only offers install methods but is totally lacking uninstall part (how to remove changes made or files added, removing the vqmod/ocmod script is not a clean uninstall) which is also important as otherwise the OpenCart installation can get pretty ugly with unused files, unnecessary SQL data, tables and columns.

Additionally many custom extensions have configurable options so the extensions may require a separate page where these can be configured (again similar as offered by modules, shippings, .... and feeds). If every custom extension would add its custom settings to the system configuration page using vqmod/ocmod it would quickly make a mess there, which is why it would be important for the custom extensions to have their own page where to adjust the custom extension settings.

For OpenCart 1.5 and 1.4 it was quite common to add the custom extension as a module so you could benefit from the install/uninstall methods and a configuration page for the extension. However in OC 2.0 this will lead to a bit of a mess as every extension under the module folder is always considered and installed as a module (be it a real one or not) and thus the layout page offers to associate it with a layout. In OC 1 the layout bindings were handled on the module settings page of each module so you could implement it differently for extensions that really were not modules.

To sum it up, we (custom extension developers) need a separate page for custom extensions (be them ocmod or not) where the extension can be installed, uninstalled and configured similarly as modules, shippings, ... and feeds are currently handled.

The Extension Installer could be used for uploading the extension files (and maybe calling the install method of the extension). Using FTP in the extension installation process is not the perfect solution, for example Joomla handles extension uploads/installations/upgrades without FTP access and this is much more convenient for the end user.

wow, good news, beta can be use to live store?? any update must be only a bug? ya?

JNeuhoff wrote:

we shouldn't be using FTP to upload the files for the installation feature on OC2. It's just like placing plain text password easily accessible to others..

It not hard to modify the admin/controller/extension/installer.php so that it doesn't use FTP, but rather, place the files directly to the server. And the session can be made secure by using SSL for the admin backend in general, including the installer.

this is dependant on the setup of the servers. most web servers wont allow php scripts to create, update or delete files. you need to chmod all directories to 777 for this to work.

Daniel wrote:this is dependant on the setup of the servers. most web servers wont allow php scripts to create, update or delete files. you need to chmod all directories to 777 for this to work.

Using 0777 for permissions as always the worst decision (means open to everyoen and all).
Should be 0755 (or at some providers I ahve seen 0750 or 0700).
But never higher!
Or if used, change back immediately back to less than 0777 after operation.

0775 is actually quite common, or 0770 when the web server runs as it's own username but I don't think Daniel was suggesting people should actually use 0777, merely pointing out why the use of ftp details was chosen, for better compatibility with servers without having to use 0777

JAY6390 wrote:0775 is actually quite common, or 0770 when the web server runs as it's own username but I don't think Daniel was suggesting people should actually use 0777, merely pointing out why the use of ftp details was chosen, for better compatibility with servers without having to use 0777

I think it is in our duty (as developer and such people who deal with things like that on a daily base) to publish such important details in a way also a noob can understand what is ment.
You and I know how he ment it, but does that everybody?

apart from the complaints about the code, what do you guys think of the new admin design?

Looks really nice with the bootstrap integration. My only issue is the menu on the left isn't as accessible as it was on the old one where you just hover to show menu items, but realise this is due to mobile accessibility

Personally, I like the new admin design.
Also, I find useful the layout edit page with the module inside.
I just found the tooltips have limited space (you cannot have large tooltips).

I agree with bull5-i for the custom extensions uninstall. I think we need something there, so we don't have to make a module for this. For example an uninstall.sql alongside with install.sql.

custom extension uninstall is hard to do.

you can delete the ocmod xml from the db but problems arise if you start deleting files and that might have been overwritten. need to think about it a bit more.

Daniel wrote:apart from the complaints about the code, what do you guys think of the new admin design?

Nice and usefull, easy to understand.
Need only the bug with the z-index be fixed (see atlassian issue tracker)

Daniel wrote:apart from the complaints about the code, what do you guys think of the new admin design?

The admin backend does its job, its clean and functional.

The only thing I noticed is that it is slower than in previous versions of OpenCart. So I looked at it, and it turns out when loading an admin backend page, it also does calls to external 3rd party servers, e.g. for getting the 'awsome' font. This can be slow in places like the UK (unlike Hongkong ) which has virtually no proper fibre broadband. So my suggestion is to perhaps keep a local copy of the awesome font with the OpenCart server?