GSOC 2017 Project Ideas
From Joomla! Documentation
Welcome to GSoC 2017 Ideas Page[edit]
Welcome to the Joomla! Google Summer of Code (GSoC) 2017 project ideas page. As we move forward with the 2017 version of the Joomla! GSoC, we will update this site with the ideas that have been submitted below.
Please keep in mind that projects need to be realistic and something that is able to be functionally completed by a student working full time for about ten weeks.
If you are interested in participating as a student please review the materials on applying that are available at Google. We strongly encourage you to ask questions about process and ideas on our joomla-gsoc mailing list.
Guidelines on Submitting Ideas[edit]
Everyone is invited to submit their ideas! You do not have to be a Google Summer of Code student or mentor to suggest one.
If you have ideas for the Joomla Google Summer of Code Program please send them to us at this form:
There are some important guidelines to submit ideas, please read these carefully before adding your ideas:
- Ensure your idea is able to be completed in a fixed period of time. GSoC runs officially between May, 2017 and August 2017. This is a short period of actual coding time. Ideas should respect the time that students have available for the program.
- Keep ideas realistic. The ideas on this list should maintain a realistic amount of work for a single student, junior level-developer, who is working with a compressed timeline and a fixed completion ('pencils down') date.
- The purpose of GSoC is to improve Joomla. This is not the time to add ideas for new extensions or features that may not be included. If the idea is related to the framework, please consult the framework team directly about new ideas to ensure there is interest in having the package included as an official Joomla Framework package.
- When in doubt, reach out. If you're unsure if your idea belongs on this list, please post to the GSoC 2017 mailing list and ask about the community's interest.
- No documentation-focused projects. Google Summer of Code is a program about code. We expect our students to document their work, but writing documentation for Joomla as a project does not align with the goals of GSoC.
Idea Pool[edit]
Project I: Webservices in Joomla![edit]
Project Description: |
---|
Integrating a rest api endpoint (like api/) into the Joomla Core. More information is going to follow in the next days. |
Expected Results: |
---|
Working REST Api for core. Including com_content as reference. |
Knowledge Prerequisite: |
---|
PHP, RESTful Webservices. Nice to have: Joomla MVC, Swagger, Knowledge of APIs |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Matias Aguirre,Anibal Sanchez,George Wilson |
Project II: Improved Routing[edit]
Project Description: |
---|
Even with the new Router there is much room for improvement in the routing area. This project aims to improve the SEO capabilities of Joomla. This will be achieved by looking at a component by component option of disabling having duplicate URLs by only having one way to access an item from within a component. This will also require changes to modules to allow them to be assigned to orhan homepages. |
Expected Results: |
---|
Improved Routing handling in components by only having a single url for each page (enabled on a per component basis for b/c) |
Knowledge Prerequisite: |
---|
PHP Nice to have: Joomla MVC, SEO experience |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Christopher Wagner,Rishi Vishwakarma,Gunjan Patel |
Project III: Cloud filesystems for media manager[edit]
Project Description: |
---|
The new media manager for Joomla! 4 contains a rest like API to fetch the folder structure and file information. This is limited to the local filesystem. For Joomla! 4 it would be nice to break that API up and to allow extension developers to add cloud based filesystems through plugins. |
Expected Results: |
---|
Media manager API rewrite to support the Joomla! plugins for cloud based filesystems. |
Knowledge Prerequisite: |
---|
PHP, File system. Nice to have: Joomla! MVC, Rest, API/Framework integration |
Difficulty: |
---|
Medium |
Mentors: |
---|
Allon Moritz,David Neukirchen |
Project IV: Improvements and extended coverage for the parallel testing environment[edit]
Project Description: |
---|
Recently the new container-based automated testing environment was developed (final development stages ongoing when writing this proposal), supporting multiple Joomla and PHP versions and increasing speed for the current codeception-based testing system: https://github.com/joomla-projects/joomla-testing. There are areas of opportunity that the current testing system is not covering right now, including covering the tests of the CMS itself, so I would like to propose improving 4 specific areas, explained in the expected results. |
Expected Results: |
1. Right now it can test Joomla extensions, but it should also have support for testing the CMS itself, by assuming that it needs to start with the testing of the CMS installer (prerequisite), next the tests of the CMS itself and finally the uninstall process. 2. The virtualisation package https://github.com/joomla-projects/virtualisation is unfinished and has little coverage. Right now it can handle basic Apache, PHP and MySQL installations. The goal is to support virtualisation environments including Postgres, Nginx and multiple Joomla versions including staging for extension testing. It also needs to be integrated to the new automated testing environment since it's not using it now. |
Knowledge Prerequisite: |
---|
PHP and object-oriented programming. Knowledge of system deployment including basic server setup like Apache, PHP, MySQL, Postgres, Nginx. Container-based virtualisation concepts. Nice to have: Codeception |
Difficulty: |
---|
Hard |
Mentors: |
---|
Niels Braczek,Tito Alvarez |
Project V: Testing Dashboard - A birds eye view on the state of testing[edit]
Project Description: |
---|
The Testing Dashboard should give people a compensative overview how the state of testing for our code base is. It collects data from the different testing areas and shows the actual result and some kind of historical data. |
Expected Results: |
---|
|
Knowledge Prerequisite: |
---|
PHP, MySQL, JavaScript. Nice to have: Joomla MVC, PHPUnit, Basic Statistics knowledge, REST |
Difficulty: |
---|
Medium |
Mentors: |
---|
Niels Braczek,Robert Deutz |
Project VI: Publishing Workflow in Joomla![edit]
Project Description: |
---|
The Joomla! Core offers at the moment a very static publishing workflow (namely: published, unpublished, archived and trashed). The idea of this project is to implement an unlimited workflow solution, so everyone can map his/her/its workflow for all supporting components.
The basic idea is, that we have 3 conditions: - the item is visible (published) - the item is not visible (unpublished) - the item is deleted (trashed) ("Archived" is not needed anymore because it could be achived with an individual state) This conditions are not "direct publishing states" like at the moment (where you can set a item e.g. to publish), but more "features" of the future states. So how should the new system work?[edit]- The user goes to the workflow component and clicks "new" - He/she/it insert a workflow title (let's say "my workflow") - Optional the user can set up different options like: description, publishing state, access level, ACL permissions etc. - After saving he comes to the workflow view, where he/she/it can define the new workflow - Here he has two options: create a new "workflow state" or create a "transition" (ofc. he can delete/edit existing ones, too.) Workflow state:[edit]Workflow states are something like the current publishing states (published, unpublished, archived, trashed). That means, items will be set to this state and will be shown (or not) regarding to the property of the state. Every state has one condition (from above), so a state could have the condition "published" (means, an item with this state will be visible in the frontend), "unpublished" (means, an item with this state will not be visible in the frontend) or "trashed" (means, an item with this state will neither be shown in front- nor backend (until a user filters for it)) So a "workflow state" is a very simple element which (in a basic version) needs only a title and a dropdown for the "condition" (ofc. there could also be parameters like a description). Transition[edit]A transition defines the change from one "workflow state" to another one. So it holds the starting "workflow state" and the target "workflow state". Additional it has the requirements defined "who can execute the transition". That means, each transition has its ACL integration and a user can define who can execute this transition.
Worflow states: 1. Needs review (condition: unpublished) 2. Needs rework (condition: unpublished) 3. Ready for publishing (condition: unpublished) 4. Online (condition: unpublished) 5. Not needed anymore (condition: trashed) Transitions: a. From 1. => 2. b. From 2. => 1. c. From 1. => 3. d. From 3. => 4 e. From 1. => 5. f. From 2. => 5. g. From 3. => 5. h. From 4. => 5. i. From 5. => 1. All transitions have ofc. individual ACL permissions where the user can define which user groups can execute the transition and change the "workflow state" So as summary you could say: the main idea is to use the current publishing states as "conditions" and allow unlimited repeatable usage of this states. |
Expected Results: |
---|
Additional goals (if time left):[edit]
|
Knowledge Prerequisite: |
---|
PHP, JavaScript. Nice to have: Joomla MVC |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Benjamin Trenkle,Shubham Rajput, Sven Hurt, Parth Lawate, Buddhima Wijeweera |
Project VII: Issue Tracker Release Section[edit]
Important Note: |
---|
Note: This project will be merged with Project VIII Refactor the Issue Tracker Application |
Project Description: |
Create a new section for the Joomla! Issue Tracker that holds a summary of a project's activity during the release cycle. See https://github.com/joomla/jissues/issues/506 for additional discussion. |
Expected Results: |
---|
A new section is added to the issue tracker. |
Knowledge Prerequisite: |
---|
PHP, MVC, dependency injection. Nice to have: Joomla! Framework |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Niels Braczek,Michael Babker |
Project VIII: Refactor the Issue Tracker Application[edit]
Important Note: |
---|
Note: This project will be merged with Project VII Issue Tracker Release Section |
Project Description: |
Work is started on refactoring the issue tracker application to use more modern development practices, to include proper dependency injection into various elements (reduced use of passing the DI container as a parameter into classes) and restructured classes have automated test coverage. At least three of the application's "apps" (loosely compared to a Joomla! CMS component) as well as the base application framework should be updated prior to the completion of the GSoC period. |
Expected Results: |
---|
A new section is added to the issue tracker. |
Knowledge Prerequisite: |
---|
PHP, MVC, dependency injection, Unit Testing. Nice to have: Joomla! Framework |
Difficulty: |
---|
Hard |
Mentors: |
---|
Niels Braczek,Michael Babker |
Project IX: Expand the Extension Manager[edit]
Project Description: |
---|
The extension manager can do with a few more features and a redesigned UI. The project would add the following features to the extension manager:
|
Expected Results: |
---|
These new features implemented in the extension manager part of Joomla. |
Knowledge Prerequisite: |
---|
PHP, MVC, Javascript. Nice to have: Medium |
Difficulty: |
---|
Medium |
Mentors: |
---|
Llewellyn van der Merwe,Peter Martin, Roland Dalmulder |
Project X: JavaScript Tests for Joomla 4[edit]
Project Description: |
---|
Increase and improve the JavaScript testing suite based on Jasmine and Karma for Joomla 4. |
Expected Results: |
---|
Almost complete coverage of the Joomla 4 JavaScript code including the new media manager. |
Knowledge Prerequisite: |
---|
JavaScript, Karma, Jasmine, jQuery. Nice to have: Travis and Drone (CI) experience, Vue, NPM, Node |
Difficulty: |
---|
Medium |
Mentors: |
---|
Thanuditha Ruchiranga,Ashan Fernando |
Project XI: Refactoring the Help Screens localised on JDocs and served in the Joomla! backend through the Help server to make them more manageable by volunteers[edit]
Project Description: |
---|
The Joomla! backend includes an integrated context-sensitive help system that accesses pages in HTML or XML served from a directory within the Joomla! installation, or more commonly, from an external help server. The documentation wiki contains the "master" help screens for all Joomla! versions. The Help Screens are numerous (for the currently supported version: https://docs.joomla.org/Help36:Help_screens) and it became unmanageable, mainly because of the high number of new Joomla! Versions and the low number of volunteers to maintain them. Keeping them up to date (content as well as numerous screenshots of the backend) is important for our users but it has became an impossible goal, even more because they also need to be localised. |
Expected Results: |
---|
A re-thought of the Help Screens to provide a more manageable and easier system that can require less time to keep the documentation up to date (on JDocs and so in the Joomla! backend). For the display in the backend, a possibility could be to have a kind of guided system. Then making the help button Open up just a how to page that's based on whatever component you're using. The guidance system could run off of JavaScript and of course you can shut it off within a click. (ex: https://www.google.com/amp/s/webresourcesdepot.com/11-awesome-jquery-site-tour-plugins-for-guiding-users-with-style/amp/?client=safari) The original source of the Help Screens will need to stay on JDocs. |
Knowledge Prerequisite: |
---|
PHP, JavaScript, JSON. Nice to have: MediaWiki |
Difficulty: |
---|
Medium |
Mentors: |
---|
Sandra Thevenet, Tom Hutchison |
Project XII: Gherkin Editor[edit]
Project Description: |
---|
To ease the creation of new acceptance tests, an editor would be useful, that provides existing and suitable test routines in a select field (similar to the search field in a browser, or the address field in a mail client). That helps to find a wording, that utilises re-use of existing test code instead of forcing rewrites. |
Expected Results: |
---|
A package that can be integrated into JTracker. |
Knowledge Prerequisite: |
---|
Joomla Deployment Setup, PHP, understanding of Gherkin based acceptance tests |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Niels Braczek,Astrid Guenther |
Project XIII: Joomla PR Testing Platform[edit]
Project Description: |
---|
Today when a developer send a Pull Requests(PR) to Joomla Github Repository, a reviewer or a tester need to manually setup a environment with the PR code to test it. This project is to focus in building a basic platform using multi-container docker and integrating with Github, which allows to automatically get the code of the PR and build a running Joomla application and provide the link inside the PR itself (Similar to how Travis Build Happens). Since we are dealing with limited this solution should self manage efficiently utilizing available resources.
Use case 1) User makes a PR 2) Similar to Travis, a Build process occurs and a link will be available in the PR 3) This is used by a tester to test the functionality (Making regression testing and verification process faster) 4) This solution should self manage efficiently utilizing available resources 5) Based on Docker |
Expected Results: |
---|
For each pull request, show a test link in build status to test the Pull Request |
Knowledge Prerequisite: |
---|
Joomla Deployment Setup, DevOps, Github API, Docker, Docker-Compose |
Difficulty: |
---|
Medium to Hard |
Mentors: |
---|
Ashan Fernando |