Super Orders v4.0 Support Thread for ZC v1.5.x

[swguy]

The github version also resolves an issue in the Plugin page version's installer

[07-Feb-2015 14:52:21 America/New_York] PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /site/admin/includes/init_includes/init_so_config.php on line 13

As a sugggestion DivaVocals, it would be better not to do things like this:

   if(file_exists(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
    {
        if(!unlink(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
...

the problem it creates is that now if this set of files is transferred to another computer running against another database (as in, for example, an upgrade), the installer no longer works.

[DivaVocals]

The github version also resolves an issue in the Plugin page version's installer

[07-Feb-2015 14:52:21 America/New_York] PHP Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /site/admin/includes/init_includes/init_so_config.php on line 13

As a sugggestion DivaVocals, it would be better not to do things like this:

   if(file_exists(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
    {
        if(!unlink(DIR_FS_ADMIN . DIR_WS_INCLUDES . 'auto_loaders/config.so.php'))
...

the problem it creates is that now if this set of files is transferred to another computer running against another database (as in, for example, an upgrade), the installer no longer works.

I've had a rough coupla last few days.. I'm tried and sleep deprived, and unfortunately still have work to do today..

So if I could ask you to do me a SOLID and help me understand that last part of your post.. I "borrowed" that code from another module's installer to begin with, and though I understand what it does, I'm not clear on the issue you say it will cause..

[swguy]

This is a pretty common workflow:

- Download a customer's cart files, which is at version X.
- Upgrade the cart to version Y locally
- Reinstall mods locally.
- Test locally
- Transfer cart files to their server for further testing (and later go-live).

In this case, auto_loaders/config.so.php will fail to be run, since it has been deleted (and not run on the non-local database).

[DivaVocals]

This is a pretty common workflow:

- Download a customer's cart files, which is at version X.
- Upgrade the cart to version Y locally
- Reinstall mods locally.
- Test locally
- Transfer cart files to their server for further testing (and later go-live).

In this case, auto_loaders/config.so.php will fail to be run, since it has been deleted (and not run on the non-local database).

Got it.. Thanks.. Now I get it.. I guess because I always just simply re-copy up the auto installers in doing an upgrade, I never considered this an issue.. I also don't have a really good solution on how to resolve this either.. Will note it as an open enhancement in the Github repo for now..

[niccol]

Got it.. Thanks.. Now I get it.. I guess because I always just simply re-copy up the auto installers in doing an upgrade, I never considered this an issue.. I also don't have a really good solution on how to resolve this either.. Will note it as an open enhancement in the Github repo for now..

Just chipping in although nothing to do directly with me. But I suspect that indirectly I may have at least dome responsibility for the issue.

I am not sure what actions are actually taken in that config file ( or the associated init_include potentially ) . But whatever they are then the way round it is to write some code that checks if these actions have been carried out and then carry them out or not as appropriate, possibly with a user confirmation that that is what they want. Then you don't have to have the config file deleted.

Downsides are of course that code that is no longer used does remain on the server. And there will be a very slight loss in processing efficiency because the checking is going to run repeatedly unless you find a nice way to get around that. Conor did some stuff like this and it works, but gets complex in some situations.

Personally, as you know Diva, my focus is usually on individual, heavily modified carts. The code for them tends to be less generic that that which is needed in a publicly released module. But in this case Scott's point is very well made.

[swguy]

Just sent you a PR with the fix.

[swguy]

Downsides are of course that code that is no longer used does remain on the server. And there will be a very slight loss in processing efficiency because the checking is going to run repeatedly unless you find a nice way to get around that. Conor did some stuff like this and it works, but gets complex in some situations.

This is the cost of not having external .sql files that need to be run by hand. But the loss is extremely small because you just check the value of a define'd variable from the configuration table. (See my PR.)

[DivaVocals]

Just chipping in although nothing to do directly with me. But I suspect that indirectly I may have at least dome responsibility for the issue.

If you mean some responsibility in that I copied off of your homework to create the Super Orders installer, then yes you are guilty!! Of course I had to add checks that aren't a part of IH4 (like not creating tables that already exist, and not adding columns that already exist in certain tables), but your IH4 example was a BIG help for me.. Dunno if I ever thanked you for that.. but if I didn't I'm saying thank you now.. You and many others here have been great teachers for me.. Speaking of which, I am gonna refine the installer to include something I picked up from copying off of lhungil's homework..

Personally, as you know Diva, my focus is usually on individual, heavily modified carts. The code for them tends to be less generic that that which is needed in a publicly released module. But in this case Scott's point is very well made.

And I understand the concern.. Scott is one of the many folks here who's examples I have followed.. Trouble is at the risk of sounding silly here, I don't know how to make the change you guys are suggesting, but I DO understand the concern.. I am willing to learn though if I have an example to follow..

This is the cost of not having external .sql files that need to be run by hand. But the loss is extremely small because you just check the value of a define'd variable from the configuration table. (See my PR.)

Thanks Scott. I just had a looksee at the PR.. Have some questions.. Will post those on Github.. Just want to make sure I fully understand EVERYTHING..

[jeking]

I'm stumped. I cannot get the auto installer to run.

I'm using the Github version and upgrading from SO 4.0.2 Clicking in the admin does not start that installer and both ADMIN/auto_loaders/config.so.php and ADMIN/init_includes/init_so_config.php remain.

I read that some servers don't honor the autoload, so tested this same version of SO on a vanilla 1.5.4 cart. The installler ran.

One difference is this upgrade site is in a sub-domain but I don't see how that would matter.

What should I be looking for as the cause?

[DivaVocals]

I'm stumped. I cannot get the auto installer to run.

I'm using the Github version and upgrading from SO 4.0.2 Clicking in the admin does not start that installer and both ADMIN/auto_loaders/config.so.php and ADMIN/init_includes/init_so_config.php remain.

I read that some servers don't honor the autoload, so tested this same version of SO on a vanilla 1.5.4 cart. The installler ran.

One difference is this upgrade site is in a sub-domain but I don't see how that would matter.

What should I be looking for as the cause?

Is this a NEW install or an upgrade??