GSOC 2017 Project Ideas

Welcome to GSoC 2017 Ideas Page

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.

Find examples of the last year at https://docs.joomla.org/GSOC_2016_Project_Ideas

Guidelines on Submitting Ideas

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:

* GSoC 2017 Idea submission 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

Project I: Webservices in Joomla!

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:
To be defined

---

Project II: Improved Routing

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:
To be defined

---

Project III: Cloud filesystems for media manager (Flysystem)

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, Flysystem. Nice to have: Joomla! MVC, Rest, API/Framework integration

Difficulty:
Medium

Mentors:
To be defined

---

Project IV: Improvements and extended coverage for the parallel testing environment

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. 3. A better and codeception-based built-in testing selection system needs to be created, so that test order is selected not based in a configuration xml file but using the dependencies made in the codeception tests itself. This also means applying this new structure to the Weblinks extension repo and the CMS tests. 4. An automated nightly builder of the staging version of Joomla so it can be used by the virtualisation package to test extensions against a pre-installed staging version.

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:
To be defined

---

Project V: Testing Dashboard - A birds eye view on the state of testing

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:
Documentation what are the different testing areas Documentation how we get details about testing areas Developing scripts to get the information and save the data Developing a website to show the results (could be a Joomla! Extension)

Knowledge Prerequisite:
PHP, MySQL, JavaScript. Nice to have: Joomla MVC, PHPUnit, Basic Statistics knowledge, REST

Difficulty:
Medium

Mentors:
To be defined

---

Project VI: Publishing Workflow in Joomla!

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? - 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: 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 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. - The user creates now different "workflow states" and "transitions" to implement his/her/its workflow. For example: 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:

At the end of the project, there should be a new component in Joomla! in which a user can define unlimited own publishing workflows. As basic (none deleteable, none changeable) workflow, the current publishing workflow is implemented, to make sure, we have B/C. The workflows should respect the Joomla! ACL (Who can see, who can do actions (activtate)). The workflows should be assignable to all Joomla! core components, which could have a publishing workflow (Banners, Contacts, Contents, Menus, Categories and the worklfow component itself) via the configuration of the component. If the assigned workflow is changed, there should be a check, if there are no conflicts (like, before we have a publishing state "ready for review" and now not) and if so, offers a "resolve view". The publishing workflow should be respected by the components in the frontend. - The backend filters will show the states in the filter dropdown. Additional goals (if time left): The student could implement a drag&drop functionality to set up new workflows in a very smooth way. The student could implement different filter parameters to modules/menu link types where a Joomla! user can choose, which publishing states he want to show or for e.g. article commit, what is the starting state of new submissions. Multilingual

Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC

Difficulty:
Medium to Hard

Mentors:
To be defined

---

Project VII: Issue Tracker Release Section

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:
To be defined

---

Project VIII: Refactor the Issue Tracker Application

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:
To be defined

---

Project IX: Expand the Extension Manager

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: Option to remove the database tables upon un-installation of a component or package if user wants to Show the changelog for an update Add a field to enter a license key for a given extension. Database fix to also check the SQL update files of installed components. The fix now only checks the core database. Option to edit an update site Signed installation archives. This is to make sure only original archives are installed.

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:
To be defined

---

Project X: JavaScript Tests for Joomla 4

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:
To be defined

---

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

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:
To be defined

---

Project XII: Gherkin Editor

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:
To be defined

---

Project XIII: Joomla PR Testing Platform

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:
To be defined

---

Project XIV: Hotkeys for power users

Project Description:

Powerusers often times are willing to deeply get into a piece of software to get faster at doing their jobs. For this, hotkeys can be a nice way to not be able to scroll and click a button. Fortunately modern browsers have a feature for this called accesskeys, which is heavily used by MediaWiki for example. these accesskeys could be used in Joomla as well, to make work easier for people willing to go the extra mile in learning Joomla.

Expected Results:

Buttons like "Close", "Save", "Save as Copy", "Save & Close", "Save & New", " etc would get unified hotkeys over the core admin pages. The classes to build html get the ability to specify accesskeys (if they don't have it yet, i'm not 100% sure) so extension developers can easily use them. Important menu items like "Add New Article" could also get accesskeys. If this shall be super fancy, a way to customize these accesskeys would be nice.

Knowledge Prerequisite:
An understanding of how Joomla builds the page is necessary, the html skills to use accesskeys should be neglectable and can be picked up in minutes.

Difficulty:
Medium

Mentors:
To be defined

---

Project XV: Picture element & inclusion of WebP in media manager

Project Description:

The <picture> element should be supported in Joomla! both in the intro/full image section and also within the editors. The benefit is that mobile will not have to load the desktop image, it can load a far smaller image and not have to resize. It can also change the crop etc. https://developer.mozilla.org/en/docs/Web/HTML/Element/picture In order to get this working for intro/full image we will need to have a repeatable field. There can be x images within a picture element. The picture element also includes a source element, a media element, a size element, and a type element (png/jpg/webp/etc). All are related to one image, thus there needs to be a repeatable group of fields. The media element defines when the image is used (like a media query). https://www.html5rocks.com/en/tutorials/responsive/picture-element/ In order to get this working for an editor image we need some way of selecting multiple images for use within one <picture> element. I don't know if this is a ten week project, so as an additional request the WebP format is a lot smaller than JPG etc so would be a useful additional to the media manager. I don't know if there are any technical considerations other than adding the WebP file extension. WebP is Open Source and created by Google - https://developers.google.com/speed/webp/. If this is asking too much then just complete the first part.

Expected Results:
Faster speeds for mobile Joomla! websites. Better control over mobile images via crops etc (designers will be happy). The potential for smaller images via WebP adding another layer of performance. All of this equals better ranking Joomla! websites.

Knowledge Prerequisite:
Joomla CMS, knowledge of adding repeatable fields to back end, minor front end coding skills to add the <picture>, PHP knowledge to call the new images.

Difficulty:
Medium

Mentors:
To be defined

---