Porting a website to a different platform is not a piece of cake and I’m sure many of you will agree on this with me. Things become more curled up when you have to port your existing website to another platform. To port Codeignitor to WordPress is one of the same problems. In this article, I will walk you through all the problems that I faced when I ported my website to WordPress.
Let me start by giving you a brief explanation why I needed to port my existing website to the WordPress platform. Just to let you know, I was pretty happy with my website, I’m a web-developer and I really like to write each piece of code by myself that way I can control the quality of the website and performance. The need started to build up when I needed to make changes to my website. I had to get to code the pieces and bits myself even for a tiny addition to the functionality of my website. I did create a solid backed for blogging and media management but soon I realised that I cannot always do everything on my own. It takes a time to learn a new skill and then it takes more time to perfect it. And especially when you have your client’s work left over. So, it was becoming a tedious and time-consuming time for me. Instead of writing articles, my time was elapsed in coding. After all, Codeignitor is not a CMS (Content Management System), it is used to build the application that will serve a particular need and perform a particular task for what it is built for. So, I decided to port my website to WordPress.
Table of Contents
Best Way-Port Codeigniter to WordPress
Porting is something I had never done before. This was my very first time. I sure read a lot about porting and that things really did help me but you know, theoretical knowledge cannot beat practical experience. I was porting my existing CodeIgniter project to WordPress on the same domain and to a new server. Yeah, I saw it an opportunity and ported my website to a whole new server as I was not completely satisfied with the existing server.
Secure Your Existing Data
Let me tell you one thing, if you are porting your website to the different server then the biggest problem that you will face is the need to secure your data. I have read stories about how people destroyed their websites in the process of porting. You will have to pay special attention to this. Just plan ahead and keep patience, I repeat keep patience. Do not let excitement get you. I know dopamine levels in your brain gets high and fills you with excitement but do not hurry in this process. Backup all your data containing your files, images, database and all the other things that are there. My advice is to use reliable software for this process. In my case, I only had to port the images, documents and database, rest all my project files were synced with the Github. If you are new to development then I strongly suggest to learn Git and add this one skill to your resume. Follow the link to read about it? Github. In my case, I had to download about 400 MB of data, which I did with the help of Git. I created a new repository and pushed everything into it from my server. This facility may not be available for you if you are on a shared hosting, therefore, use FTP client. I prefer Filezilla. This way I backed up all the folders, files and images from the server.
I was using PhpMyAdmin for managing the database on the server. It was quite easy to export complete database with few clicks. Now, I successfully backed up my data and secured it. It took me about 2 hours. Now, the next thing was to set up the website on the new server. I didn’t make any changes to my existing website. Didn’t stopped it until I set up my website onto my new server. The next big problem that arises is maintaining your Google Page Rank. You do not want to make a bad impression in eyes of Google. Let’s see what I did to cope up with it.
Maintaining Google Page Rank
One of the most important phase in porting your website successfully. You must now take it lightly. One wrong move and all your hard work go in vain. The concept for preserving Google Page Rank is fairly simple. You just need to redirect your old pages to their new address with a status code of 301. You might have heard it somewhere about “301 Redirect” and if you are hearing it for the first time, well let’s say you do not spend much time reading.
What is 301 Redirect and why would you need it?
“301 Redirect” simply tells the web crawlers that the page current page has been shifted to their new location and then you provide the new location for the same. A real world analogy to this will go something like this, let’s say you moved to someplace to the outskirts of your city. Later, one of your friends came knocking doors at your old address. Now, imagine what would happen if no one will be there to address him. He won’t have any choice but to go back with a thought that he will never find you again. That is bad, Right? But what if you attached a note on your front door with your new address. That way he will know your current address and will move to your new house to meet. Same goes with the web crawlers, you must provide the new address for all the pages that has been moved.
It requires logics work it out. In my case, this was a little trickier because I had to move the website on the same domain without interfering with the WordPress page URLs. There was a?fewer choice in front of me.
- Copy Paste each blog with the same slug
it seems a more intuitive solution but what if you have more than 40 articles to port. You cannot just copy paste each of the blogs. Yes, you can make a resolution to port 5 articles every day which would take around 8 days to port all your articles, but what if you have more than 80 articles. Then what are you going to do? On the top of that what if you are lazy. This becomes a really tiring and time-consuming thing at this time. - Find a way out depending on your website’s architecture
I opted for this solution. I had to find a way to port my database completely without wasting my precious time and I found a really simple solution. I took my whole project and integrated it with the existing WordPress application and created a separated database to serve the data. It is like I’m running two different websites under the same domain. The old links will be served from a different database and all the new links will be served by WordPress database.
Pros and cons I faced with my later approach.
Pros –
- I didn’t have to do any heavy lifting
- This was a time-saving approach, I saved about 8 days with this approach
- There was near to no downtime
Cons –
- Complex redirect logic formulation
- Knowledge of the core functioning modules of both the Application
- Sooner or later you will have to change the old website layout to match the new one for better UX
Now, it is up to you to choose which a better solution is for you.
Redirection Logic
It all comes down to the structure of your website. My old websites permalinks were displayed in this format, www.olderversion.com/site/blog/345/article-slug/, and the current version has permalinks in this format www.currentversion.com/article-slug/ you can see the distinction here. So, all I had to do was to parse the incoming URLs, pass them to pattern match and if pattern matches then redirect the URLs safely to their new home. This redirection is pretty simple and does not require any advance knowledge on the developers’ part. You could write a Redirect Rule in .htaccess and put it in the root of your project. Here, is the redirect logic for the same,
RewriteEngine on RedirectRule ^site/blog/([0-9]+)/([a-zA-Z0-9-]+)/?$ HTTP://currentversion.com/project-folder/site/blog/$1/$2 [R=301,L]
This is it. It will match the incoming URLs pattern and redirect it their new home. Yeah, it’s simple but it did requires a redirect on the server part and though the performance affected is negligible, it is there. And too many redirects are not good. So, I didn’t opt for this solution. I simply changed the internal routeing pattern of the older website such that it will serve URLs in this fashion /blog/345/article-slug instead of /site/blog/345/article-slug. Then I simply changed the name of the project folder to site. So, automatically all the request will be mapped to their correct home. Plus there will be no redirection, therefore, saving the valuable server resource. If someone asks me about the performance lag in porting, I can say that there is no performance issue as everything is working the way it used to before. In fact, there are two different databases to serve different articles, which would instead improve the performance in times of heavy traffic. All that said, I recommend you to follow the redirection rule because it’s straightforward and less time consuming and you do not have to be an expert to do that. Copy paste the code and you are good to go J
Conclusion
Porting a website is really a few hours job given that you understand the architecture of your existing website and also the new platform that you are looking to port to. I know CodeIgniter and WordPress both very well, thus porting Codeignitor to WordPress was not that difficult. Hope you enjoyed the article and learned something from my experience. Just comment below if you face any problem or want to discuss more any phase of porting.
Cheers 🙂