I'm relatively new to web development and I have some serious concerns about repairing/editing/fixing live site.
I use WordPress and its DB hold also configuration, so let's say that I need to do some work on website with e-shop. I will start website on my local with current version of DB from live website. But in few hours, when I'm done, I can't just overwrite live DB with my DB from local environment, because there are some new orders, posts etc.
How can we deal with this kinds of things?
Thanks everyone who will share his advice or experiences!
First youhave to make note of all the changes you are making in the files. You have to document it properly.
Next there are actually three cases
i) When changing the files alone
if you are changing just the files then obviously no need to change the database only the files needs to be updated. First no need to hack the core wordpress files as everything can be done through "actions" and "filters" method. I mean by creating a plugin so your core files are safe. https://codex.wordpress.org/Writing_a_Plugin
ii) When chaning the database alone
if you are chaning the database instead of deleting the entire datase and reloading you can simply alter the tables using "ALTER" command http://dev.mysql.com/doc/refman/5.7/en/alter-table.html.
iii) Changing both databse and files.
Follow (i) and (ii)
Related
My WordPress files are downloading instead of executing on the server. I have tried changing the server but that does not solve the issue. I am sure it is happening from my WordPress files as the hosting runs other WordPress files smoothly.
I wish I could could provide the code but that isn't needed. Please guide me. Thanks.
I have only seen this happen when:
1) PHP is turned off or not installed on the server
2) The server needs to be reset
3) File names are not correct
4) The redirect script is not redirecting as it should
5) Links are not valid
The good news is most of these can be solved by you/your host. Call your host to ask them for help on verifying the PHP install/process. If everything is good (for instance, if you have another site on the same server that is working fine) then you need to verify file names. As this is WordPress and the file names are all pretty standard this isn't exactly likely but make sure there are no unwanted spaces and the file names are "something.php". With WordPress you may see a bunch of parameters passed through the URL so "something.php?blah=blah" Is fine too (no space between php and ?).
Check the link you are clicking. The file names might be good but the link may be bad. It might be as simple as fixing all the link URLs. From what I recall of WordPress, there is a built in method of linking to pages within the same WP site. I believe these are all based off the URL in the database so you may want to verify the URL in the database/config file to verify WP is sending them to the correct place. If they are not stored in the database and are instead, coded directly into the content, you may have to manually update every link to the correct URL.
Finally, if it is script or wordpress related you may want to consider a fresh WordPress install. The good thing about WordPress is all the good stuff is in the data base:
1) Make a backup of the data base
2) Trash your WP install completely
3) download and install new WP with desired plugins and themes
4) Restore database
If the last step breaks the server again, check URLs within the database: http://codex.wordpress.org/Changing_The_Site_URL
Your Host can usually help in backing up and restoring WP databases. Even godaddy (who does not support it) will often help you walk through the process (you really want to call the hosting team. As an ex-godaddy employee, those guys are the experts).
If this isn't enough information, please provide a link to the site. It will allow me to do some quick troubleshooting to determine the overall issue.
EDIT: Help for verifying php install
Create a php file with the following contents:
<?php phpinfo(); ?>
And upload it to your site
This will make information about your PHP install easily accessible
Note: DO NOT LEAVE THIS FILE UP PERMANENTLY AND DO NOT POST A LINK PUBLICLY, YOU DO NOT WANT RANDOM PEOPLE ON THE INTERNET ACCESSING THIS INFORMATION
If you can access the file and it loads up a bunch of information in a purple (I believe it is purple) table, your PHP install is up and running. If the file just downloads like the rest, contact your hosting provider.
I'm helping a friend migrate her wordpress server to GoDaddy, and I think I may have bitten off more than I can chew... I've never migrated a wordpress before. This page here is the Wordpress wiki for moving Wordpress when your domain isn't changing. It doesn't seem to complex, but I'm terrified of accidentally ruining this website and I don't understand a couple of things on the wiki.
The Wiki says
If database and URL remains the same, you can move by just copying your files and database.
Does this mean that I can just log in to her server from Filezilla and copy all of the files on the server? What does database mean, is that something separate from the files on the server?
If database name or user changes, edit wp-config.php to have the correct values.
This sort of goes with my first question.. What initiates a database name or user change?
Apologies for my ignorance, but after an hour or so of searching around for these answers I'm left just as confused.
Last but not least, is there anything else I should be aware of when migrating a wordpress? I'm a little nervous..
You are going to need to migrate you instalation in two parts.
Part 1 you already eluded to. You will need to copy the files from one server to another. I am guessing you know how to do this so I will not dive any deeper into it. If you do need more explanation, please let me know and I will edit the question.
Part 2 is what you mentioned but said you did not understand. Copying the database of wp install. Wordpress runs off of PHP and MySQL. The "files" part in part 1 is the PHP files (along with some html and css). You need to log into his MySQL server and do an export of his database. You should be able to export the database (How to export mysql database to another computer?) and import it into his new server on GoDaddy. (Error importing SQL dump into MySQL: Unknown database / Can't create database).
Just take things slow, follow the guides that I have linked and do not delete anything from the first server until everything is working on the second. Please let me know if you do not understand anything.
if you don't feel confortable with database exports and imports, try using plugins like:
http://wordpress.org/plugins/duplicator/
or
http://wordpress.org/plugins/wordpress-move/
Check his docs for info.
Luck!
• A database is literally a data base. It's where websites (and other applications) store their data eg. For Wordpress, it would be data such as posts, user information etc.
If you are using a cPanel setup then you would need to get access to it and navigate to phpMyAdmin which is the GUI for managing a database.
Now I'm not sure what type of setup you're using but that should be a start.
• A database has a connection server address (usually localhost), a database name, username and password. These are setup at the time of setting up a database.
When migrating servers, you would need to update those details in the wp-config.php file (I think around line 19 or so).
• The annoying part about migrating Wordpress to another server is the domain change as you have to update the old domain with the new domain throughout the database. However since you're not changing domain names, it should be a smooth ride as long as the new server supports PHP and has a database.
I developed a magento site locally and it was and still is working fine. I need to put it on a public URL to show people though so I've set it up on a subdomain.
I have uploaded all of the files, copied the database to the live server, amended the database connection details and cleared the cache and session folders. I just get a load of wierd symbols when I try and view it in my browser. It is at Click me
You can check if the settings of the webservers are alike. If it is a cloud spaced hoster ask them if their server is capable of running Magento.
Also make sure the compiler is disabled and there are no other cache modules active.
You can't "copy" a Magento database, you'll have to create a new one at your new location.
Every installation needs its own database as many variables are different...
Copy it over and amend the core_config_data table so it contains the new URLs of your store. You will also want to flush the cache and empty out any session data in the database, as it will relate to your old URLs (probably won't matter too much, though).
I'm doing a manual WordPress update.
I backed up the database to a .sql file.
Is there any way to prevent write to database temporarily while still allowing read to the whole MySQL database?
This is to ensure
The backed up database is up to date
Users are still able to browse contents on my website without disruption (I will put up a maintenance notice that your posts will not be saved etc.)
Update
The upgrading activity is only used as an example here.
I'm planning to make some changes directly to the database as well and it will take a while.
I'm sure I have seen websites (famous one) showing that they were under maintenance and that my comments/ posts would not be recorded (no write) but I was still able to browse their websites (read is ok).
I thought it was quite a reasonable need, was it not?
I'm sure there must be a way to
Serve the caches of webpages (server-side) to users while not connecting the the database at all in up to a couple of hours (logging in/ registration will not available to users but that's ok)? How do you think I can achieve that then?
To lock out any visitors from posting comments and such, you can go into phpmyadmin, find the wordpress user account (DB_USER as defined in wp-config.php) and revoke its insert, edit and update privileges. But this will probably not degrade gracefully into user friendly error messages when they still try anyways ignoring your messages. And if you are doing an update through php script in the way the wordpress installs itself it may still need these privledges to make any necessary modifications like adding options to the options table.
What version are you upgrading from and to? I know the install took me all of 30 seconds, and I can't imagine there would be a huge change in database between updates. But then again WP can be highly customized and I don't know the extent your site deviates from the standard install.
Sorry I'm about to go to sleep so I won't go into depth but one way that works for sure is if you have two MySQL users, 1 for your website to read/write from and another to do your maintenance. Your first user, you can change his privileges temporarily to read only and that should work.
We're currently designing a rewrite of our PHP website. The new version will be under SVN version control and have a separate database for development and live sites.
Currently we have about 200,000 images on the site and we add around 5-10 a month. We'd like to have these images under SVN as well.
The current plan is to store and serve the images from the file system while serving their meta data from the database. Images will be served through a PHP imaging system with Apache rewrite rules so that http://host/image/ImageID will access a PHP script that queries the database for an image with the specified ID and (based on a path column in the table) returns the appropriate image.
The issue I'm having is keeping the image files and their meta data in sync between live and development sites.
Adding new images is (awkward, but) easy for the development team: we can add the image to our SVN repository in the same manner we do all files and manually create the meta data in both the live and test databases.
The problem arises when our employees need to upload new images through the website itself.
One viable solution I've been able to come up with is having our PHP upload script commit the new images to SVN and send INSERT queries to both live and development databases. But to me this seems inefficient. Plus SVN support in PHP is still experimental and I dislike having to rely on exec() calls.
I've also considered a third, separate database just for image meta data. As well as not storing the images in SVN (but they are part of the application and not just 'content' images that would be better off just being backed up).
I'd really like to keep images in SVN and if I do I need them to stay consistent with their meta data between the live and development site. I also have to provide a mechanism for user uploaded images.
What is the best way of handling this type of scenario?
The best way to handle this would be to use a separate process to keep your images and meta data in sync between live and dev. For the image files you can use a bash script running from cron to do a "svn add" and "svn commit" for any images uploaded to your live environment. Then you can run a periodic "svn up" in your dev environment to ensure that dev has the latest set. Mysql replication would be the best way to handle keeping the live and dev databases in sync given your data set. This solution assumes two things: 1) Data flows in one direction, from prod to dev and not the other way around. 2) Your users can tolerate a small degree of latency (the amount of time for which live and dev will be out of sync). The amount of latency will be directly proportional to the amount of data uploaded to prod. Given the 5 - 10 images added per month, latency should be infinitesimal.
I've had to solve this sort of problem for a number of different environments. Here's some of the techniques that I've used; some combination may solve your problem, or at least give you the right insight to solve your problem.
Version controlling application data during development
I worked on a database application that needed to be able to deliver certain data as part of the application. When we delivered a new version of the application, the database schema was likely to evolve, so we needed SQL scripts that would either (1) create all of the application tables from scratch, or (2) update all of the existing tables to match the new schema, add new tables, and drop unneeded tables. In addition, we needed to be able to prove that the upgrade scripts would work no matter which version of the application was being upgraded (we had no control of the deployment environment or upgrade schedules, so it was possible that a given site might need to upgrade from 1.1 to 1.3, skipping 1.2).
In this instance, what I did was take a tool that would dump the database as one large SQL script containing all of the table definitions and data. I then wrote a tool that split apart this huge script into separate files (fragments) for each table, stored procedure, function, etc. I wrote another tool that would take all of the fragments and produce a single SQL script. Finally, I wrote a third tool that was used during installation that would determine which scripts to run during installation based upon the state of the database and installed application. Once I was happy with the tools, I ran them against the current database, and then edited the fragments to eliminate extraneous data to leave only the parts that we wanted to ship. I then version-controlled the fragments along with a set of database dumps representing databases from the field.
My regression test for the database would involve restoring a database dump, running the installer to upgrade the database, and the dumping the result and splitting the dump into fragments, and then comparing the fragments against the committed version. If there were any differences, then that pointed to problems in the upgrade or installation fragments.
During development, the developers would run the installation tool to initialize (really upgrade) their development databases, then make their changes. They'd run the dump/split tool, and commit the changed fragments, along with an upgrade script that would upgrade any existing tables to match the new schema. A continuous integration server would check out the changes, build everything, and run all of the unit tests (including my database regression tests), then point the finger at any developer that forgot to commit all of their database changes (or the appropriate upgrade script).
Migrating Live data to a Test site
I build websites using Wordpress (on PHP and MySQL) and I need to keep 'live' and 'test' versions of each site. In particular, I frequently need to pull all of the data from 'live' to 'test' so that I can see how certain changes will look with live data. The data in this case is web pages, uploaded images, and image metadata, with the image metadata stored in MySQL. Each site has completely independent files and databases.
The approach that I worked out is a set of scripts that do the following:
Pull two sets (source and target) of database credentials and file locations from the configuration data.
Tar up the files in question for the source website.
Wipe out the file area for the target website.
Untar the files into the target file area.
Dump the tables in question for the source database to a file.
Delete all the data from the matching tables in the target database.
Load the table data from the dump file.
Run SQL queries to fix any source pathnames to match the target file area.
The same scripts could be used bidirectionally, so that they could be used to pull data to test from live or push site changes from test to live.
If you already have a solution to deal with data migration from dev to prod for your databases, why not store the actual images as BLOBs in the DB, along with the metadata?
As the images are requested, you can have a script write them to flat files on the server (or use something like mem_cache to help serve up common images) the first time, and then treat them as files afterwords (doing a file_exists() check or similar). Have your mod_rewrite script handle the DB lookup. This way, you will get the benefit of still having the majority of your users access 'flat' image files handled by your mod_rewrite script, and everything being nicely in sync with the various DBs. The downside is that your DBs get big of course.