Note: This is an updated version of the Proposal sent via GSoC website. You can find UI mock-ups and details of the backup procedure under the Project Details section. The original proposal did not have those mock-ups and details of the backup procedure.
Name: Mert Yazicioglu
Email: email@example.com firstname.lastname@example.org
Personal Website: http://www.mertyazicioglu.com (Redirects to mertyz.wordpress.com currently)
Skype ID: mertyazicioglu
IRC nick: merty
Phone number: 00905377922754
School Name: Bilkent University (Ankara, Turkey)
Years completed: 1 year
PHP Experience Level: Advanced
WordPress Experience Level: Current user and plugin developer.
Link to project description on WordPress-powered blog: http://mertyz.wordpress.com/2011/04/06/wordpress-move-proposal-draft/
Describe your idea in detail: I took the WordPress Move idea from the list of suggestions for GSoC’11. Even though that list is what made me think about the project in detail, the reason I decided to work on this project is my recent experience in moving our WordPress-powered online school newspaper’s website to a different web server.
To name a few issues I had during the transition:
- Slowness of my Internet connection in downloading backups from the old server
- Need of changing our old server’s details to make it work on my local web server
- Need of changing the connection details to make it work with the new web server
- Need of changing image paths as I added some contents while it was working on my local web server
- Slowness of my Internet connection in uploading backups to the new server
Even though those seem like small issues, on a large installation it may become a real pain to fix. Luckily, our installation was not that big and those tasks were a piece of cake for me. However, when I saw that suggestion in the ideas list, I have realized how it can become a massive problem for a newbie with no coding background. So I wrote down a feature list and started working on it.
My main aim here is to code a straightforward but also a feature-rich script that fits every kinds of installations just fine and makes the whole transition process a piece of cake for everyone. So the user will only install a plugin to his/her current installation and decide whether he/she wants to move onto a new server or only change the domain name.
If the user decides to change the domain name, plugin will first ask for the new domain name to replace with the older one. When the necessary information is provided, plugin will loop through the database records to change every instance of the old domain name with the newer one. This will affect system settings, widgets’ settings, plugins’ settings, attachment paths inside posts etc. Once everything is done, user will be forwarded to the login page of the ACP using the new domain name.
If the user decides to migrate from a server to another, plugin will first ask for the FTP connection credentials of the new server. Once a connection is established, plugin will upload a standalone script that will handle processes on the new server. After that, 3 different ways to migrate will be provided to the user to better fit his/her needs:
- Option to move the content only: If the former installation only had posts with no attachments or customizations, this is the easiest way to go. Plugin will pass the database backup to the new server via FTP and the standalone script on the new server will download the latest version of WordPress and import the database backup to the new installation. After importing completes, script will loop through the database records to replace old server’s credentials with the new one’s where necessary. When everything is done, user should be redirected to the dashboard of the new installation. This method requires the content to be text-only and also user should be fine with upgrading.
- Option to move the complete system directly as is: If the former installation is heavily customized or filled with attachments, this is the way to go. Plugin will backup the whole system as is and upload it to the new server via FTP. When uploading completes, plugin should redirect the user to the standalone script to continue with the replacement process where information related to the old server is replaced with the new server’s. After that, user should be redirected to the dashboard of the new installation. This method works fine with all kinds of installations as it moves the system as a whole, leaving nothing behind.
- Option to move the system partially: If the former installation is heavily customized and filled with attachments but you don’t want some of the plugins installed or none of the attachments anymore, this is the way to go. Plugin will provide an interface that you can choose what to move or not. Therefore if you are planning to turn your website into a plain-text format with no images, you will not need to move huge attachments with you to the new server. In the same way, you will be able to drop plugins you will not use on your new server. Once your selection process is completed, the plugin will prepare the backup file and upload it to the new server. Standalone script on the new server will take care of the rest by replacing old server’s information with the new server’s where necessary etc. This method is the best if you want to get rid of things you will not use anymore to speed up the transition.
In all of these 3 methods, once the backup files are created, they will be made available to the user to download as well. That way, if the old server fails uploading backup files to the new server, the user can do it manually and continue with the standalone script to complete the migration. So the standalone script will also have the method selection screen for these users.
I am also thinking of implementing the ability to merge multiple WordPress installations if I have time. User will be able to select which WordPress installation should be used as the base so the others’ contents will be transferred to that one. While I think implementing this would be superb, I may not have time to do so. I will certainly do my best to implement it but in case I fail, I will add this feature with an update after GSoC’11 completes.
The whole system will be as user-friendly as possible, so it will be able to identify the problems and give instructions to fix them. The user will be guided throughout the process with a detailed documentation.
WordPress Move will be also developer-friendly as it will provide hooks to let developers extend the migration assistant for their needs. Therefore rewriting the whole system will not be needed to just add another process.
It will be easy to translate to make such a powerful tool available to everyone around the globe.
The whole system will use AJAX to notify the user on what is going on at the moment. That way, user will not try to deal with redirections.
I will try my best to update this blog as much as possible during the development process. I will let my mentor, the WP community and the WP developers know how the project is going. Therefore I will work closely with my mentor.
Here are some UI mock-ups that are subject to change:
WPMove Migration Assistant
WPMove Migration Assistant
WPMove Migration Assistant
WPMove Manage Backups
WPMove Admin Menu Widget
Some Details About The Backup Procedure:
It will simulate backuping first to calculate the size of the backup. If it is bigger than the remaining free space, two options will be provided to the user:
a) Basic Option: It will fall back to one-file-at-a-time uploading method.
b) Advanced Option: It will show all the files and directories to the user with checkboxes next to them, so user can decide which files to backup. In addition to that, there will be “remove after uploading” option that starts uploading the biggest directory first using the one-file-at-a-time method, and checks if there’s enough space left or not to backup the rest of the system. This check will be done every time after uploading a directory finishes until enough free space is allocated.
If the user has enough space to backup and the backup size is really big, it will create backups of the system in chunks. Those chunks will be created intelligently so it will make backups of bigger directories in chunks first, until the rest of the system can fit inside a big chunk.
Finally, I am thinking of implementing a method to define how big those chunks should be so that uploading the file will not fail because of the time it will take. In order to achieve that, plugin will try uploading a test file to the new server and calculate the upload speed. Sizes of chunks will be defined using this speed value.
What have you done so far with this idea:
- I read the last year’s project, Automatic Migration by Brian McKenna. Thought how I can incorporate some of his ideas and ideas of the people who commented on his project.
- I also made a brief research on tools written for the same purpose to define their strengths and weaknesses. That way I will not make mistakes they made so WordPress Move will be at least one step ahead of them.
- Drew the flowchart diagram of the system. (Will share on my blog)
- Drew a few mock-ups on how it should look like.
Plugin, theme, or core: The software will consist of a plugin and a standalone script. Standalone script will be uploaded by the plugin to the new server if user selects the migration option. No changes to the core will be made.
Anticipated challenges: I cannot think of anything that would cause the failure of the project.
Potential mentors: No preference.
Schedule of Deliverables
Milestones and deliverables schedule:
April 26th – May 15th – Explaining the details of my project to the WordPress community and asking for their ideas.
May 16th – May 22nd – Deciding which suggestions of the community should be implemented and how with my mentor.
May 23rd – Coding begins!
May 30th – Tool to backup the database should be written by now.
June 7th – Tools to archive the files and upload the archives to the new server should be written by now.
June 14th – Tool to update database records, and tool to download & install the WordPress should be written by now.
June 21st - Coding the standalone script should be mostly done by now.
June 28th - Coding the administration page of the plugin in the ACP should be mostly done by now.
July 4th – AJAXifying the interfaces of both the plugin and the standalone script should be done by now.
July 8th - Internationalization should be done by now.
July 10th – Code maintanence should be done by now. The project reaches the feature frozen state.
July 11th – July 15th – Mid-term Evaluations
August 1st – Tests and fixes on numerous different installations and environments should be done by now.
August 21st – Writing the documentation and help guides (including instructions to solve problems) should be done by now.
August 22nd – The project is completed!
I will walk with my mentor along the project, so I will consider suggestions of my mentor in every step.
Other commitments: Timing of the GSoC’11 is perfect for me as I am totally free during the organization. (No school or work)
Open Source Development Experience
PHP Experience: I started learning PHP 6 years ago and I have been mainly using Object Oriented Programming for the last 3 years. I recently wrote a framework with MVC pattern using PHP and also wrote a CMS working on it. I am thinking of releasing the framework and the CMS as a free software to provide people a base to build their own scripts upon. CMS needs a lot of work but I think it would still provide a good base for starters. I also wrote a survey application running on my framework for the market research of a company. Of course, I wrote many PHP scripts in different complexities among the years but the most notable of them are those three.
Note: I heard about GSoC’11 a few days ago before the deadline, via the WordPress Development Blog widget on the dashboard of my WordPress installation. Therefore I could not find the time to research about the project,prepare a proposal and contribute to the WordPress itself. I still did my best to make a research about the project, write a good proposal, write a plugin and contribute a patch. Even though I have a well understanding of the WordPress core, my project does not require this skill really as it will consist of a plugin and a standalone script that will do the main job (which is not directly connected to the WordPress). So I can assure you the final project will be an example of state-of-art programming.
Other Open Source/Free Software Experience:
- I contributed SkateBoard project with a few bug reports and fixes but the project discontinued.
- I participated Google’s Highly Open Participation Contest and helped Joomla!
- I voluntarily contributed translations of Ubuntu, Simple Machines Forum, Joomla!, SchoolTool and SkateBoard.
- I released some of my scripts under the GNU/GPLv2 license on various platforms but lost track of most of them due to changes made on those platforms.
- In a few months, I will release my framework and CMS projects as Open Source projects to provide a good base for OOP newbies.
- I also have an ongoing research project about the extent of freedom the Free Software Movement brings.
- Director of Online Operations – GazeteBilkent (Online Newspaper of our University) (WordPress-powered)
The website used to work on my framework and CMS written in PHP but I decided to switch to WordPress recently.
- Software Developer – Chipping-Potatoes Market Research Website
Developed a poll system that generates detailed statistical reports using JS (AJAX), PHP and MySQL.
- Lead Website Designer – Europe@School Website Design Contest 2006 (Won the 2nd prize!) (HTML, CSS, JS)
- Ubuntu – Volunteer Translator
- Simple Machines Forum – Volunteer Translator
- Joomla! – Volunteer Translator
- SchoolTool – Volunteer Translator
- SkateBoard – Volunteer Translator (Also contributed with a few bug reports but the project discontinued)
Apart from those, I have coded many scripts with different complexities. They range from an online dictionary script to a full-fledged business cataloging system. I did not mention them because those projects either discontinued or disappeared without my knowledge. I do not exactly know who uses which of my scripts right now as I have provided most of them for free on various platforms.
Academic Institution: Bilkent University (Ankara, Turkey)
Current Program: Computer Technology and Information Systems for a BS degree. I am about to complete my freshman year.
Anticipated Graduation: 2014
Academic Performance: I am an Honors Student with a GPA of 3.44/4.00.
Courses I took / am taking are:
- CTIS151 Introduction to Programming (Grade: A)
- CTIS152 Algorithms and Data Structures (Ongoing)
- CTIS163 Discrete Mathematics (Grade: B)
- CTIS164 Technical Mathematics with Programming (Ongoing)
- CTIS165 Fundamentals of Information Systems (Grade: B+)
- CTIS166 Information Technologies (Ongoing) (This is actually a Linux course)
Even though courses I took so far may not seem too related, I should note that I learned programming on my own when I was 8 years old and I have been coding in PHP for 6 years. Apart from PHP, I know C, C++, Java, Perl and Python programming languages. So I do have good programming skills and a good understanding of code efficiency.
GSoC for Credit: No.
You’re applying to work with WordPress during GSoC because: I chose WordPress because it is one of the few PHP projects I adore and love to work with. I have been amazed with its extensibility since the day I first used it. I am really happy to have a project that would be a major contribution to the WordPress community in my opinion.
After GSoC, you envision your involvement with WordPress will be: Ongoing, definitely. I would love to become a core developer of such a successful script, so I will do my best to support the community both with core contributions and plugins.