GSOC 2017 Project Ideas

From Joomla! Documentation

Revision as of 14:27, 13 February 2017 by Wilsonge (talk | contribs) (→Project II: Improved Routing)

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: Hotkeys for powerusers

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:
PHP, JavaScript, HTML, CSS. Nice to have: Joomla MVC
Difficulty:
Hard
Mentors:
To be defined

Project IV: Cloud filesystems for media manager (Flysystem)

Project Description:
The new media manager for Joomla! 3.8 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 V: 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 VI: Improve Language Manager - Extensions\Language(s)

Project Description:
Many language files contain text that is NOT translated. The language constants are commented waiting to be translated. To understand the problem, you should look some of the language files from Transifex/OpenTranslators. You will find many commented language strings in the files. https://www.transifex.com/opentranslators/public/

The idea is to add a new section after Overrides where everyone who has permissions will be able to edit the text in the language files. It could be named "Language File Editor" or "Translation Manager". The users should be able to download and send the language files to their maintainers (extension developers). You should provide information about the maintainer of the language files (name, email, website,..). You can also provide a form (popup) that can be used for easier sending of the language file to its maintainer. The system will notify the administrator if there are language constants that are NOT translated. You can show the information about NOT translated text on the dashboard via module or Quick Icons plugin.

Expected Results:
This tool (language files editor) will engage much more people to translate Joomla language files in their language. Furthermore, it will engage much more people to translate third-party extensions. That will improve the multilingual support of Joomla! CMS and many other popular extensions. This feature must be accompanied by documentation in the form of wiki pages, full help screens and video tutorials in 3 min each. The code must be accompanied by appropriate unit tests.
Knowledge Prerequisite:
PHP Nice to have: Joomla MVC
Difficulty:
Medium
Mentors:
To be defined

Project VII: Improve Troubleshooting

Project Description:
One of the weaknesses of Joomla is the ability to provide detailed information about problems occurred in the system. You can look the reviews about the problem with troubleshooting here. https://www.yokoco.com/2016/04/18/wordpress-vs-joomla-vs-drupal-a-content-management-system-cms-review-for-marketers/

Improve the log functionality. Implement functionality to store detailed information and any kind of error message, even debug mode and error reporting have been disabled. It could be Log Manager or Manager for Troubleshooting. Classify every record (error message) as warning, error, alert, etc. The records should provide a link to a page with detailed information where user will be able to find a solution. Many servers store information about errors in files (php_error, error_log, etc.) in the main folders of the website. Do functionality to read those files in the Log Manager. Show information about the errors on the dashboard. You can display information about the number of the errors by Quick Icon plugins, just like Quick Icon - Joomla! Update Notification. It should be possible to download the logged data as a file. It should be possible to download the server log files (php_error, error_log, etc.).

You should provide a form that the administrator will be able to use to send the logged data. He will be able to send the data to the developer of the extension or Joomla! issue tracker. You should provide information about the extension and its developer, if the errors come from third-party extension. The information should be extension name, developer name, email, website, etc.. Do API that developers will use to implement log functionality to their extensions.
Expected Results:
That will make the system easier for troubleshooting. The administrator will be able to react in time getting information about potential problems. He will be able to send logged data to the developers that maintain the extensions. Everyone will be able to use this feature to inform Joomla! teams or developers about problems with their extensions. Developers will be engaged to provide better description and solutions (links to pages with information) of errors that occur in their extensions. That will help to improve the quality of Joomla! CMS and third-party extensions. This feature must be accompanied by documentation in the form of wiki pages, full help screens and video tutorials in 3 min each. The code must be accompanied by appropriate tests.
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC, PHPUnit, Selenium
Difficulty:
Medium
Mentors:
To be defined

Project VIII: Daily Tips (Quick Start Guide or Tips & Tricks)

Project Description:
New Joomla users complain, it is difficult to orient in the system at the beginning. The newbies need quick start guide to become comfortable with the system. Here you are some reviews that will help you to understand the problem better. https://www.trustradius.com/reviews/joomla-2014-12-13-01-47-52 https://www.g2crowd.com/products/joomla/reviews

