Google Summer of Code Proposals
Proposal 1: Working Copy of Joomla! Live Site
IDEA & BENEFITS:
Administrators usually work on their live site directly and sometimes they do mistakes as all people do. As a result, the live site gets messed after extension installation/uninstallation process and re-configuration. The idea is to have a working copy of the live site and make changes on it, then, if everything is okay after some testing, you can approve changes and the tool will apply them to your live site.
I would like also to implement some basic features of Subversion into this project e.g. commit/approve, update/synchronize, revert, merge, create patch, apply patch (SVN operations afterwards).
Using this tool, people will do less mistakes on the live site and get less nervous!
I am Edvard Ananyan aka edo888, a citizen of Armenia. I am 20 years old, and I have been granted a full scholarship to be an undergraduate student at Yerevan State University majoring in Applied Mathematics and Physics (Department of Physics).
Being highly interested in computer science, I have also accomplished a number of open source projects. Some of them are listed below:
- GTranslate: an automatic translation module based on Google Translate
- Jumi: Joomla! custom content extension package (in partnership with Martin Hajek)
- Jumi Tips & Tricks
- JosLang: Multilingual system plugin (in partnership with David Thomas)
- Xinha WYSIWYG editor plug-in
As you may know I'm also a Joomla! Bug Squad member.
You can read more about myself on my website: http://edo.webmaster.am/about
Here is also an online reference: http://tinyurl.com/edo888 -> http://jumi.vedeme.cz/index.php?option=com_contact&view=contact&id=2:ed&catid=12:contacts&Itemid=49
MILESTONES & DEVELOPMENT PROCESS TIMELINE:
Creating an API and interface will be needed to complete this project. They both will be developed simultaneously to make able testing from the interface. I will keep the main coding ideas and standards of Joomla! Framework hoping it will be a part of Joomla! 1.6 in future.
During the development process I will assume that the live site (master or parent afterwards) and the working copy (child afterwards) are running on the same versions and configurations of OS/Apache/MySQL/PHP, and the server configuration will stay intact (this tool can be only a testing environment for SERVER RE-CONFIGURATION).
Now I will describe in general what it will be and how easy it will be to work with. Here are some steps administrators can do:
- Create as many childs from the master to work on them (admin can create even a grand child)
- Modify the child (re-configure, add/edit content, install/uninstall/update extensions) and test (we can have a "spy bot" if necessary on the child to determine made changes easily)
- Approve changes to the live site with one of this options:
- Create a patch from the child
- Apply the patch to the master
- Directly approve changes to the master (actually it can do 3.1 then 3.2, just in one step)
- View the changes made on the child
- Synchronize the child with the parent (when the child is out of date)
- Revert the child to the parent state
- Merge 2 sites (master-child or child-child) with referential integrity
There are 2 possibilities to make changes on the Joomla! website, which is to change database and/or file system. So there will be 2 types of functions in the API, which will make changes to the database and to the file system.
Working with the file system is the easiest part, because every file has last modified date, which makes easy to determine which file is newer.
Working with the database is much more complicated, because there can be different scenarios with relations.
My goal is to make an API, which will implement SVN operations not only to core tables, but also to 3rd party tables, which can come with 3rd party extensions.
The only table, which will be intact is #__session (no need to do SVN operations on this table, because users will be only on master).
To work with the database like with the file system, we can alter all the tables in the child and add last_modified_date column and add triggers for update action, which will update last_modified_date e.g.
mysql> ALTER TABLE `table_name` ADD last_modified_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;
To not destruct relations between tables, we can increase the auto_increment column values in child tables (in general relations are made with auto_increment fields). So with that we will be sure that if the admin will work directly on the master (to make faster changes), there will be empty space between table rows, which are inserted with master and those, which are inserted with child site.
mysql> ALTER TABLE `table_name` AUTO_INCREMENT = 500; /* big value depending on the table row count */
+------+----------+---------------------+ | id | title | last_modified_date | +------+----------+---------------------+ | 1 | Title 1 | 2009-03-21 14:05:40 | | 2 | Title 2 | 0000-00-00 00:00:00 | +++++++++++++++++++++++++++++++++++++++++ -> enough space between 2 and 500, MyISAM Engine will fill new rows here | 500 | Title 3 | 0000-00-00 00:00:00 | -> added by child, we already increased auto_increment value for child table +------+----------+---------------------+
In this case merging will become easier.
Future enhancements: It is also possible to have a history table (#__tablename_history) for each table in db, which will keep table row versions in it. It will enable versioning of the whole database. Not only the content, but also parameters, module positions, etc. would be versioned. The other thing, which can be done, is to have language tables and keep table row translations in them.
I'm going to work 8 hours a day, 5 days a week; it's a full time job.
April 20 - May 17: TIME TO SPEAK WITH THE MENTOR
Week 1 May 18 - 22: Interface and API functions to make a child from master. (1)
Week 2 May 25 - 29: Interface and API functions to view changes made on child. (4)
Week 3 June 1 - 5: Interface and API functions to revert che child. (6)
Week 4 June 8 - 12: Interface and API functions to synchronize the child. (5)
Week 5 June 15 - 19: Interface and API functions to create a patch. (3.1)
Week 6 June 22 - 26: Interface and API functions to apply the patch. (3.2, 3.3)
Week 7 June 29 - July 3: PREPARE FOR THE MID-TERM EVALUATION
Week 8 July 6 - 10: SUBMITTING THE MID-TERM EVALUATION
Week 9 July 13 - 17: Interface and API functions to merge 2 sites. (7)
Week 10 July 20 - 24: RESERVED TIME
Week 11 July 27 - 31: RESERVED TIME
Week 12 August 3 - 7: PREPARING FOR THE FINAL EVALUATION, PUTTING EVERYTHING IN THEIR PLACES
Week 13 August 10 - 14: PENCILS DOWN, SUMMARISING RESULTS, WRITING DOCUMENTATION
Week 14 August 17 - 21: SUBMITTING THE FINAL EVALUATION
August 22 - 25: TIME FOR LAST MINUTE DECISIONS
- Bringing new functionality to Joomla!
- Making a big step towards a professional career
- Being involved in serious project development for getting more experienced
- Meeting interesting people, learning from them and SIMPLY HAVING FUN!
- Increasing chances to get full scholarship for masters degree in the US
- Earning some money for my further education
- Making a dreams come true
I'm looking forward to continue contributing to Joomla! in the future and organizing Joomla! Armenian community.