Putting a new, updated PrestaShop site live - migration

I need some best-practice advice for how best to go-live with a new PrestaShop store.
The background: we have been working on a new store, with new core (PrestaShop version) and new design (updated theme).
Next: very soon, we need to put this store live, but we already have a live (and active) PrestaShop store.
So, what is the best approach to get this new store live?
Of concern are the changes to the current live version whilst the new one has been developed - content, orders, accounts etc which need to persist.
FYI we have full server access with cPanel, SSH etc.
Many thanks!

Set the current live site in Maintenance for a few hours at a time when you have less visitors: use a module like [MigrationPro][1]
[1]: https://addons.prestashop.com/en/data-migration-backup/8934-migrationpro-prestashop-upgrade-and-migrate-tool.html or look for some free scripts on Prestashop forum->Free modules section (although I recommend the module above; not affiliated with them just used it several times).
Migrate the data, check if everything alright and if it is, just move elsewhere (as a backup) the files in the web directory and move there the new shop files (set the new shop on maintenance too).
Clear all caches, test it the set it online.

My opinion is:
Putting the main site in maintenance mode
Moving the main site to a new test address
Upgrading the test site in the new address to the desired version of Prestashop
Getting output from the desired template (your custom theme) and importing it on the test site
If there is no problem, you can move the test site to the main site (files and databases) or do the same thing again on the main site.

You need to start a process and create documentation.
Create a copy of the live shop folders and database to a new address like /test.
Upgrade your test shop to the new version 1.7.6.5.
Start moving your theme and modules from your new store to the upgraded test shop.
Create documentation of every change. like moving files, moving modules DB tables, and more.
Create a backup of your current live shop.
Repeat 1-3 steps and follow your documentation in your live shop.
I think you can move everything in a few hours if you have a step by step guide.

Related

Why is it better to work on a local website copy than live on the website?

