i have a hosting where i put my domains files. i have one directory called wordpress where i installed a copy of wp. What i am trying to do is to do an SVN checkout on that folder.
but i get: Redirect cycle detected for URL '....
any ideas how to set it up so that i can grab those files on my computer and then checking them in after i make changes?
also, im not looking necessarily for something specific on wordpress, i might want to check out some other files lather on
thanks
You need to make sure that the folder you are trying to "checkout" is an actual SVN repository.
You can do so with the svnadmin create command. More info available here
Related
Me and my friend started developing a web site using a WordPress theme. I uploaded the source code on git hub and started doing changes on the website using the admin dashboard. But whenever git status command is entered in the bash, It says working directory is clean and no changes. Any idea why this is happening?
git tracks changes of the source code (or, generally, any files) which lie in the folder where the repository is located. But when you change something in WordPress or other CMS, these changes are typically recorded into database, not filesystem. Only files uploaded by users typically go to the file system, but not configuration settings (like titles and posts).
Is it okay to put my wordpress config file (containing database name, username, password, etc.) on my GitHub repo if I'm using wordpress with my website? Or is it not secure? Why or why not?
If it's not secure, what steps can I take to not put on GitHub since it's public but at the same time be able to use GitHub as version control for my website and push files to the server?
No, I would not upload your config file to your repository. Unless it's private, but even then...use caution. As a best practice I only add the theme folder that I am working on into the repository, there really is no need to add Wordpress in its entirety to the repo.
To ignore that file when pushing to your repo add it to your .gitignore (https://help.github.com/articles/ignoring-files/) and it wont be added.
In addition to using .gitignore to keep your wp-config.php file out of your repo, you can also move it one directory above where you have WordPress installed and WordPress will look for it there.
A relative has a wordpress based site that they want me to make a few changes to that I can't seem to find a way of doing from wordpress itself because it puts everything in categories but if something doesn't install itself fully or anything you can't find all the files. I want to have some kind of file manager so i can browse the website's filesystem directly, find the files and add the exact code I want to add, and be done with it without removing or disabling wordpress itself.
Use and ftp client to login. This will allow you to browse the file and folder structure of the server. Once you get logged in you can use......
dir - directory listing
cd - change directories
put add files to the server
get - pull copies of files from the server
There's more, but this should get you started.
Ok, so I'm familiar with creating local Wordpress builds, and have been chugging along happily with the technique outlined in Smashing's MAMP-based article. My question goes a step beyond this.
The article is great for developing generic themes, but when developing sites (not necessarily blogs) based in Wordpress, for me at least, it's a little painful come launch day.
I have to go back in and reconfigure the server's Wordpress to match what I've already done locally. Settings have to be entered again, plugins need be installed again, menus recreated, and css will have to be altered to reference the unique classes/id's Wordpress generates for posts/pages/custom taxonomies…sometimes things are missed in the process. What I want to know is this:
Is there an easy way to automate cloning or mirroring the build on my local machine to the remote server?
Even if you have to just LMGTFY me, that would help. I don't exactly know what I should be searching for. Searches dealing with 'mirroring wordpress configuration' and 'cloning wordpress configuration' returns tutorials on moving content, which I know how to do.
If it helps, I'm running OSX 10.6.8 with xcode dev tools, git, ruby, node, and homebrew. All of my live servers have ssh access as well as ftp, and I build with the most current versions of Wordpress.
Here are some easy steps to follow:
Download and install the WP Migrate DB plugin.
Go to Tools > WP Migrate DB and fill-in the blank fields(New address (URL), New file path and optionally check/uncheck the other options). Click on Export Database and save the export file to your computer.
Make a .zip archive with ALL of your files(the /wp-admin, /wp-content, /wp-includes directories and all files in the root directory).
Upload that file to your production server, where you want your WordPress site to reside.
Go to your cPanel(or use the unzip command through SSH) File Manager(or any other alternative that you might have) and unzip the file that you just uploaded.
If you don't already have a Database set-up on your production server - create one through the hosting control panel(for cPanel, it would be Creating a mySQL database in cPanel, for plesk it would be Plesk 7 Tutorial: Creating a database, for anything else, just google it up, or try your hosting's FAQ). Remember/write-down your Database Name, Database User and Password.
Edit the wp-config.php file and change the values for the DB_NAME, DB_USER, DB_PASSWORD and optionally DB_HOST - but this is usually localhost - if that doesn't work try asking your web host, or if you have phpMyAdmin, log-in to it and look at the very top of the page - in this case the DB_HOST would be localhost.
After you've done all of that, log-in to your DB administration tool(most of the time this would be phpMyAdmin, but it could be something else as well) and upload the database export file that you save to your computer in step 2. Note: If your hosting hasn't provided you with a DB administration tool, I would suggest that you upload the phpMiniAdmin(click on the "Download latest version" link and save the file to your computer) script to your production server. Then go to that script(if your website is located at http://example.com/, go to http://example.com/phpminiadmin.php) and enter your DB details. On top of that page, you will see an import link. Click on it and upload your DB export file. Note 2: phpMiniAdmin doesn't support gzip-compressed files, so if you did check the Compress file with gzip option in step 2, you will have to re-do that step with this option unchecked.
Log-in to your site and go to Settings > Permalinks in order to update your permalink structure.
Check the permissions of the /wp-content/uploads and /wp-content/plugins directories - make sure that you will be able to upload images and plugins without any problems.
That's pretty much it. It might seem like a lot, but I follow this process for almost every site that I upload to production servers and it can take me as less as a bit under 10 minutes to do all of that(considering that I usually use custom MySQL commands, instead of the WP Migrate DB plugin - I should probably start using it :) ). Once you get used to the process and you don't encounter any low-quality web hostings, you should be perfectly fine with these steps.
Note: Since you used ssh as one of your tags, I assume that you usually have ssh access to the production server. If you don't I'm still assuming that you have a cPanel access(if that's not true and you can't unzip files on the server, then upload all files manually via FTP client, instead of doing steps 3 and 4).
I guess the only way is to copy the database or part of it.
What I do is to copy the relevant tables and modify manually the site URLs in table options. There are only 2. There is also a nice plugin velvet-blues-update-urls to modify all links, after the site URLs are set manually to be able to access the backend, in case posts are also copied.
Next, copy all theme directory files to the same directory in the site, assuming you are using the same theme.
Both processes can be automated with a PHP script.
I am not sure this is what you want, but hope this helps.
Not sure that this is exactly what you need, but to move a site you can use the built in Wordpress "export" and "import" options. As far as I remember there was an option when importing to change URL's and the import would change a few things for you.
Even if this does not answer your exact question, hope it helps.
I run my blog using Wordpress and all too recently became a big believer in SCM. I really want to put my site into subversion (that's what I'm using right now, maybe git will come later) but I can't think of the correct way to do it yet. Basically, my repository is set up currently with an 'implementation' directory and a 'resources' directory, with implementation holding what will eventually be published to the live site. I want to be able to preview my site locally without having to upload to the server for obvious reasons. However, to do this I found that I needed to actually install Wordpress locally (not just copy the remote site down to my local box). This was told to me over at Wordpress.org.
This brings up the problem of being able to use SCM with the install because I need to upgrade my local site every now and then but this generates inconsistencies with subversion because it can’t track what’s going on because an external system is messing with it’s repository structure. That just won’t work.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
Anyway, I’m sure other people have tackled this and the solution is probably applicable to many apps similar to Wordpress (Drupal, phpBB, phpMyAdmin, etc.). So, how do you do it?
It's actually not that hard to do, but I'll break it down into a few suggestions here. What you're describing is more or less a "vendor drop" directory. This is basically where you maintain the code in SVN, but replace the contents with the newer stuff as it comes out.
What you should start with is an empty directory. Set up an SVN repository, and then do an SVN checkout into the empty directory (it will still be empty, except it will get a hidden .svn directory added). Next, install wordpress here normally, and then add its files to svn. You can probably just "svn add *" but be careful, and remove anything you don't want versioned (uploads/temp/cache directories, if applicable). You can also use the svn:ignore property to tell it to ignore certain directories or file types, if you'd like. Run "svn stat" to show you what is going to be checked in, etc, and once all is good, commit it (svn commit) and start working from there. Now you have a base installation of wordpress in SVN.
As you work and make changes, commit them.
When it comes time to upgrade, simply replace wordpress over top of what you have. Make sure when you replace directories, you replace the contents, and not the whole directory itself. You don't want to lose the hidden .svn folder in every folder because that is what will mess subversion up. Do an svn stat and/or svn diff to figure out what's changed, if anything, and mostly what's newly-added. At this point, you can commit again.
To deploy on your production site, you can do an svn export, or do a regular checkout into the web directory. If you do a checkout, be sure to only update when you are ready to deploy.
This is the method I'm testing. It takes some time to setup but you should then (in theory) have a future-proof install:
Installing WordPress The Right Way
Also look at svn:externals for pulling in plugin updates:
Use svn:externals to install WordPress plugins
I think the upgrade part can even be a little easier than that; I do this with the most current version of both 2.5 and 2.6, as well as bleeding-edge trunk revision of WP.
Since Wordpress offers all of their stuff as subversion repositories, getting the current rev of a stable tag is as easy as making the blog directory and then
# svn co http://svn.automattic.com/wordpress/tags/2.6.2/ (replace the current rev here for the first check out).
When an upgrade is available, simply navigate to your blog directory and run
#svn sw http://svn.automattic.com/wordpress/tags/2.6.3/ (or whatever wordpress rev you're updating to)
Then releasing to your production site is just an export, as gregmac mentions
However, I don't think this answers your actual question, which I interpret as "How do I keep my custom stuff in SCM while being able to upgrade Wordpress". Your instainct about what directories to tack is pretty much on target (your own personal blog's stuff - themes, pplugins - will be in wp-content, so you should only need to put that into subversion) but I'm not proficient enough with subversion to tell you how to place the directory into your own repository while still being able to rely on Wordpress's repo for upgrades. My "SCM" for those files on my site is an off-server copy of the wp-content directory.
Maybe from that standpoint gregmac's answer works better for you.
My initial inclination is to try to just SCM my theme information as this is really the only stuff that I ‘own’ while as everything else is really just part of my platform (no different than Apache or PHP, really). However, that’s where my understanding breaks down. How can I selectively SCM only part of that directory structure, and how can I maintain the configuration of Wordpress that I’m on?
That's exactly how I version control my blog. I've found that it works great. Generally, if you're editing WordPress' files, you're doing it wrong and will be in for misery when it's time to upgrade.
To simplify this, I use TortoiseSVN. I navigated to my /wp-content/themes/ directory in Windows Explorer, right clicked on my custom theme's directory, and chose import from the context menu. After importing all of the existing files, I performed a checkout on that directory and everything was set.