The Technical Side To Rebuilding A Website

Concept

Concept

Joined
May 17, 2015
Messages
276
Likes
379
Degree
1
Hey guys,

Recently I mentioned that I have been given the go-ahead to redesign their website. My experience is limited to when I managed a team to redesign our company website (7 years ago). However, I’m doing it on my own this time, and my on the ground technical knowledge is limited.

I’d love to get feedback, or at least pointed in the right direction.

Here is what my initial idea for a plan is:
  • Create a subdomain. Eg newsite.website.com (will have to research how to do this)
  • Implement WordPress and import original site content etc and start creating the site on newsite.website.com
  • Once the newsite is complete, move it over to website.com (will have to research how to do this)
Firstly, I’m not sure if the above is best practice. Did you seriously cringe reading that plan? If so, what’s missing and what could I improve?

And as I mentioned, I will need to do some further research into the process. Does anyone have any good resources or guides that could help?

Or do you have a completely different way that is easier and less risky?

Appreciate your help guys.

Cheers
 
That's about as simplified of a plan as it gets. It sounds good in theory. Feel free to use this thread to ask questions live as you go. I'm happy to answer anything regarding your servers and if you have cPanel and how to import a database and all that.

There are little things to consider as you go. I'll go ahead and mention this so you don't hurt your rankings in the meantime. I'd use .htaccess to block out all IP addresses but the ones you'll be using during development so Google doesn't crawl and index the Wordpress site. Because Wordpress will start pinging those Ping lists that Google uses as starting points for crawling.
 
Ryuzaki said:
That's about as simplified of a plan as it gets. It sounds good in theory. Feel free to use this thread to ask questions live as you go. I'm happy to answer anything regarding your servers and if you have cPanel and how to import a database and all that.
Click to expand...

Cheers mate, will do. I'll likely use this thread, similar to a case study thread. I'll post up what I plan to do as I go. Hopefully, it will help newbies with something like this. It will also give you guys a chance to pull me up on anything before I blow everything up.
 
Ok, here’s what I’m thinking of for step one.

As I see it, I have two choices:
  • Build in a Subdirectory
  • Build in Temporary Hosting
I’m leaning towards temporary hosting. Here’s why:

The people who built the website original also apparently host it in-house. As a result, I don’t have access to the cPanel, the hosting is slow and it is also expensive for what my client is getting.

For this reason, I’m thinking of building the website on new hosting (Siteground) which the client is open to.

My understanding is I can use the temporary URL to test the new WordPress site before pointing our domain to the new hosting servers.

There seem to some guides to doing this including:
Once I’ve set up the temporarily URL, my understanding is I can build the Wordpress as normal?

Once I’m finished, the plan is to point the domain to the new website.
 
I recently did it and I used that method too.

For the htaccess you can do this: http://www.htaccesstools.com/articles/password-protection/

And you can add this after "Require valid-user"
Code: 
Order allow,deny
Allow from YOUR IPs HERE
Allow from YOUR IPs HERE
Allow from YOUR IPs HERE
satisfy any

You can use the duplicator plugin for transferring the files and the database
 
I wouldn't do it on the sub domain, since you are looking to move away from the current setup.
How large is the site - how many pages?

Get a new domain and host it somewhere else or other option would be to do the dev on local install of WP.
 
Build it locally. Set up apache and vhosts so you can work on thedomain.dev, which you point at localhost with your .hosts file.
Vhosts seem like more effort than a local subfolder eg http://localhost/thedomain but it will save a bunch of hassle with relative paths etc.

working locally, you can edit files much quicker (no upload > refresh cycle), load much quicker (no network latency) and use a proper IDE with code completion, function and method lookup, go to definition, step through debugging etc etc.

You can push the local copy somewhere on the internet for you client to view periodically (i tend to use a subdomain on a short nondescript domain i own, eg clientsdomain.xxx.uk.
Put the whole staging site behind basic auth so its not available to the whole world:
https://www.wpwhitesecurity.com/wordpress-security-hacks/securing-wordpress-wp-admin-htaccess/
(the link shows how to do it for the wp-admin directory, but its easy enough to see how to do it for the whole site)
This is more client friendly that IP restrictions (they want to be able to show it to people on their phones etc).

Also be aware that importing the existing content could be easy (wordpress export tool) if the current site uses standard wordpress features (post content and meta fields) or a huge manual ball ache if it uses some form of pagebuilder plugin / shortcode hell, so you might want to do a dummy run before giving a solid quote on this.
 
The actual dev site location is of less importance, at least initially. With Wordpress, personally I'd recommend always starting with a local copy (WAMP, XAMPP, etc. helps a lot with local setup). Sometimes it's just good to experiment, move fast, and break things without it being live or having to worry about yet another server. This is great for doing quick test runs, especially with things like @Steve mentioned, to confirm if you're gonna have major issues with migrating custom data. Consider this first step as sort of a "proof of concept", to identify as many unforeseen issues up front.

Clients normally want to see the work in progress, to occasionally affirm things are on track. Usually when I hear a web dev company also "owns" and/or is the sole manager for a site's hosting, that's a red flag. I'd sidestep all of that, and when the time comes after your initial local tests, I'd fire up a new install on a separate host.
 
You must log in or register to reply here.
Back