I used to work on the live website when I'm editing a website (I'm working alone), but some people told me "it's the old way". I'm inclined to evolve and I like to work, but how can't I lose time doing this?
First, that means that I need to get a copy of the website on my computer. I need to copy the files, dump and restore the database, first waste of time. If my customer adds extension on the website in the meantime(for example, Wordpress) my modification should be impacted then I need to add it on my local copy to. If I need to modify the DB I will need to do it on the local copy too.
Secondly if I want to show a work in progress to my customer I need to apply all modifications to the live website and check than everything works, still a waste of time.
And finally when everything is ok, I need to update again the live website, files and DB.
So, there's two options:
this is not the correct way to do and there's tools to do all that transparently (I hope so)
this is not a waste of time but a needed time to work properly (I understand why agency have big prices and I'll keep my method)
It depends on the complexity of the project and the size of your team.
One of the major risk of working on a live site is the introduction bugs in production. You also want to have some confirmation of functionalities developed from QA or your customer before having your users access them.
Basically, you want to make sure your new code does not break the live site, so working on the local instance could help you in this way, and you could also deploy on the live test site you changes for approval and QA.
Also if you working with a larger team working on the live site just won't scale up and the risk of introducing bug is even higher.
You could consider using docker, to simplify development on your local machine.

Composite C1 - develop locally, sync to live site

I have a couple of Composite C1 CMS websites.
To edit them currently I use the web based CMS on the live site.
However - I would like to update the (code & content) in Visual Studio locally - then sync to the web. However, if my local copy is older than that online (e.g. a non techy client has edited something on the live site) and I Web Deploy - it will go over the top of the new file on the server.
I need a solution that works out the newest change? I can't find anything in Google or the C1 docs.
How can I sync - preferably using Web Deploy. Do I need some kind of version control?
Is there a best practice for this - editing the live site through the web interface seems a bit dicey & is slow.
The general answer to this type of scenario seems to be to use the Package Creator. With that you can develop locally, add the files you've changed to a package, and install that package on a live site. This solution does not at all cover all the parts of you question though, and has certain limitations:
You cannot selectively add content to a package. It's all pages or no pages.
Adding datatypes is easy, but updating them later requires you to delete the datatype (and data), and recreate the datatype.
In my experience packages works well for incremental site updates, if you limit the packages content to be front end stuff, like css, images and such.
You say you need a solution that works out the newest changes - I believe the only solution to this is yourself, with the aid of some tooling. I don't think there's a silver bullet solution here.
Should you use a version control system? Yes! By all means. Even if you are not sharing your code with anyone, a VCS is a great way to get to know Composite C1 from a file system perspective, as you can carefully track what files are changed on disk, as you develop. This knowledge is crucial when you want to continuously add features the a website that is already alive and kicking - you need to know what to deploy, and what not to touch.
Make sure you read the docs on how Composite fits in VCS: http://docs.composite.net/Configuration/C1-and-Version-Control
I assume that your sites are using the XML data storage (if you where using SQL Data Store, your content would not be overridden upon sync).
This means that your entire web application lives in one folder on disk on the web server, which can be an advantage here.
I'll try to outline a solution that could work for you, although I must stress that I've never tried this - I'm making it up as I type.
Let's say you're using git, download the site in it's entirety from the production web server, and commit the whole damned thing* to your master branch.
Then you create a new feature branch from that commit, and start making the changes you want to deploy later, and carefully commit your work as you go along, making sure you only commit the changes that are needed for your feature to work, to the feature branch.
Now, you are ready to deploy, and you switch back the master branch, and again download the entire site and commit it to master.
You then merge your feature branch into the master branch, and have git do all the hard work of stitching you changes in with the changes from the live site. There are bound to be merge conflicts, and that is where you will have to jump in, and decide for yourself what content needs to go live.
After this is done and tested, you can web deploy the site up to the production environment.
Changes to the live site might have occurred while you where merging, so consider closing the site, or parts of it, during this process.
If you are using SQL Data Store i suggest paying for a tool like Red Gate's SQL Compare and SQL Data Compare or SQL Delta, to compare your dev database to the production database, and hand pick SQL scripts that can be applied to the production database along with your feature deployment.
'* Do consider using a .gitignore file to avoid committing certain files - refer to the docs for mere info.
I suppose you should use the Package Creator
Also have a look here: http://docs.composite.net/Configuration/C1-and-Version-Control

Upgrade nopcommerce 2.8 to 3.10

Hello,
I am new in NopCommerce. I have change in Nop.Core, Nop.Data and Nop.Services. I have change also in some controller, Model and view of Nop.web.
If i wish to upgrade nopcommerce version from 2.8 to 3.10 then, which way is easy and best.
1) I backup my file and get update. Once update is finished then, may i replace only those part which i have updated and differ from original code? May i add new method which is in my backup file but not in original code?
2) Or May i have to create new plugin or other way.
[For example: I have change in product table and add new fields like size, age, color.]
Please let me know your valuable feedback.
Thanks
There is no straight right or wrong answer. I am suggesting on the approach i took. Assuming you have code changes and database changes on top of base nop 2.80.
Ground Work
Write down a detailed modifications list. (Additional functions you have added on top of 2.80.)
Check with 3.10 if any of your modification is supported out of the box.
My modification count was 250 (very detailed up to estimation).
Approach
Upgrade 2.80 db to 3.10 db.
Modify 3.10 code to support new features of 2.80.
DB Upgrade
Find a good database diff tool. ex: SQL Compare.
Restore your production (2.80) DB to your dev pc and install nop 3.10 db into your dev pc as well.
Compare both DB table by table. Basically, you are going to upgrade 2.80 db to 3.10 db by comparing 3.10 schema.
Alter/Delete/Add new columns in 2.80 by comparing 3.10.
Create Store information (Store table). This is new feature in 3.10 and StoreID is needed for most other tables.
Update customer data to match 3.10 schema.
Update products information. ProductVariant table is now merged with Product table. So need to update product table.
Update Order details. OrderVariant is now OrderItem. So move the data.
Move other tables.
I used to create single SQL Script which,
Restores Production DB from a backup file.
Script block for each table which, upgrades each tables and populates data.
This gives you flexibility of run and run and again run the script if there is any error or even this is helpful during scripting.
In addition to this, if you are merging 2 or more stores in to one,
Add all store information in step 5.
Now create a separate script for each store from this point.
You need to find different sequence number for OrderId & Customer id. Can't be same.
When you add 2nd or more store, check for existing customer before adding.
Check 01
Now take a fresh 3.10 code base and run against your migrated db. All should work well if you have done migration properly.
Code Upgrade
There is significant changes to be done on code simple because there is noProductVariant table. So all the custom logic needs to be re written.
Main issue is, invoicing. If you have more than one store, there is no email setting per store basis. So have to custom modify that too.
A good approach would be,
Do all the customer side eCommerce fist.
Then do the admin side.
If customer and admin in same functionality, do together. example, custom modification on order placing work flow.
There will not be big modification needed for plugins.
Check 02
Run the migrated DB with Updated 3.10 code base. All should work.
On Big Day
Backup Production DB and Production Code base.
Run the Upgrade scripts and Replace new code base.
No 3rd Step, since you have done all the hard work before this.
Ok, if you screw up, then roll back.
Things to Note
I learned these by testing. thank god, i found them before actual migration.
There is no detailed instructions at the time we were migrating on how to setup a complete multi-store solution in nop commerce side. There is a instruction here on how to setup nop commerce in production server. but i is not covering all the aspects.
We were using VPS Server to host our platform. If you are using VPS, please beware that SNI is need to be used if you set up multi-store properly. Only IIS 8 and above supports SNI. Which means you need Windows 2012 Server. See here and here for more on SNI
We were using Pleask to manage the server. So set up master domain as primary and all other stores as alias. In IIS side, RDP in to VPS and Set up SSL for each domain using SNI feature of IIS8
Down side of SNI, it is not supported by all old browsers. See here.
Limitations
If you are using Pleask, then email wont work very well. Since email box will be created only for master domains and all other alias will share the same email accounts. So you can send a reply from alias email. unfortunately, its out of nop commerce development scope.
i haven't found a solution for this. working on this.
I'd recommend doing the database incrementally. According to the upgrade guide, you must apply the upgrade scripts one at a time, just read through the guide and have at it.

