Author: Andy Page 2 of 18

Moving a WordPress Site to a New Server

On November 26, 2020

In HTML/CSS, PHP/mySQL, Uncategorized, Wordpress

I recently had to install a copy of my wordpress site on localhost so I could test an upgrade without risking my live site. I used to do this a lot, but I’d forgotten the steps, so after I figured it out (again), I thought I should write it down…

Before starting: I moved my site to localhost. I run PHP/MySQL on localhost with XAMPP. I’m not going to provide a lot of details on every step. If you don’t know how to use XAMPP or phpMyAdmin, you’ll need to figure that out.

Step 1: Back everything up! Download all of your live site files to a local folder. Also, export your database. I export my database from the live site’s phpMyAdmin. Save the site files and database export somewhere that you won’t touch it. This is your fail-safe, just in case something really bad happens.

Step 2: Download all of your site files again. Yes, you COULD copy them from step 1, but that violates the principle of not touching your backup, so I don’t recommend it.

Step 3: Export your live site database again. You can copy your export from Step 1, but I think it’s a bad idea.

Step 4: Copy all of your site files to the new server. In my case, I created a wp_test folder in localhost/htdocs and pasted them in there.

Step 5: Open the wp-config.php file in in a code editor. It has info you’ll need for the next steps.

Step 6: Create a database on the new server. I did this through phpMyAdmin on localhost. This will be easier if you can give the new database the same name as the original (refer to DB_NAME in your wp-config file). If that’s not possible, don’t sweat it.

Step 7: Create a user for the new database. If possible, reuse the same user name and password as the old site (DB_USER and DB_PASSWORD in wp-config). Again, if your server won’t let you use these values, it’s no big deal. Generally, the hostname should be set to localhost. Since I was doing this on localhost, I gave the user full privileges, but if you’re moving it to another domain, you may need to be more careful about the privileges on your user. You can check the user account on the live site to see what permissions the user should have.

Step 8: Import the file from Step 3 into your new database.

Step 9: You need to open your wp_options table in the new database and modify the following entries:

site_url: change it to your new url. In my case: http://localhost/wp_test
home: same value as site_url

Step 10: If you were able to reuse your database and user info, you should be able to go to the site now. If you had to use a different user or database, change the values in your wp-config file to match the new values.

Step 11: You may need to fix some folder permissions tor things like image uploads to work correctly. Again, check the live site folder permissions for reference. NEVER use 777 permissions. 755 permissions should be what you need. That should do it! Check that you can click around your site and go to the admin panel. Things to watch out for:

Error establishing a database connection – means that your credentials in wp-config don’t match your actual user OR your MySQL server isn’t actually running.
404s on the pages – see this post.
Pay attention to the URLs of the pages and admin panel. If you didn’t do step 9 correctly, it might direct you back to your original live site. It’s important to make sure you’re not on the live site before making changes.

Let me know if I missed anything important in the comments!

Git Bundles – A Beginner’s Guide

By Andy

On February 28, 2019

In Uncategorized

I recently ran into a situation at work where I needed to share a Git repo “across an air gap.” In other words, I needed to be able to read a Git repo without actually having read access to the Git repo. I did some research and found out that this can be done with Git Bundles, but when I tried to look for info on how to actually USE Git Bundles, I mostly found a lot of Stack Overflow and Reddit threads with 23 year old know-it-alls providing helpful tips like “That’s stupid. Why would you ever need to do this?” The answer is that you work for a financial services company and they are paranoid to give developers access to anything that exists on the internet. Anyway, enough ranting. I pieced together a method for using Git Bundles that worked well for me and I thought I’d share it.

So here’s the setup:
A company we’ll call “OutsourcePro” is hired to build an application for your employer, who we will call “FullTimeJob.” OutSourcePro uses private Bitbucket repos for all of their projects and they offer to provide the devs at FullTimeJob access to the repos for purposes of doing regular code reviews. Unfortunately, FullTimeJob is a financial services company and finds the internet to be too scary to allow anything like Git repo access. So, FullTimeJob’s developers are told that they can’t have the access.

OutSourcePro offers to send a giant zip file with the entire project at intervals of their choosing (rarely or never). But, FullTimeJob’s developers find out about Git Bundles. FullTimeJob devs tell OutSourcePro to provide a Git Bundle every Tuesday and Friday. This will allow FullTimeJob devs to review the changes without needing to read every single line of code to figure out what’s different. FullTimeJob’s security experts agree that receiving a giant zip file via email twice a week is more secure than accessing a private Git repo directly (um… okay). Great! But, now what? The interwebs have very little useful info on how Git Bundles actually work. So, a developer at FullTimeJob does some experimenting and comes up with a plan:

Method 1: One-way Traffic
This assumes that all development work is being done by OutSourcePro and that FullTimeJob’s developers only need read-access for code reviews and whatnot. Developers at FullTimeJob will not be committing or pushing any code.

OutSourcePro creates a private Git repo (on Github, Bitbucket, or somewhere else).
FullTimeJob creates a corresponding Gitlab repo on their proprietary, enterprise Git server.
OutSourcePro does daily work and pushes ALL changes to to their private Git repo (including work in progress)
On Tuesdays and Fridays, an OutSourcePro developer pulls ALL commits from ALL branches to their local repository.

The OutSourcePro developer creates a git bundle:

git bundle create outsourcepro_DDMMYY.bundle –all

