Git Product home page Git Product logo

core's Introduction

phpList core module

Build Status Latest Stable Version Total Downloads Latest Unstable Version License

About phpList

phpList is an open source newsletter manager. This project is a rewrite of the original phpList.

About this package

This is the core module of the successor to phpList 3. It will have the following responsibilities:

  • provide access to the DB via Doctrine models and repositories (and raw SQL for performance-critical parts that do not need the models)
  • routing (which the web frontend and REST API will use)
  • authentication (which the web frontend and REST API will use)
  • logging
  • a script for tasks to be called from the command line (or a cron job)
  • tasks to create and update the DB schema

Please note that this module does not provide a web frontend or a REST API. There are the separate modules phpList/web-frontend and phpList/rest-api for these tasks.

This module should not be modified locally. It should be updated via Composer.

Installation

Since this package is only a service required to run a full installation of phpList 4, the recommended way of installing this package is to run composer install from within the phpList base distribution which requires this package. phpList/base-distribution containrs detailed installation instructions in its README.

Contributing to this package

Contributions to phpList repositories are highly welcomed! To get started please take a look at the contribution guide. It contains everything you would need to make your first contribution including how to run local style checks and run tests.

Code of Conduct

This project adheres to a Contributor Code of Conduct. By participating in this project and its community, you are expected to uphold this code.

Structure

Running the web server

The phpList application is configured so that the built-in PHP web server can run in development and testing mode, while Apache can run in production mode.

Please first set the database credentials in config/parameters.yml.

Development

To run the application in development mode using PHP's built-in server, use this command:

bin/console server:run -d public/

The server will then listen on http://127.0.0.1:8000 (or, if port 8000 is already in use, on the next free port after 8000).

You can stop the server with CTRL + C.

Development and Documentation

We use phpDocumentor to automatically generate documentation for classes. To make this process efficient and easier, you are required to properly "document" your classes,properties, methods ... by annotating them with docblocks.

More about generatings docs in PHPDOC.md

Testing

To run the server in testing mode (which normally will only be needed for the automated tests, provide the --env option:

bin/console server:run -d public/ --env=test

Production

For documentation on running the application in production mode using Apache, please see the phpList base distribution README.

Changing the database schema

Any changes to the database schema must always be done both in phpList 3 and later versions so that both versions always have the same schema.

For changing the database schema, please edit resources/Database/Schema.sql and adapt the corresponding domain model classes and repository classes accordingly.

Developing phpList modules (plugins)

In phpList, plugins are called modules. They are Composer packages which have the type phplist-module.

Bundle and route configuration

If your module provides any Symfony bundles, the bundle class names need to be listed in the extra section of the module's composer.json like this:

"extra": {
    "phplist/core": {
        "bundles": [
            "Symfony\\Bundle\\FrameworkBundle\\FrameworkBundle",
            "PhpList\\Core\\EmptyStartPageBundle\\PhpListEmptyStartPageBundle"
        ]
    }
}

Please note that the key of the section with extra needs to always be phplist/core, not the name of your module package. Please have a look at the composer.json in the rest-api module for an example.

Similarly, if your module provides any routes, those also need to be listed in the extra section of the module's composer.json like this:

"extra": {
    "phplist/core": {
        "routes": {
            "homepage": {
                "resource": "@PhpListEmptyStartPageBundle/Controller/",
                "type": "annotation"
            }
        }
    }
}

You can also provide system configuration for your module:

"extra": {
    "phplist/core": {
        "configuration": {
            "framework": {
                "templating": {
                    "engines": [
                        "twig"
                    ]
                }
            }
        }
    }
}

It is recommended to define the routes using annotations in the controller classes so that the route configuration in the composer.json is minimal.

Accessing the database

For accessing the phpList database tables from a module, please use the Doctrine model and repository classes stored in src/Domain/ in the phplist/core package (this package).

For accessing a repository, please have it injected via dependency injection. Please do not get the repository directly from the entity manager as this would skip dependency injection for that repository, causing those methods to break that rely on other services having been injected.

Currently, only a few database tables are mapped as models/repositories. If you need a mode or a repository method that still is missing, please submit a pull request or file an issue.

Accessing the phpList data from third-party applications

To access the phpList data from a third-party application (i.e., not from a phpList module), please use the REST API.

Copyright

phpList is copyright (C) 2000-2021 phpList Ltd.

core's People

Contributors

aleksanderkoko avatar bizmate avatar fenn-cs avatar marianaballa avatar michield avatar moshekaplan avatar oliverklee avatar samtuke avatar sawey avatar schmidtsabine avatar xh3n1 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

core's Issues

Investigate separation of public, private, and shared assets

Some access control use cases would be simplified if assets with different security contexts were grouped and separated (e.g. public subscribe paths, admin paths, and items shared by both). In phpList 3 these assets are generally directory based, with routes corresponding to directories. In phpList 4 it may be convenient to use routes to enable web-server based access control based on such routes.

Further investigation of this possibility is required.

Requested in phpList/phplist3#336 (comment)

[Not an issue] Release v4?

Just ask if you have planned any release of the new version or still in a early development.

Thanks for all

SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) supports

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

