Google Summer of Propuestas Código

Esta es una especie de Subversion para Joomla! sitio en vivo.
http://docs.joomla.org/Summer_of_Code_2009_Project_Ideas # Working_copy_of_Joomla.21_live_site

IDEA Y BENEFICIOS:

Normalmente, los administradores trabajar en su sitio en forma directa y en ocasiones lo hacen errores como todos los de la gente. Como resultado, el sitio en vivo se cometa un error después de la extensión de instalación / desinstalación de procesos y re-configuración. La idea es tener una copia de trabajo del sitio de vivir y hacer cambios en ella, entonces, si todo está bien después de algunas pruebas, puede aprobar los cambios y la herramienta que se aplican a su sitio web.

Me gustaría también poner en práctica algunas características básicas de Subversion en este proyecto, por ejemplo confirmar / aprobar, actualizar / sincronizar, volver, unir, crear el parche, aplique el parche (SVN operaciones después).

Con esta herramienta, la gente va a hacer menos errores en el sitio de vivir y menos nervioso!

ACERCA DE MI:

Estoy Edvard Ananyan aka edo888, un ciudadano de Armenia. Tengo 20 años de edad, y se me ha concedido una beca completa para ser estudiante de pregrado en la Universidad Estatal de Yerevan con especialización en Matemáticas Aplicadas y Física (Departamento de Física).

Siendo muy interesado en la informática, también he realizado una serie de proyectos de código abierto. Algunos de ellos se enumeran a continuación:

• GTranslate: un módulo de traducción automática basada en Google Translate
• Jumi: Joomla! contenido personalizado paquete de extensión (en colaboración con Martin Hajek)
• Jumi Consejos y Trucos
• JosLang: plugin sistema multilingüe (en colaboración con David Thomas)
• Xinha editor WYSIWYG plug-in

Como ustedes saben yo también soy un Joomla! Bug Squad miembros.

Usted puede leer más acerca de mí mismo en mi sitio web: http://edo.webmaster.am/about

Aquí también es una referencia en línea: 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:

La creación de una API y la interfaz será necesario para completar este proyecto. Ambos se desarrollarán de forma simultánea para realizar pruebas de poder de la interfaz. Voy a seguir las ideas principales de codificación y las normas de Joomla! Marco de la esperanza de que será una parte de Joomla! 1,6 en el futuro.

Durante el proceso de desarrollo voy a suponer que el sitio en vivo (maestro o padre después) y la copia de trabajo (después del niño) se están ejecutando en las mismas versiones y configuraciones de OS / Apache / MySQL / PHP, y la configuración del servidor se quedará intacto ( esta herramienta puede ser un entorno de prueba para servidor vuelve a la configuración).

Ahora voy a describir, en general, lo que será y lo fácil que será para trabajar. Aquí hay algunos pasos que los administradores pueden hacer:

1. Crear tantos del niño desde el maestro al trabajar en ellos (administrador puede crear incluso un nieto)
2. 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)
3. Aprobar los cambios en el sitio en vivo con una de estas opciones:
   1. Crear un parche del niño
   2. Aplique el parche en el maestro
   3. Aprobar los cambios directamente con el maestro (en realidad se puede hacer entonces 3,1 3,2, en un solo paso)
4. Ver los cambios hechos en el niño
5. Sincronizar el niño con el padre (cuando el niño está fuera de fecha)
6. Volver al niño a la madre patria
7. Combinar dos sitios (maestro-niño o niño-niño) con la integridad referencial

Hay dos posibilidades de realizar cambios en el Joomla! sitio web, que consiste en cambiar la base de datos y / o sistema de archivos. Por lo que habrá dos tipos de funciones de la API, lo que hará cambios en la base de datos y el sistema de archivos.

Trabajar con el sistema de archivos es la parte más fácil, ya que cada archivo tiene fecha de última modificación, lo que hace fácil determinar qué archivo es más reciente.

Trabajar con la base de datos es mucho más complicado, porque no puede haber diferentes escenarios de las relaciones.

Mi objetivo es hacer un API, que llevará a cabo actividades SVN no sólo a las tablas de base, sino también a las tablas 3 ª parte, lo que puede venir con extensiones de 3 ª parte.

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 */

For example:

+------+----------+---------------------+
| 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

MOTIVATION:

• 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.