The OutSourcePro emails the bundle to FullTimeJob
A FullTimeJob developer copies the bundle to their Desktop and clones it to a new folder:
```
git clone /Users/FullTimeJobDev/Desktop/outsourcepro_MMDDYYYY.bundle
```
This will clone it into a folder named for the bundle: outsourcepro_DDMMYYYY
The FullTimeJob Developer should then point the origin of the new local clone to their private enterprise Git server:
```
git remote set-url origin https://ftjgitlab.com/project/repo-name.git
```
Once the origin has been set, the FullTimeJob developer can push all changes from the local clone to the enterprise remote.
Once all the changes have been pushed, the local clone should be deleted from the FullTimeJob developer’s Desktop.
Now, all FullTimeJob developers can fetch/pull the changes from the enterprise remote to their local repos.

Basically, this process allows you to make a duplicate of the Git repository on your own server and keep up with the changes being made by the OutSourcePro team.

Method 2: Two-way Traffic
What if developers on BOTH teams needed to make changes to the code? This use case is actually very similar, with both teams sending Git bundles to each other and following the process above. But there are a few tips I will suggest to make it easier:

Don’t cross the streams! Before starting the project, decide what each team will name the branches on their Git repos, and make sure that the two teams are ALWAYS USING SEPARATE BRANCHES. Same-named branches will cause chaos. In our example:
- FullTimeJob will eventually own all of this code, so they name their main branches “dev” and “master.” All other branches on their end will be named “ftj-something.”
- OutSourcePro will eventually hand over all of the code, so they name their main branches “osp-dev” and “osp-master.” All other branches will also be named “osp-something.”
Decide who will do the merging into the final repo branches. Again, in our case:
- FullTimeJob will own the code and the final project will reside in the “dev” and “master” branches create by FullTimeJob. So, only FullTimeJob developers are allowed to merge code into these branches.
- Similarly, OutSourcePro owns all of the “osp-” branches and only OutSourcePro devs are allowed to merge anything into those branches.
Both teams should be merging the other team’s work into their branches regularly and resolving the conflicts.
Nail down specific times when new bundles will be delivered to each team so that the syncing and merging can be done at scheduled times.

That’s it! I suggest testing this out internally before you try to do it in a real-life scenario. Have two developers act as members of the two teams. One developer can create a git bundle and send it to the second dev, who will follow the process of trying to duplicate it to a new repository. Then, have the first dev make some commits and send another Git bundle to the second dev who tries to add the changes to their duplicate repo. Good Luck and let me know if I missed any important details!

Running XCode projects on a device without a developer account in XCode 7

By Andy

On June 19, 2015

In ios, iOS Game Dev, Uncategorized

One of the announcements at WWDC 2015 was that developers would be able to test apps on devices without a paid Apple developer account in XCode 7. I was just about to drop $99 on a developer account so I could test a personal project on my devices. So, I decided to dig in and figure out how to do this.

IMPORTANT NOTES BEFORE YOU START:

You can’t do this if you have any developer accounts in XCode. This makes sense, really. If you have a developer account, then you can already test your projects on a device and you don’t need to do this.
If you follow the steps below, your accounts will change across ALL versions of XCode on your Mac. So, if you need to keep your developer accounts in XCode 6, do NOT follow these steps.

Now that you’ve been properly warned about the ramifications, let’s get started…

Step 1: Download XCode 7 beta. Please note that XCode 7 beta is still pretty rough and you may need to go back to XCode 6 for certain things.

Step 2: Remove any developer accounts in Xcode. Open XCode Preferences and go to the accounts tab. You can’t have any accounts in here that are connected to any Apple Developer accounts. This means that you can’t have a paid developer account, but it also means that your Apple ID can’t be part of any free developer accounts (like Safari development). If there are any developer accounts in here, you need to delete them. The easiest thing to do is simply delete ALL of the accounts listed in here, then add them back in later as needed.

Notice how the Apple ID I’m using says “Free” under the iOS and Mac headings:

Step 3: Open an Xcode project and connect your device to your Mac.

Step 4: Check your project build settings. Choose your project target in your XCode project settings and go to the Build Settings tab. Make sure that your Code Signing is set to iOS Developer and your Provisioning Profile is set to automatic.

Step 5: set target device in XCode as shown:

Step 6: Run the app from Xcode

Step 7: Choose the account you want to use. If you deleted all of your accounts in step 2, you will be prompted to sign in with an Apple ID. Again, you must use an Apple ID that is not tied to a developer account.

Step 8: Apple may prompt you to fix issues with your certificate or provisioning profile. If this happens, click the “fix issue” button and let Xcode handle it for you.

If this process fails for any reason, here are some other things you can do:

Open Keychain Access on your Mac and delete any development certificates in here. I had some old, expired certificates in my keychain and deleting them cleared up some problems.
Go back to XCode preferences and check that the Apple ID you used is not connected to any developer accounts
Worst case scenario: remove all accounts from Xcode preferences and create a brand new Apple ID with a new email address. This should force XCode to use a free account.

Just like any normal Xcode provisioning, it sometimes takes a little fiddling around to get it working. If you find any other tips, leave them in the comments.

Good Luck!

Kenny Login is Available Now!

By Andy

On February 12, 2015

In Android, HTML/CSS, ios, Mobile Apps, Uncategorized, Wordpress

After months of procrastination and delays, I’m proud to officially release Kenny Login – a fully responsive HTML5 theme for your WordPress Login page. Version 1.0.0 is available now as a free WordPress plugin. Simply install the plugin and activate it through your admin panel. Blam! Kenny Loggins all up in your login page! Click here to get the lowdown.

Log in to the Danger Zone!