The idea is to do a tool for Daily Tips (Tips and Tricks) that will be visible on the administration dashboard and on the component pages. It could be Tips and Tricks manager where the administrator will be able to manage the information. The tips will be displayed via modules and plugins. The system will have to show information about most used features and configuration options. The block where the tips will be displayed should provide:

  • navigation buttons for changing tips to next and previous
  • link to video from youtube (you can show the video in popup)
  • link to page with detailed information where the newbie will be able to learn much more

You will have to provide an API for developers. They will use it to add tips about their extensions, during the process of extension installation.

Expected Results:
The daily tips will make Joomla much more clear for new users. They will point users to right direction faster. The newbies will become comfortable with configuration options, components and features really fast. That must be accompanied by documentation in the form of wiki pages, full help screens and video tutorials in 3 min each. The code must be accompanied by appropriate unit tests.
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC, PHPUnit, Selenium
Difficulty:
Medium
Mentors:
To be defined

Project IX: 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 X: 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:
PHP, JavaScript. Nice to have: Joomla MVC
Difficulty:
Medium
Mentors:
To be defined

Project XI: True Role Based ACL for Joomla

Project Description:
The current ACL Implementation in Joomla that uses Groups makes it very hard to scale to really large projects & even for simple use cases you end up having many many groups & Access levels. The same can be achieved in way lesser number of 'Roles'. The idea is to have a way to attach 'Actions' that are defined against an extension to Roles. Roles can be defined to b context specific to a extension or bind to any action across extensions. This allows for simpler management of access. The system ideally can sit alongside the current Group based system so as to not cause Backward compatibility issues. Its also possible to migrate.. But A case could be made for maintaining both.
Expected Results:
Implementation a Role Management system that maps to Joomla extension actions & a view to assign users to roles. Supporting all core Joomla extensions to support Role based ACL
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC, ACL
Difficulty:
Medium to Hard
Mentors:
To be defined

Project XII: Multisite in Core

Project Description:
One of the key features missing in Joomla today in Multi-site. Done right it does not need to be extremely complex. It would involve creating a 'Site Manager' in the backend that lets the Super admin entities called 'Sites'. All the content on the site will need to be Associated with a site. We may also put up for discussion the possibility of associating content & entities against multiple sites. In addition to associating content with sites, the retrieval will also need to respect the site id.
Expected Results:
Screens to manage sites - Add, Edit, Delete. Ability in all content forms to associate content with one or more sites. Update the retrieval to respect site id.
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC
Difficulty:
Medium to Hard
Mentors:
To be defined

Project XIII: Image Map Input Control

Project Description:
This should be a drop-in for a <select> list (single, multiple). Areas (elements and/or polygons) should be mapped to the options of the select element.
Expected Results:
A form using JForms can address the input control.
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC, SVG
Difficulty:
Medium
Mentors:
To be defined

Project XIV: Analog Input Controls

Project Description:
There are a lot of fancy input controls (knobs, sliders, steppers, ...), that do not have the complexity of an image map. They should work as progressive enhancement of standard <input> elements.
Expected Results:
A form using JForms can address these input controls.
Knowledge Prerequisite:
PHP, JavaScript. Nice to have: Joomla MVC, SVG
Difficulty:
Easy
Mentors:
To be defined

Project XV: MicroFormat Content Elements

Project Description:
Create output for semantic data with the appropriate markup. This should be developed using JLayouts.
Expected Results:
Ready-to-use layout files for the most common microformats.
Knowledge Prerequisite:
PHP, HTML5, understanding of microformats. Nice to have: Codeception
Difficulty:
Easy
Mentors:
To be defined


Project XVI: 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 XVII: 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 XVIII: 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 XIX: 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 XIX: 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 XXI: 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 XXI: 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
Retrieved from "https://docs.sandbox.joomla.org/index.php?title=GSOC_2017_Project_Ideas&oldid=364304"