I have a simple Wordpress website that is created using twelve twenty. I need to transfer it from server to my PC to be able to edit it and transfer it back to server. Now that I copied wordpress directory from server to my PC it asks me to reinstall it. How can I do it? Am I missing something? Is it possible to work on website locally and once it is done transger it to the server?
Reason for doing this are:
-don't want to loss data for wrong doing things.
-have a copy of website on local machine.
-easier to work on the local machine offline rather than bing online and accssing the server.
From my point of view , i would suggest u to back-up full website and database from server [every hosting control panels has option to backup same]
Connect via ftp and edit ur files.. there to make lots of changes when u want to move from local to server or server to local.
cheers!!!
Editing the files on a live site directly is a terrible, terrible idea. It invites any number of points of failure. If you're actively developing a site things will break at some point - it's part of the developing process - and you definitely want to break things locally, not on a live site.
There's actually several steps involved, all of which are too long to go into great detail, but here's an overview of what is required along with a few links to get you started. The first time you do it seems laborious, but once you figure it all out it actually only takes 10 minutes.
Firstly you will need a local environment MySQL and PHP environment to install it. As you're on PC look at WAMP; here's a fairly good tutorial on installing it.
If you have a lot of content on the live site you might want to import it into your local environment; you'll need to export the database (probably using PHPMyAdmin) and then import it into your local database. You will need to update a couple of database options so that it points towards your localhost. It's basically the reverse of the process detailed here: you'll be changing your-site.com to localhost:8888. If your site is relatively simple you could skip this stage*
Now you should be able to update your local copy of wp-config.php with the database connect details for your local database (usually it's just localhost for the host name and root for the user and password`). With that in place you should now be able to install WP.
Now that it's installed you can edit away to your heart's content on your local copy, safe in the knowledge that anything you do on your local copy doesn't affect your live copy. When you're ready to push your changes live you can use FTP to copy your local files to your live environment.
* For a lot of projects I don't actually go to the trouble of synching databases - if there's a live site that the client can change the content on it often becomes a futile exercise attempting to synch a database with a moving target. In those instances I'll just use a comprehensive set of test content that contains every conceivable type of content that could possible inserted in to the live site.
your going to love working on your project from your locally. Here's an article I found on wpmudev http://premium.wpmudev.org/blog/how-to-install-wordpress-locally-for-pcwindows-with-xampp/ which gives you a step by step guide for PC / Windows.
Related
I'm developing a website using Word Press (Elementor plugin) and I want to create a custom widget. I found a tutorial I want to follow (https://www.youtube.com/watch?v=Ko9i153o_iU), the only problem is that I have no idea how to access the code on my local machine to begin. From what I can tell, everything I'm doing is on the word press website, and the code isn't on my local machine. How do I go about getting the code onto my local machine so I can begin working with it in vscode?
You need a way to spin up local apache or nginx server and mysql, along with Wordpress. I suggest the app Local:
https://localwp.com/
Then, if you want to copy your production environment (your website), you need to get the files for the theme and any plugins onto your local environment. Local pairs with some hosting providers to make this easy. Otherwise you can install by downloading the files. Some hosting providers give you FTP or SFTP access to your site files. Figure out how you can gain access and download them.
Lastly, if you want, you can copy the database over to your local environment. There is a great plugin called WP Sync DB that does this for free. It can also be a way to push your local environment to your production environment, but I definitely suggest keeping backups if you are going to do that.
I have a WordPress website up and running with many plugins installed on it and a huge database, I need to use chef-solo in order to create an environment in which can install the same website with all its plugins and and also importing its database.
I need it to be like, using chef to install the same website on a different server, exactly the same
Now here are my questions:
I know we can use chef to install WordPress but can we set it in a
way that we don't need to configure the the WordPress and everything
is already set once its running?
What to do with the plugins? can we install them using the chef or
now that should be done manually?
How about importing the database, that can be done with chef-solo
as well?
The whole website is on git, can I somehow import the whole
thing?
is there any other issue I may possibly face? if I want do that?
There is a wordpress cookbook openly available for chef.
When you mean configure, I take it you mean setup data in the database. Assuming that you've separated the database instance from the server instance, and you're attempting to scale up the number of servers then you should be able to skip data setup. You should be configuring the new server instance (node) to point to the same database via Chef.
I stumbled into this question looking for the answer to this question. From what I can tell the start may be here.
Kind of hand-wavy, but this should enable you to do some wordpress stuff via the command line with Chef, rather than the point and click it prefers.
As per #1, you should not need to import the database. If the database goes down, you'll want to focus on that as a separate but connected recipe, since then you'll want to be taking snapshots and uploading them somewhere like S3 via a cron job. I believe there are plugins that can enable this.
You'll have to be a little more clear by "import". If it's in a code base you may be able to short-cut your cookbook path by pulling down the git repo onto the host. You may want to look at git-archive.
Other issues that I'm looking at are images. We're migrating from a hosted solution to AWS, and it appears that instead of storing the images in the database, word-press pulls them into a local directory. This means that if we scale to > 1 host, we'll have issues with images. Something to think about, there's a wealth of plugins that can probably solve this.
Hope this is helpful,
Ben
I am currently using Komodo edit for coding, and have a set up where I am using MAMP and a local install of Drupal, and SASS to build my site offline.
Once its ready test online, I upload onto the remote site. However, then I am working sometimes on the remote site and sometimes on the local one, and finding some problems.
I'm not using SASS on the remote site, so I am working in the CSS file. I don't have all the Drupal panels in code yet, so I'm having to rebuild them on the remote site, and I'm making tweaks and changes on the fly.
I end up with two slightly different versions of the site and need to keep track of the changes I want to keep from both. What can I do to clean up my workflow?
It would be better if I could work entirely locally and then sync that to the remote environment.
With something like Netbeans I think I could have a local copy of the site running and then right click and upload each file onto the remote server so there are two copies of the file.
I could do with some advice as to what the cleanest set up is.
I have an actual Dev server with its own ip and a live server with its own ip but they both connect to the same mysql server. There are two databases set up, db1 and db2.
I use a php script with basic sql instructions to:
Check which db is in use.
Backup that db (say, db1).
Sync the databases
Import that db into db2.
Once that is done, I use this:
cp webdb2.settings.php settings.php
So I always have two databases available and can roll right back (in this case with:
cp webdb1.settings.php settings.php) if something when wrong.
This seems to be a pretty good system. I only ever work on the dev, and then push it to the live with the process above.
The best thing that you can do is work offline an then sync the content (themes/modules) when you have to.
If you work on both you could lose data or lose track of code changes.
I just started a new position replacing a developer who left abruptly working on a project that is based in the Kentico CMS. I am completely unfamiliar with ASP and Kentico, so the answer here needs to be tailored for a total beginner. I am familiar with other languages (PHP, Ruby, SQL, etc.) but have no idea where to begin with this.
So, want I am wanting to do is copy everything from our production site (db and all) to my local machine so I can develop on it easier. I have already exported the db into an SQL file, and copied all the files in our Kentico Instance folder into github, and cloned it on my local machine. I assume since Kentico is already "setup," going through the installation process in their documentation is not the way to go about this.
Any help would be incredibly appreciated!
David, basically there are a few "pieces" to running Kentico locally. Since, as you mentioned, Kentico is already set up, you should have an easier go of it.
A database with the necessary Kentico tables (it sound like you
already have this)
The codebase (all of the code files that you copied to github)
A valid license for any domain you want to run Kentico on. Was the site already public facing? Do you know what licenses you have
or can you log into the CMS Desk on the site that you copied
everything from?
Set up IIS for your local website. If you are unsure on this one I can explain further, but basically you need to add a new site,
point it to the root code folder for your site, and set the domain
to be a domain you have a Kentico license key for. You'll also need
to change the app pool settings to "integrated" mode (most likely)
and also set the appropriate version of .NET (if it's a recent
version of Kentico you'll want .NET 4.0)
Next you'll need to edit your hosts file to add the domain and point it to your localhost IP address. So add a line like "127.0.0.1
dev.yourdomain.com" or the equivalent.
Edit the web.config file so that your code can connect to your database. You will need to edit the connection string accordingly to
point to the database on your machine.
Once you have done these steps, your site should start to run just as it had before. I didn't give great detail on all of these pieces so let me know what problems you encounter so I can further clarify. More information about the current situation would also help.
One other note I would make: if you need the client to be able to review your work, it will most likely be more efficient and easier for you to leave the original database on the web server, and (if possible) connect to it remotely from your local machine. Since almost any change you make will result in a database change in Kentico, I find it much easier to be working on 1 database for development with distributed codebases. Otherwise you will probably need to overwrite the other database with your changes constantly and this can be annoying. If you leave the database on the server and just connect remotely, you can just ftp (or use git) to push files to the server that you have edited locally.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-