Can you add support for?

LDAP:

  • RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

I add SCRAM-SHA-512(-PLUS): https://xmpp.org/extensions/inbox/hash-recommendations.html

Linked to:

"phone home" - slow admin panel

Hi,

I'm installed phplist for one of my firends. Latety he complains that admin panel is working very slowly. First we thought that could be mySQL problem. But after tuning changes admin panel still works sloooowly.

After some investigation :-) I suspected a "newsfeed" script which is connecting to phlist.org for news. After disabling it (by commenting the whole lists/admin/ui/dressprow/rssfeed.php) admin panel working very quickly.

I've checked this code. Well, I don't have patch to correct this script, but I'll try to write some thoughts how it could work (maybe quicker):

  1. Check if there is "cache" of feeds: file or mysql
  2. Check if this "cache" is quite fresh - let's say 1 day/week/moth. It could be a config parameter
  3. if cache is "out of date" (or does not exists) download it from phplist.org (do "phone home").
  4. Display news on panel (last N entries) from cache.

I think such mechanism will make less "calls" to your servers, users will see that admin panel is working faster. Also phplist is not a news portal :-))) so changes are not published every minute.

I hope my suggestions will help you with your work

[META] phase 4

  • switch the URL to SemVer in the changelogs to HTTPS
  • drop the old core code
  • #286 Cleanup: use Doctrine\ORM\Mapping as ORM;
  • #287 use 32bit-safe timestamps as exception codes
  • upgrade phpstan
  • add composer scripts for most of the Travis build steps
  • use the directory names as defined in http://php-pds.com/
  • create a test branch with Symfony 4
  • add other bundles that are standard for Symfony applications
  • add the Symfony requirements checker
  • require Symfony >= 3.4 (and update the other dependencies)
  • make the project structure more similar to the default Symfony project structure
  • research whether to use doctrine validations
  • use Symfony bundle hooks
  • research incenteenv
  • console command for purging old session tokens
  • add functionality to automatically add new lines to parameters.yml
  • decide on what to log
  • #2 add/configure logging
  • log things
  • document the logging
  • support/configure HTTP caching (last modified header, eTag, HEAD requests?), also research whether and how to use and set “valid until” headers
  • decide whether to switch to Symfony 4 (which would require PHP >= 7.1)
  • phpList 3 Functionality dependency review (to determine order of next steps)
  • #191 support SQLite
  • create a "phplist4 module template" repository
  • Include example module with composer package and repo, plus tips on adding DB tables, using hooks etc.
  • provide a way to have different DB credentials in the tests via a yaml file (instead of via environment variables only)
  • Configuration wizard that copies PL3 configuration to PL4 (and than can be run multiple times) (old configuration: https://resources.phplist.com/system/config/variables)

[META] Performance

Route conflicts

@samtuke, I've done some testing and some research on representing conflicts for phpList modules that provide the same routes (e.g., "/" or "/api/v2/"):

  • When a route with a path already is set, it cannot be overwritten - the first route "wins", and the second route with the same path is silently ignored.
  • The installation order of Composer packages is that requirements are installed first. So if another module depends e.g., on the phplist/web-frontend package (and our package provides the "/" route), the route from phplist/web-frontend will win, i.e., the "official" route will win. If there is no dependency, the order is not fixed, though.
  • As far as I can see, there is no way to have something like "this package provides the startpage-route capability, and it conflicts with all packages that also provide this route" in a composer.json, as in that case the package would be in conflict with itself.

I've come to the conclusion that the risk of conflicting routes is relatively low anyway, and by properly using the dependencies, the official route "wins". So I'd like to not add any additional conflict mechanism, if there are no objections. @samtuke, @michield, any opinions on this?

[BLUEPRINT] Module registration

This is the plan for how module registration for phpList 4 should work. Comments and feedback welcome.

Principles

  • All phpList modules are Composer packages that are recognized by the package type phplist-module defined in the composer.json.
  • A phpList module package must only contain code, assets and configuration related to this package. The module-related files must also not be "piggy-backing" in some other package. Packages still can depend on other packages and make use of their code, though (by adding them to the require section of the composer.json).
  • From the view of the administrator/user, a module is installed by requiring it in the root package composer.json and then running a composer update. It will not be possible for a package to be in an "installed, but not activated" state.
  • It must be possible to test module packages on their own, i.e., without the base-distribution package, both with automated tests as well as manual tests. (The module package usually will depend on at least the phplist4-core package, though.)
  • Modules that provide the same capabilities (e.g., the same routes) can be configured via their composer.json to conflict with each (or more specifically: with other packages that provide the same capabilities) (TODO: document how to do this)

Technical approach

  • For the installed application, each bundle can bring its own configuration that will be auto-included once the bundle is included.
  • There will be an application-wide configuration file that lists all module-provided bundles (i.e., their class names).
  • Each module package must provide the class names of its provided bundles in the extra section of its composer.json.
  • The phplist4-core package will provide a composer script that lists all installed modules (i.e., all installed composer packages that have the corresponding type). (The core might need to read vendor/composer/installed.json for this. I'll need to check this.) This script will be there mainly for convenience, and also to keep the PRs relatively small. This script will also be accessible via a bin/console command.
  • The phplist4-core package will provide a composer script that runs through all installed module packages, reads their composer.json file, and generates the root application bundle classes file. This script will listen to the update and install events of all phplist 4 packages (including the core). It will also listen to the package creation event of the base-distribution package. (NB: Scripts will always only be executed for the current root package, not for any dependencies.)
  • The "empty start page" will be moved to a separate module package (for which we still need to find a good name). This package will be included by default in the base-distribution package (as long as the web-frontend package does not provide any usable content). This package will conflict with the web-frontend package as both provide the / route (i.e., the root route). This package will also be used by the automated tests for module registration in the phplist4-core package.

(Planned) Pull requests

  • #153 Add a function for provided the path to the application root.
  • #155, #156 Add a composer script that lists all installed module packages to the phplist4-core package. This will include a PHP class for this that can also be used for other things.
  • #157 Add the not-yet-autogenerated bundles classes configuration file to the phplist4-core package, move the REST API configuration and the "empty start page" configuration there, and add it to Git. (At this stage, the phplist4-core still has hard-coded references to the rest-api package.) (This config file will be removed once auto-generation of the config file is added.)
  • #158 Add the script that auto-generates the root configuration file to the phplist4-core package and delete the old manual configuration file. Add composer listeners for update and install to the phplist4-core package and add the file to the .gitignore.
  • Change the "empty start page" bundle to auto-include its configuration.
  • For all module packages and the base-distribution package, add composer listeners for update and install to the phplist4-core package and add the file to the .gitignore.
  • #168 Add a script that auto-generates a routes configuration file.
  • phpList/rest-api#40 Add the configuration file to the rest-api package.
  • #183 Clean up the code for the empty start page in the phplist4-core package.
  • #179, #205, #207 Use dependency injection.
  • #203 Allow modules to provide their own (non-service) configuration
  • Use the FOSRestBundle for our REST module.

Update all packages to latest possible versions to enable full php8 support.

Description

Currently dependencies cannot resolve non-conflicting installable versions on php8.0. Failing build commands are marked with continue-on-error: ${{matrix.php-versions == '8.0' }} # [temp-php8] to ignore php8.0 errors in the .github/workflows/ci.yml. It's the required to also ignore build errors on php8.0 for phpList/rest-api which depends on phpList/core.

Once we are fully able to support php8.0 on core, build error for php8.0 ignored in phpList/rest-api may no longer be ignored.

RFC6331: Moving DIGEST-MD5 to Historic

20 November 2008: CRAM-MD5 to Historic:

29 June 2017: CRAM-MD5 to Historic:

July 2011: RFC6331: Moving DIGEST-MD5 to Historic:

There are now:

  • July 2010: RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM): SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802 (SCRAM-SHA-1 and SCRAM-SHA-1-PLUS)
  • July 2010: RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803
  • November 2015: RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS: Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677

[META] phase 3

  • #159 support for PHP 7.2
  • #239 provide the source code language in the code snippets in the README
  • #124, #241 make sure everything is fine both with the lowest as well as highest version of the dependencies
  • #252 add a model and repository for subscriptions
  • research whether a m:n association can have an automatic creation date
  • #246, #264 use a shared integration test for the core and the REST API
  • #261 use touchDatabaseTable in the ModificationDateOfNewModel and fix any bugs in touchDatabaseTable with this
  • rework the login code so a web login for non-superuser admins will be possible
  • block authentication for disabled admins
  • add badges for code coverage
  • research how to nicely display the code quality, e.g., with badges?
  • #247, #??? add system tests for all three environments
  • document how to run the dev server for all 4 sub projects
  • #237 rework the documentation
  • add and configure Symfony caching
  • add and configure Doctrine caching
  • disable all caching for the development and testing contexts (including route caching

[META] Get phpList 4 up to speed

  • 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
  • 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

Remove unused phpList 4 classes (pre-rewrite)

Short problem description

The old phpList 4 classes contained within this repository are no longer used and cause failures of some testing tools such as Scrutinizer. They may also be confusing for first-time contributors browsing the codebase. Therefore it is best to remove them. Their usefulness for reference seems to have been exhausted; at least they have not been referred to in many months to the best of my knowledge.

Outdated schema.sql

There have been several DB schema changes in phpList3, not applied in core schema.sql yet.

Add Travis builds

This is a request to the project owners: Could you please set up Travis builds for this project, a .travis.yml and a master build status badge in the README?

Thanks!

Schema validation errors

Short problem description

Entities define a schema that is invalid according to doctrine schema validation tool. As a result the schema cannot be created

Steps to reproduce

  1. bin/console doctrine:schema:validate
  2. shows validation errors
[Mapping]  FAIL - The entity-class 'PhpList\Core\Domain\Model\Messaging\SubscriberList' mapping is invalid:
* The field PhpList\Core\Domain\Model\Messaging\SubscriberList#subscribers is on the owning side of a bi-directional relationship, but the specified mappedBy association on the target-entity PhpList\Core\Domain\Model\Subscription\Subscriber# does not contain the required 'inversedBy' attribute.

[Mapping]  FAIL - The entity-class 'PhpList\Core\Domain\Model\Subscription\Subscriber' mapping is invalid:
* The field PhpList\Core\Domain\Model\Subscription\Subscriber#subscribedLists is on the owning side of a bi-directional relationship, but the specified mappedBy association on the target-entity PhpList\Core\Domain\Model\Messaging\SubscriberList# does not contain the required 'inversedBy' attribute.


In SchemaException.php line 109:
                                                                  
  The table with name 'phplist.phplist_listuser' already exists.  

  1. As a result also the schema cannot be generated

Expected behaviour

no errors when running bin/console doctrine:schema:create and a consistent db structure as a result

Actual behaviour

As per description in steps

System configuration

docker, php7.2, mysql 5.7
Extra info at https://github.com/bizmate/phplist-benchmark

Package version

dev-master tried both hashes 9f890f2 and d4dc77b

PHP and Composer version

php - php7.2 ( https://github.com/bizmate/phplist-benchmark/blob/master/docker/php/Dockerfile#L1 )
Composer version 1.9.3 2020-02-04 12:58:49

Restore config.ini

I noticed that config.ini has been removed. I would be good to have a default.config.ini or example.config.ini file providing default config values.

Provide migration instead of being backwards compatible

I know this is quite a huge deal for Michiel and maybe for others, but I think it will be confusing when not changing the database at all.
Now that messages have become campaigns and users have become subscribers, it would make a lot of sense to change the naming in the database as well.
It will be confusing to put subscribers in the users database and do queries referencing user_ids etc.

I would even want to suggest another change, not to use mailing-lists anymore, but switch over to a more general filter system (so mailing lists can be compared to user attributes).
We can have categories of filters like:

  • Mailing lists
    • News
    • Development
  • Favorite color
    • Red
    • Green
      And use regular attributes as filters as well
  • Name
  • State
  • Country
  • ...

The GUI could easily split this up and still pretend like we use lists, but it might be easier to build a general filter for which subscribers need to receive a given campaign.

[META] phpList core phase 2

This meta ticket covers the core-related tasks for phase 2. The base-distribution-specific tasks are listed in phpList/base-distribution#18, the rest-api-specific tasks are listed in phpList/rest-api#20, and the web-frontend-specific tasks are listed in phpList/web-frontend#16.

  • #131 get the Travis builds to work on Trusty
  • #133, #138 rename the branch alias from 4.0.0-dev to 4.0.x-dev https://getcomposer.org/doc/articles/aliases.md#branch-alias
  • #135 add a .htaccess
  • #136 add the Symfony console
  • #139, #140 automatically determine the application root directory
  • debug logged routing exception (was the 404 error for the missing favicon)
  • #141 move the bin/ and web/ dir copying script to the core
  • #122 add favicons in different sizes (to avoid the 404 errors)
  • #145 fix error "You are not allowed to access this file." in development mode
  • #146 set up the log and cache directories
  • #148 move the environments to an interface
  • #134, #137, #147, #149 make the project structure more similar to the default Symfony project structure
  • #147, #149 clean up the configuration files
  • #150 add a server console command and document it
  • #150 document how to use the different environments
  • de-duplicate the director creation in the repositories
  • add a structure for a configuration file that is outside the vendor folder
  • #175 rename Bootstrap::preventProductionEnvironment
  • #151, #153, #158, #168 add a mechanism for modules to register themselves to the core via Composer
  • #168 document how to create/add modules
  • #168 remove the dependency on the REST bundle
  • #181 automatically clear and warm all caches on composer update
  • #182 document when to use the REST API and the repositories when writing modules
  • #180 configure the "hello world" route to only accept GET requests
  • #183 rename the "hello world" route
  • #183 make the root route an official "nothing is here yet" route
  • #183 rename ApplicationBundle to HelloWorld bundle
  • move the CI stuff into a shell script (or into several scripts)
  • #188, #189 move the production secret to environment variables or the "outside" configuration file
  • #190 add DB configuration via YAML files
  • #196 use the Symfony-Doctrine integration
  • #179, #205, #207 add DI and use it
  • #203 Allow modules to provide their own (non-service) configuration
  • #218 add a model and repository for lists
  • use the FOSRestBundle for rest-api
  • #223 add a model and repository for subscribers
  • allow setting the DB configuration via a configuration file in addition to environment variables
  • have a look at other systems and their APIs
  • #194, #235 Fix cache clearing for broken configurations

Symfony framework [question]

Hi!

As soon as you are already using some Symfony2 components, why not using the Symfony2 Fullstack to bootstrap application development? I think this will make code more consistent and incapsulated i.e. with using container instead of global constants and static classes and ini config. Also it's provides essential libraries, like Doctrine2 ORM and Swiftmailer which allows you to focus on business logic and fits better to OO style of this version

Introduce CS tools

In order to keep code clean and consistent, I would suggest you to use some CS lint and fix tools.

For PHP: PHP Code Sniffer and php-cs-fixer.

For JavaScript: ESLint

You may also use a SaaS service to help you with code auto-fixing and PR comments.

I made a service like this: https://flintci.io

If you are interested, I can made some Pull Requests. What are you current standard constraints?

Regards.

Add error handling for failed database connection

Short problem description

Following successful installation via base-distribution package, when database credentials have not been set, a Symfony FOSRest bundle error is displayed.

Expected behaviour

A clear and simple error message stating that the database connection failed

System configuration

PHP and Composer version

PHP 7.2.17
Composer 1.8.4

Project Structure Proposal

Namespace Refactoring

Currently we include version in our namespace:

namespace PhpList\PhpList4\Core

I think we will have trouble when relasing a next major version for example 5.0.0. Contributor will get confused whether the same class can be used or not in 5.0.0 version. Please take a look at symfony. Symfony have a different version from 2.0 to 4.0. Some components act differently in each version. To make maintenance easier we don't see any version included on symfony namespace.

We can use git branch feature to maintenance spesific version of phplist, so we don't have to stick a namespace into a spesific namespace. For example:

  • branch 3.0: for phplist version 3.0 (yes, we can even use same git repository to maintenance 3.0 version)
  • branch 4.0: for phplist version 4.0

Thanks to psr4 autoloading. This namespace will create an unnecessary sub directory in psr0 autoload:

// path/to/phplist4-core
src/
----- PhpList
----------- PhpList4
------------------ Core

I suggest we just use a more simple also a more common practice used by an opensource project:

namespace PHPList\Core;

I know this refactoring can produce a lot of error. With find and replace (php editor feature), and phpunit tests to detect any error; I think we can refactor namespace easily.

Testing Configuration

1. phpunit.xml.dist File

By default phpunit will search phpunit.xml in the current working directory (path/to/phplist4-core), if this file is not exists then phpunit try to find default configuration file which is phpunit.xml.dist. I think it's more simple to just use phpunit without having to pass --configuration in command:

# path/to/phplist4-core

./vendor/bin/phpunit
# command above is more simple then:
./vendor/bin/phpunit  -c Configuration/PHPUnit/phpunit.xml

So I suggest we need to put our configuration file in path/to/phplist4-core/phpunit.xml.dist, and git ignore the path/to/phplist4-core/phpunit.xml file because it should be a custom configuration for every developer.

2. Testing Configuration

We should separate testing configuration from project configuration. so we need to move all tests configuration from Configuration directory to tests/config.

Directory Naming Conventions

I suggest that we use lowercase for non namespace directory. So when we see Configuration directory we will know that it will contain a class, while config dir only contain a configuration file. Here's my sugestion:

  • tests directory: Since there are no namespace called Integration, Support, and Unit, we just use lowercase name for this directories
  • Configuration directory: we just use simply use config because it is a common name used by symfony based project to store configuration files.
  • Database directory: we need to rename this directory to data.

Here's what I hope phplist4-core project directory like:

path/to/phplist4-core
├── config
│   ├── config.yml
│   └── # other config files...
├── data
│   ├── phplist-db.mwb
│   └── Schema.sql
├── src
│   ├── Core
│   ├── Routing
│   └── System
└── tests
    ├── config
    │   ├── code-sniffer-ruleset.xml
    │   ├── phpmd-ruleset.xml
    │   └── phpunit-travis.xml
    ├── integration
    │   ├── Composer
    │   └── Core
    ├── system
    └── unit
        ├── Core
        └── Domain

Some References

Here's some sample of good symfony based project that we can implement in phplist:

Drop StyleCI from the CI process

I'd like to have PHP_CodeSniffer only as the style rules of the CI then will be the same as of the grumphp pre-commit hook. Also, this will allow us to modify the rules with a configuration file in the repository.

[Meta] Build core component classes

  • Admin Class (which is not User Class).
  • Subscriber Class
  • List/Campaign Class
  • ...

Up to us to decide on which components we will keep on core.

"phone home" issues and security

The existing version 3 of phplist has a somehow worrying issue. It "phones home" via several methods that can't be disabled via a config option.

The one that worries me most is the rss feed on the dashboard, which is a security risk. In the past, we've seen some serious exploits in the unserialize() function of PHP. Unfortunately, the rss on the phplist dashboard uses exactly that, to load remote memory arrays directly to the PHP interpreter.

This can be exploited by someone first getting access to the remote phplist server, or by using a man-in-the-middle attack (like DNS injection) to send a malicious string to thousands of phplist installations.

Since version 4 is still in development, I propose a few quick solutions to avoid any potential security issues in the future:

  • Add a config parameter to disable the rss calls on the dashboard.
  • Stop using unserialize(), instead use a proper XML or JSON reply from the phplist server and add some checks and limits on the strings contained within that reply.
  • Verify the remote reply via secure keys or similar method, to make sure the reply is being generated by the phplist server.

Please let me know what you think about the issue.

Thank you.

Add a CODE_OF_CONDUCT.md

I'd like to use the [Contributor Covenant Code of Conduct"(http://contributor-covenant.org/version/1/4/) for this, which more or less is the standard CoC for projects on GitHub that have a CoC.

Part of the document needs to be an email address to which people can write when they experience/witness harassment or other violations of the CoC. Which email address should I use for this?

Offer a way to directly include the newsletter signup in a website

(I assume this is the correct repo to use going forward instead of phpList3, let me know if not @samtuke :)

What would be incredibly useful is a small building block / widget of HTML + JS which allows people to simply add an input field to a website (like the frontpage) where people directly put their email address.
This would simplify the flow a lot for users.

For example, compare the direct email input with subscribe button on http://www.theatlantic.com vs the linked button at https://nextcloud.com – there we could simply have an input field + button at the bottom of the page, and that’s all that subscribers would ever see. No extra page load and no redirect to different interface = probably more signups. :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.