A Composer Dependencies Revamp has been implemented for Tiki17. with a web-based interface added to Tiki18. Info below is kept for posterity.
Why does Tiki use Composer?
To manage nearly 100 dependencies:
- https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/vendor_bundled/composer.json
- https://composer.tiki.org/ using Satis
How does Tiki use Composer? Look for the string composer in:
https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/setup.sh
See also: Composer
Idea: php console.php that lauches Composer and installs rarely used components, or things that we can't (or prefer not to) bundle in Tiki. This proposal is only about the libraries. Code that uses these libraries continues to be managed in the main Tiki code base, optional as always. This is important to keep things simpler, and avoid http://pluginproblems.com/
Challenges and opportunities
We could eventually turn off mods https://mods.tiki.org/ , which is only used currently for https://doc.tiki.org/PluginR to get around licensing issues (GPL vs LGPL).
Security
- Permissions of files created by the Apache user
- Most of our recent security issues involved libraries managed by Composer but not used by everyone. All Tiki files have a feature and permission check which makes them only a risk if active How+to+release#Check_that_all_PHP_files_have_a_feature_check but we don't have this for external libs.
License incompatibilities
- Sometimes, the best library is of an incompatible license (but still OSI compliant). See License
- We have spent a lot of time in the past to work with upstream projects to change the license (Bootstrap, Bootstrap Tour, etc.). But sometimes, it's just not possible.
Without shell access
- What we develop should work for users without shell access or, at least, they should have a documented procedure. For example, download this file abc.zip and unzip in folder /var/www/virtual/example.org/vendor_custom.
- Mods has such documentation
- What is installed manually vs. custom libs installed by composer should be stored in a different directory.
- The vendor/ directory can be deleted and everything is re-generated (great!).
- We wouldn't want to have to track manual vs. system managed dependencies....
- The vendor/ directory can be deleted and everything is re-generated (great!).
- Could be a Phar instead of a Zip
Single composer.json file
- Modifying the composer.json file, which will get overwritten on upgrades
Jordi suggested: Composer#Split_composer.json_information_into_two_files .
End goal
- A checkbox in tiki-admin.php that installs Composer Libraries when the relevant feature is activated.
- This should run Composer if it can
- If it can't, but for users with shell access: it should tell the user what shell command to run
- For those with no shell access, it should tell the user what to install where (like Mods: http://twbasics.tikiforsmarties.com/Installing+Mods+Manually ). This more or less is what people need to do now for ViewerJS and mPDF. Suggested location is a vendor_custom directory.
- This should run Composer if it can
- Tiki code that uses these libs would check for them,
- If someone manually added a lib, and it's now out of date, there should be a warning in tiki-admin.php
- If there is a security vulnerability, an email should be sent out. (This is actually something missing in Tiki in general.)
- Tiki code that uses these libs would be maintained in common code base to keep things simpler.
- If there are any post-install-cmd , they should be run
Perhaps via Tiki console (and launchable via TRIM) and also doable via tiki-admin.php
Composer#Optional_libraries
Composer#Web-based_management
Composer#Locations_of_optional_libraries
Examples:
- ViewerJS (AGPL)
- mPDF (50 Megs)
- https://packagist.org/packages/mpdf/mpdf
- make sure permissions are OK
- Font handling should better in the future and permit optional addition of fonts
- Piwik
- Ideally, would be able to install Piwik using the same database as Tiki (table names are prefixed so no collision is possible).
- https://packagist.org/packages/piwik/piwik
- SEOstats
- https://packagist.org/packages/gidkom/php-openfire-restapi
- Better optional because only useful if interacting with Openfire (which is the WikiSuite use case).
- FullCalendar Scheduler (GPL)
- PhantomJS and CasperJS
- Maybe http://diagramo.com/
- https://github.com/thiagoalessio/tesseract-ocr-for-php
- A library to create charts server-side so they can be in emails and in PDFs generated by mPDF
- https://github.com/alchemy-fr/Media-Alchemyst As it's likely we'll add for Tiki 18 (file, video and image manipulation needs)
- BPMN
- Maybe (license is an issue)
- https://github.com/fzaninotto/Faker Perhaps could be triggered by profiles. -> Faker
- Perhaps translations (of the Tiki interface)
- Would be a good time to review translation workflow
- And perhaps resolve the challenge of branches and translations. (ex.: Everyone grab from trunk)
- And reduce number of lines of PHP reported here: https://www.openhub.net/p/tikiwiki/analyses/latest/languages_summary
Bonus questions
- Could Tiki itself be installed via Composer?
- If so, should it? TRIM vs RPM/DEB/PPA vs ClearOS apps
- Any suggestions to improve the way Tiki uses Composer?