X-Cart forums

[RichieRich]

Confusing behaviour in create an order backend. You are preseneted with every product in the database to choose from, yet you can only choose available products greater than 1. Once again zero-logic behaviour.

Lets say you have 50 listed products with almost the same name, possibly some different SKU to seperate the products, or a number at the end of the product, you wont know until you select it, that you cannot select it!

Surely, it would make sense in any language to list only available products which have a quantity greater than 1?

[carpeperdiem]

Originally Posted by cflsystems

Note all "converting" tasks after the db sql patch. So my guess here is - if you want to upgrade to 4.5.5 - you have to run store upgrade from earlier 4.5.x version....

I don't really like this. Forget about what Jeremy described as post-upgrade-testing process - you have to go through either installing 4.5.x version to upgrade the db or use the live store to do that (if that live store is on 4.5.x)....

Steve,

Not following you here??? Have you found a way to do a last-minute database patch/upgrade only?

I would like QT to comment on the upgrade process... what were you (QT) expecting a real operating store to do? Did you consider the process? Please provide what you (QT) think is a reasonable way to upgrade from 4.5.4 to 4.5.5 -- allow 72 hours from time of upgrade to going live for testing and management approvals. How would YOU (QT) do this for your paying customer? Assume the dev that's doing the work has full root access to the server, SSH, etc... Assume that there are some files that are not virgin. Let's say 25 files.

Here is how I want to do it:

1. .tgz backup of live site.
2. backup of database using phpMyAdmin
3. clone live site to /domain.com/dev/455
4. clone database
5. set htaccess to deny all to /dev directory (allow by IP only)
6. unpack upgrade tgz in-place
7. read the upgrade notes
8. patch config.php to new format - make sure $xcart_web_dir is set to /dev/455; if you have to set RewriteBase in htaccess - do it now. RewriteBase /dev/455/
9. set php memory limits on your server to an obscenely large setting
10. set permissions using CLI
11. open dev xcart admin in the new dev/455 directory. run upgrade script.
12. copy the results to a text file
13. open results in a spreadsheet -- sort by comments
14. for each file that is "could not patch", rename file to -OLD and replace with virgin 4.5.4 version - take notes. (You will re-modify your files later).
15. complete the upgrade.

Your dev store is now 4.5.5. That was easy.

Now, the fun part: re-patch each of the files from #14 -- use a compare text utility. This shouldn't take long.

Test your store. Test some more.
Because xcart decided to add new features to 4.5.5 - you have settings to deal with, new security issues in config.php and some template code that is probably not wanted. Comment it out. DOCUMENT EVERYTHING.
Keep testing.

Now, we are 2 days since running the upgrade to the /dev store. It's ready for production. But wait! The live store has been working its butt off and I there are many new customers and many new orders. HOW DO WE re-UPGRADE/CONVERT the production database to work with the upgraded store?

We used to simply, clone, run patch.sql and then re-point config.php to the patched database -- but the new upgrade process has changed things. WHAT IS THE WAY that X-Cart wants us to do this now?

[cherie]

Originally Posted by carpeperdiem

Here is how I want to do it:

Here's how I want to do it: click the Upgrade button.

Everything else should be automatically accounted for by the upgrade process.

[carpeperdiem]

Originally Posted by cherie

Here's how I want to do it: click the Upgrade button.

Everything else should be automatically accounted for by the upgrade process.

LOL!

[Danimal]

Originally Posted by jillsybte

For 4.5.5, line 312 in config.php:

const BLOCK_UNKNOWN_ADMIN_IP

I believe this was set to FALSE by default. Did you change it to TRUE? If it's set to FALSE, you shouldn't be seeing the error you're seeing when your IP address changes.

I left it at false because I know we change weekly. I do like the feature and if it were not for in the middle of working you get that message, it would not bother me. But I can not get a static IP over here. Grrrr..... And I never know when it is going to change.

So I have no idea. Just going to have to be a thorn we live with. We do password protect the admin and provider directories.

[Danimal]

Originally Posted by cherie

Here's how I want to do it: click the Upgrade button.

Everything else should be automatically accounted for by the upgrade process.

Yes! This!

[jillsybte]

Originally Posted by Danimal

I left it at false because I know we change weekly.

If you left it at false and it's still blocking you when your IP address changes, it could be a bug.

I know this feature didn't work quite right in a past version (4.5.x, but I don't recall the exact one). When my IP address changed, I tried to log in to the admin and it simply bounced me back to the login screen with no reason given. And I think I had to attempt the login 2 or 3 times before it finally sent me the email with the link.

[Danimal]

Then it must still be a bug. Because yet again, head to do a patch to the DB and BAM! got the thing again. 3rd time in a day. The config files says if your IP changes frequently, turn on something else. Well, that is on too. And still.

Thanks X-Cart.

[cflsystems]

Originally Posted by carpeperdiem

Steve,

Not following you here??? Have you found a way to do a last-minute database patch/upgrade only?

I meant - with this new 4.5.5 upgrade I don't see it possible to do the db sync like we did before, since the upgrade of the db is not finished after the sql patch is applied.

I have not tried this but maybe it will be possible to (although I have doubts)

1. dev site is ready
2. close live site
3. apply sql patch on live db (make sure you do have a backup of it before doing this)
4. run the patch_post.php which does all these "converting...." after sql patch is applied - maybe copy the file to store root and run it - yourdomain.com/patch_post.php - maybe it will work and finish the db upgrade as a standalone file - so there is no need to upgrade the whole store

This will still require a little bit more time than just applying the sql patch but a lot less time than running a whole 4.5.x upgrade

If this doesn't work for right now I do not see another way but to run a complete upgrade on the live site just to correctly patch the db

[carpeperdiem]

Originally Posted by cflsystems

I meant - with this new 4.5.5 upgrade I don't see it possible to do the db sync like we did before, since the upgrade of the db is not finished after the sql patch is applied.

I have not tried this but maybe it will be possible to (although I have doubts)

1. dev site is ready
2. close live site
3. apply sql patch on live db (make sure you do have a backup of it before doing this)
4. run the patch_post.php which does all these "converting...." after sql patch is applied - maybe copy the file to store root and run it - yourdomain.com/patch_post.php - maybe it will work and finish the db upgrade as a standalone file - so there is no need to upgrade the whole store

This will still require a little bit more time than just applying the sql patch but a lot less time than running a whole 4.5.x upgrade

If this doesn't work for right now I do not see another way but to run a complete upgrade on the live site just to correctly patch the db

I am done.
I am walking away from this until QT joins this discussion and explains what they were thinking.
4.5.4 with bug fixes is working. My ONLY justification for 4.5.5 is to play with a better iFrame for Xpayments -- and if I can't easily make it work, I can be stuck on 4.5.4 for a long long time. It's ok.