A tool for partiell transferring database/webspace between two identical Joomla projects on the same server. -- 2

General requirements - The component to be created is only used in the backend of Joomla. - The projects between which data should be transferred are located on the same server, but use different databases and different webspace directories for the Joomla installations. No FTP is needed. - The component can be installed via the Joomla installer and should be provided as an install package. - Preferably the component should be installed in the main project and not in the sibling project. - If category management is necessary at all, it is very easy to keep it without sub-categories. - There is a component configuration where e.g. the database connection data and the project root directory of the sibling projects are configured. Example application: A realistic test scenario involves transferring data between two projects and bringing the project data up to the same maintenance level. In a main project, the site operator maintains shop products. There is another sibling project, under another domain, but on the same server (own database, own Joomla directory). This project has its own data tables and a few things are different than in the main project. However, the site operator only wants to maintain the shop data once in the main project. Therefore not all data should be transferred from the main project to the sibling project but only selectable data. The component should not only be suitable for this example scenario, but should also be flexible enough to be used for other tasks or in other projects. Description of the component: For this purpose, the page administrator creates jobs in this component which the page owner can then easily execute and process. Categories and tags can be used to organize individual jobs into overall tasks. The jobs can be sorted on the job list view and filtered by category or tags. The Joomla Framework standard view methods are to be used for this purpose. Sorting must always be maintained despite the active filter. So the side operator can accomplish large tasks by processing individual jobs. He can, for example, use a category or tag as a filter and then only see the jobs of this category/matching tag in the list view and can execute these individually and step-by-step and thus perform the task, for example, the transfer. Job Types: There are three types of jobs that the site administrator can create. These jobs are maintained using a common detail view dialog (edit). A job type must be selected in the edit dialog. The job type determines in which way the command entered in a text area input field is processed during its execution action. For each job type it must be possible to specify whether it is to be applied to the main project (same project) or the sibling project. The three job types are: a) a command line command (bash shell command like linux). This job type is used to copy product images from the main project directory to the sibling project's image directory - exactly as you would do it on the command line. b) an SQL query statement. This Jop type is used, for example, to make modifications to the tables of the target or source database. For example, to set certain product categories or product manufacturers on the sibling project to "unpublished" that are set to "published" on the main project. c) Table copy list. A list of tables is entered in the text area input field. One table name per line. When this job type is executed, all source tables named there are copied to the target database (simple overwriting, without comparison). There could be 4 views 1. main view is the list. This serves 2. job edit view for configuring the jobs. 3. configuration accessible via the Options button. 4. optionally simple category management More details? Not her because character count limitation. It is up to the programmer to decide whether a detail edit view is necessary at all, or whether the jobs can be edited already and only in the list view, e.g. via Ajax functions.