Create new model in Yii without using Gii

I'm new to Yii and am taking over maintenance of a fairly completed project. In all the books and web resources it only talks about adding new models/controllers etc using the Gii tool. I have looked in the config/main.php file of this project and the Gii module has been removed and also there is no index.php page for me to simply re-add it to. The project is live on a server already.
How do I add a new model to the site? I have tried duplicating an existing model and creating a new database table but I can't seem to access it from anywhere within the app. Would I also have to edit a file in the framework somewhere to add a new reference to this model?
Or do I have to create a local development environment replica of the site and use gii there, then add the new files (presumably not just the model file otherwise what's the difference?) to the server.
Gii model generator just create file in Model folder, so you just need to duplicate one of them and change all references.
If you create some different from other models class in that folder it will work, because of autoloader.
Probably you just forgot to change some info. Check file name. It need to be EXACT same as class name. For example if your model class name is Users your file need to be Users.php
It sounds like you are trying to modify production code in your live production environment. What happens when you do something to break the site? How long can that site afford to be off-line, or have things not working quite right? It is my experience that new development should be done in a development environment and then promoted to production. Otherwise you are forced to test your changes in your live production environment, and that is a dangerous thing indeed.
Given that you are new to Yii, odds are that you aren't going to be able to write code that is bug free the first time.
Best thing to do is create a development environment to mirror production, and install Gii there. Then you can create all the models and controllers you want with Gii, test your changes, and finally promote your changes to the production environment. This is really a best practice issue. You don't want to be changing your live code with untested code.

Creating a test site for updating a CMS

I have been asked by a client to make amends to their site using the custom CS system that was built for them (by somebody else). Making the changes is not a problem but they want the changed to be viewed on a test server before going live and the only way I can think of doing that is by pulling the entire site down, duplicating and reconnecting databases and uploading it to a test server. Then I would have to make all the changes twice which isn't really ideal.
Does anyone know of a way to do this that isn't such a ball ache? There's hundreds of files and data tables as you would expect with a custom CMS and for changes that would only take a few hours to do duplicating the entire site seems a tad unnecessary.
Cheers,
Sam
Does the CMS have "preview mode"?
Typically, in a CMS you make your changes using the content editing interface, save the changes, allow authorized users to view the changes in preview mode, and then change the status to "approved"; this then sends the changes live.
Different products call this by a different name, and have different ways of doing it - but it's worth rooting around in the custom CMS to see if there's something similar.