[META] Get phpList 4 up to speed
oliverklee opened this issue · 15 comments
- set up the usual stuff to have a clean and friendly open source project on GitHub (i.e., the usual best practices):
- #23 add a LICENSE and decide on which license to use (currently, the README mentions both the GPL as well as the Affero GPL)
- #42 clean up the README.md
- #51 rework the CONTRIBUTING.md
- #29 add a CODE_OF_CONDUCT.md
- #26 add a CHANGELOG.md
- #26 adopt semantic versioning
- #27 go PHP-7-only (drop support for PHP 5.6)
- #47 update the .gitignore
- set up a CI chain to automate as much stuff as possible, thus making contributing and reviewing PRs less work:
- make updates with two commands possible (composer update and DB migrate)
- restructure the project into two projects (similar to the way TYPO3 CMS does it):
- the core (which will not be modified locally)
- a site package which includes the core, and which is intended to downloaded when installing a new site site with phpList, and then not re-downloaded, and where additional/changed HTML templates can be installed
- decide on whether and how we should provide an all-in-one package
- make (reversible) DB migrations via the command line possible
- restructure the project into two projects (similar to the way TYPO3 CMS does it):
- make automatic deployments of updates possible, e.g. via TYPO3 Surf, Capistrano etc.
- document which steps are needed for deployment (and the initial install)
- security:
- #54 move as much stuff as possible out of the document root
- remove or replace the code that has raw SQL queries and might have SQL injections
- reuse as much stuff from tested third-party libraries (via composer) instead of rolling our own (so we can focus on the stuff we really need to do for ourselves, avoiding the NIH problem):
- ORM: Doctrine ORM (and Doctrine QueryBuilder for parts where Doctrine ORM is too slow)
- Command line stuff: Symfony Console
- configuration: Symfony YAML
- Routing: Symfony Routing
- HTML templating: Twig
- Logging: Monolog (PSR-3 compatible) #2
- DB Migrations: Doctrine ORM
- creating emails: Swiftmailer (or maybe keep PHPMailer)
- HTML/CSS for the app: Twitter Bootstrap
- CSS for the emails: Zurb Foundation for emails/Zurb's email framework
- rich-text editing: CKEditor, Raptor Editor, Odoo
- inline CSS for emails (if needed): Emogrifier
- large data processing/search/statistics: Elasticsearch
- translation/localization: XLIFF
- tests:
- #76 add integration tests in addition to the unit tests
- extensibility
- decide on whether and how we should allow different mailers
Wow, thanks Oli for getting things into action here. Cheers.
A few comments on this:
- Swiftmailer vs Phpmailer: maybe judge first, which one is more suitable
- TurboLinks is nice, but a big nice-to-have I would say
- inline CSS: take a look at Zurb's email framework
- If we could use Fluid here for templating this would be super-huge-awesome
Ah one thing you have to check first: Most of those libs are GPL AFAIK. phpList is not GPL so you have to check compatibility of licenses.
@liayn If I include the libraries via composer, but don't copy them into the project, does the license matter then?
@liayn Thanks for the comments! I've included them in the list.
Well, I'm not a lawyer, but I see it the other way around: You still want to provide a downloadable full package of phplist in the future, hence the composer install has to be done during packaging. At this point the license matters for sure.
Oh, actually I'd prefer it to be composer-deliverable only as this will allow easier updates. (Updates with the old all-in-one package are a real pain.)
I have experience with this with other products... you will lose 90% of your user base.
Consider all those small usecases where people don't send thousands of mails, but run a tiny instance on their FTP-only hosting.
SwiftMailer vs phpMailer, I think we should try being mailer independent. A bit like this, https://github.com/phpList/phplist3/blob/master/public_html/lists/admin/EmailSender.php
I'll start a discussion about the all-in-one package issue on the developer list. Maybe we can offer an option that people without SSH access can download the package, run a composer install, and then copy the whole thing (including the vendor folder) to the web server?
@michield What would we (ro the user) gain from being mailer-independent? (The user will never use the mailer directly.)
Well, yes, good idea basically, but composer requires a local PHP, which is a bit out of scope I would say. (for non-devs)
@oliverklee mailer independence will allow adapting to new mailers quicker.
The packaging issue is something to think about. We will want to be able to package the lot for easy download and install. Even though the future may be delivering it in a Docker container instead. Maybe we should discuss this on the mailinglist.
It is fine to mix GPL and AGPL. Basically both require providing the source, and AGPL is more restrictive (eg you have to provide it, even if you use it to run as a service). You particularly have to provide the source, if you make changes to it.
Just the nature of having it here on Github means it's provided. Moreover, the AGPL will ensure that hosted versions have to use the same code. Some people think that phpList Hosted is a different version of the code. It is not, and the AGPL makes sure of that.
http://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant
I've moved the TurboLinks to-do to the new performance meta-ticket #30.