I copied the complete folder of my prestashop 1.7.3.0 on a new folder on my server with new database, install a new theme and maj prestashop in 1.7.7.0
The concern is that now that I have finished in the meantime I have had orders and customers.
I imported the products in excel redone the variations by hand.
How can I subsequently export customers and orders?
In excel import of my last clients it tells me that the password is required for the import?
What would be the best method even going on phpmyadmin to import the customers, addresses and orders that I miss on the new store?
Thanks for your feedback.
To align customers and addresses you can use Prestashop's built-in CSV import feature.
Regarding orders there is no standard way to do it,
you have to perform queries on the new database synchronizing the missing data of the old one, taking care to check the various tables of the site because there are several entities involved (and structure might change between PS versions too).
Also keep in mind that there may be third party modules on the old site that save data and therefore must be synchronized.
Other options: you'll put "catalog mode" on the live store for a few days until you've finished the work on the new one or use a paid data migration module that can perform incremental migrations.
Related
We had a company that developed a website for us, for a large amount of money. When the site was done we wanted to put it up on GoDaddy's hosting and the company said that it wouldn't work on GoDaddy and that we would have to leave it on their hosting servers at a cost of $300/mo, they say that because they have custom-built software that allows the customer to edit the website, that looks just like Joomla's editor. I am about 90% sure that the website was built with Joomla. I have built many websites, none with Joomla, so my question is, I want them to just give us the website files and database that we paid for, so we can go to another hosting company with our website that is a lot cheaper $25/mo. So what files do I ask the company for that developed the website to make sure we have all the correct files to transfer the website to another hosting company?
They are being very difficult to work with so I just want to make sure I know what files to ask for.
Any help on this would be greatly appreciated.
A Joomla install consists of files and the database so you need to ask for the files (probably as a zip file or similar) and an export of the database.
You can then restore the files and database on the destination server.
You will need to update the configuration.php file with the new database host, database name, database user and database password once you have restored the files to the destination host.
Alternatively you could ask for an Akeeba Backup file if they are using Akeeba Backup (which most Joomla website owners do). Akeeba backups up files and the database into one convenient compressed backup file which makes it easy to restore to the destination using the free Kickstart install tool.
Browsing certain urls can help verify if they are using Joomla. For example:
/administrator/manifests/files/joomla.xml
/index.php?option=com_content
/index.php?option=com_users&view=login
/index.php?option=com_search&view=search
Setup/Background:
I work for a product that contains 500k+ LOC predominantly (Java and Javascript). We have been running Fortify static analysis roughly for the past decade since Fortify 3.x/4.x. We use SSC to view and audit the analysis results. That way, the results are also made available to others in the team who may be interested in addition to the security leads.
Periodically, along with the code release, Fortify version is also upgraded and the metrics are migrated to a newer version. Fortify platform and upgrades are managed by a separate team. We just run the scan, upload the fpr. The results are automatically merged in SSC. Subsequently, we audit the newly found violations and re-mediate them appropriately. Usually for every release, there are hundreds of false-positives which are audited as "Not an issue".
Question:
We are moving to a new platform - there would be a fresh installation of Fortify SSC managed by a different team altogether. If we perform an analysis and upload fpr to the new SSC instance, it may report one million+ violations. In reality, these violations have already been audited as 'Not an issue' in our existing instance. We need a way to "seed" the newer instance with audited results from older instance.
So, we would need some way to export the results from existing instance of Fortify SSC and import the same in the newer instance of Fortify SSC.
From the existing instance, I know that I can "Download Application File" fpr from 'Application Artifacts' that contains all the audited results. I would like to know if in the newer instance of SSC, by importing using 'Upload Artifact', will be audit data be seeded? So that, from the next scan, we can simply keep uploading the fpr files and the only the delta violations will be reported.
Existing Fortify SSC is on version 17.20. Newer platform Fortify instance would most likely be version 18.10 or 17.20 but hopefully not below that.
It should work, give it a try. If this doesn't work, I think you can directly export the Database from the old instance, and import it to the new Database. If the two SSC versions are two far apart, the database schema may have changed a lot and the data transfer may be challenging. If you have issues, I would contact Fortify Support directly for help. They are usually responsive.
TL;DR:
It works.
Long Answer:
I have "Downloaded the Application File" from an existing instance of Fortify SSC 17.20. This will typically be in the format - .fpr
I have installed another instance of Fortify SSC 17.20.
Later, I created a dummy Application and a Version for the project.
I have imported the earlier downloaded fpr from Step 1 using "Upload Artifact". Now, the new instance of SSC took 3 days to completely import and provide audit/metrics etc
Ensure that the audit/metrics are same as the source SSC instance
Subsequently, performed a fresh scan and uploaded the new fpr.
Fortify SSC successfully merged and the artifacts. On subsequent uploads the existing audits are carried forward and no information is lost.
Hello I would like to ask how is it possible to migrate VM2 to VM3. I want to update my Joomla site from 2 to 3 and VM to be compatible. I found only that http://docs.virtuemart.net/tutorials/installation-migration-upgrade/198-upgrade-virtuemart-2-to-virtuemart-3.html please help I have many data on VM2 and I don't want to lose it.
this process should be careful, follow my procedures:
Go to official site installed VM Migrator plugin
before you should do all your backup sql in VM2 and VM3 sites
Also what I had done is add another Database called migration_vm2 in my server, and import vm2 sql, this could be avoid the problem and you could query one of table to compare
And for import the users and orders list and products you should use VM Migrator
There are some ways to achieve that. My pattern is mostly like this.
First attempt, update all Joomla components, install VirtueMart 3 via normal installer, install Joomla 3. If that fails:
Second attempt, use Daycounts Migrator and use a fresh J3/VM3 installation on the same server to transfer files and database with the migrator. If that fails:
Third attempt, compare the databases from first attempt or second attempt and export single db tables and import with the changed column names into VM 3 db.
Use a standard template like Protostar in the beginning, change to a new template only after everything else works.
This question is not answered in one answer here, I suggest the VirtueMart forum.
This worked for me. First download the newest VM package from the official site. Note that normally it is a compressed file with core component and AIO component zipped inside, so you will have to extract these first.
Second, in your Joomla 2.5 backend, check Extension Manager > Database tab and do a fix if necessary. Do not forget to do a backup of all your site using Akeeba or similar extensions. Keeping a backup of existing orders is good practice.
Finally, using the Extension Manager installer, upload and install the VM3 core and the AIO after that. Clear cache and check database fixes again if necessary.
Very important: clear your browser's cache to purge preloaded js files and so.
Check your VM3 frontend and backend, you should have all your items, registered shoppers, old orders and so. There can be some styling issues with new classes, also your shopper groups could be misconfigured, correct the prices to be shown... and thats it!
About the migration from J2.5 to J3, having VM3 installed has not been a problem for me so far. Always refresh your web browser cache after a migration in order to eliminate preloaded javascript files that are obsolete, otherwise you could have some problems trying to save menus, articles and so; just clear your cache again and thats it.
At work we use Oracle (12c client) to store most of our data and I use SQL Developer to connect to the database environments.
Issue:
We have issues where tables are being modified for one reason or another (too lazy to create a new table so they add new columns and change data types or lengths). This in return will break the table for others who actually utilize it for its real purpose.
Update:
We have DEV, TST, UAT, and PRD environments. We test and have scripts approved before we promote to PRD. The problem resides in DEV when we want to go back to an existing table to make an change, but that table had already been modified for different reasons.
Question 1:
Is the versioning just for stored procedures or is it possible to track changes to table structures, functions, triggers, sequences, synonyms, etc.?
As Bob Jarvis indicates you need way more than a solution to your question. You need policies and practices enforced for all developers. Some ideas from places I have worked:
every developer has a VM machine with a copy of the database installed. They can do whatever they like on it but must supply scripts to move their changes to production. These scripts are applied on a test instance and again on a QA instance before going to production.
subversion works on all OS and tortoise works well on windows. Committing scripts to a repository works well and this is integrated with SQL developer and can be done with Toad.
you have a permissions issue. Too many people have the privileges to alter tables. Remove these permissions and centralize on one or two people. Changes are funnelled through them as scripts and oversight can be applied there. Developers can have their own schema to test or a VM with a copy for development.
run this script to see who can alter tables
select * from DBA_TAB_PRIVS
WHERE PRIVILEGE = 'ALTER'
The key is a separation of concerns. Developers should have access to a schema where they can do what they need. The company needs to know who did what, when and where.
If you have more than one developer working on multiple changes to a dev environment then you need coordination and communication as well as source control. A weekly meeting to discuss overlap areas or a heads up chat message are just some ways to work together.
The approach I think works best, is to have a DEV database where all the developers manage their own set of schemas.
Scripted builds are provided with test data loads to allow any developer to create his own working schema. He then works on there, tests his changes and then commits his changes via scripts to the source control. DEV databases do not need to be large, just need enough test cases to allow for unit tests.
Script all the changes so that they can be checked into a version control system, and merged with other changes. The goal is to have a system where devA checks in changeA, and then when merged with the main trunk, devB gets changeA as he builds his schemaA.
This approach requires care if the main project schema employs PUBLIC synonyms. You will need to consider this as you go forward.
I would also advise with each change checked in an accompanying back out script should be checked in.
The advantage of this approach is that devs can manage their own schemas. With a scripted approach they dont all need to have DBA knowledge, and don't need to manage the database either. having all these on one database makes it easier to manage and control resources.
I've used this approach in teams with 50+ developers and it has worked very well.
This approach also paves the way for having devs checking scripts in and having a automatically creating a deployment package.
There is so much that can be done to make the development-test-deploy-backout cycle easier to manage.
For several years now I have freely hosted several local organizations web pages at no cost. One of those organizations wishes to move to their own server that they manage with their own server provider (alas, not A Small Orange--a little too expensive for them).
They have
a couple add on domains/websites
advanced DNS records with Google Apps
several mailing lists
a database or two
and of course their hosting directory
I was just wondering if there is a way to just export that stuff, so it can be imported in another cPanel?
OPTION ONE: One by one move all the stuff to the new host. Create the mailing lists, manually import the databases, set up the DNSs, and upload the files.
OPTION TWO: I could export the entire site, download the entire site, go to the new provider and upload it, and then delete all my content.
OPTION THREE: Is it possible to export their parts of the site, and import that to the other hosts cPanel?
Or another option all together? No email, and I don't even need the hosting history to be there (but it would be nice).
if you are moving from cpanel hosting to another cpanel hosting then just create a full backup of the website that you want to move from WHM which will backed up emails , databases , SSLs , sub domains , addon domains , everything in .tar.gz file format. Download that back up file then upload it to the new servers and restore it from WHM from Restore backup option in WHM.
OR
You can do live migration from WHM itself with Copy Accounts function from WHM which will be easier option to move the websites and the stuff.
However after migration you will need to make sure that you have assigned dedicated IPs , have configured the name servers properly ( the DNS part ) etc..
I would suggest to hire an expert to do this migration in order to avoid any possible issues.