Using Postgres with the Postgis extension to integrate GeoData / GIS functionality in your project is not natively supported by Doctrine and Doctrine migrations.
First you have to add the extension to Postgres, even if you use the Postgis docker image like postgis/postgis:14-3.3-alpine.
So add this SQL statement to the up method of your first migration: $this->addSql('CREATE EXTENSION IF NOT EXISTS postgis;');
and the DROP statement for the extension to the down method: $this->addSql('DROP EXTENSION postgis;');
Now, when using Doctrine with Postgres and Postgis extension, migrations still behave a bit odd and try to remove Sequences created by Postgis, because Doctrine migrations does not take Postgis extension’ s built-in Sequences into account.
Are you annoyed of too many deprecation warnings in you logs of your symfony app? Probably yes because it is really a lot of noise. However deprecation logs are still useful to ensure future compatibility of your app.
So since version 5.1 symfony will log deprecations to a dedicated log channel when it exists and ships with this monolog config:
- deprecation # Deprecations are logged in the dedicated "deprecation" channel when it exists
This is added already in the recipe and ships when installing symfony.
Ok, but the handler for this deprecation channel is not configured, so you have to do this yourself. How? Add this to your monolog config:
There are multiple PHP native ways to convert umlaute and other special characters to ascii save formats, but most of them i experience insufficient in the one or other way.
Since i am using symfony anyway i can use the String component which has a handy slugger which converts any characters into safe ascii characters. It is very flexible and can be customized with locales, custom replacements and closures.
Since SilverStripe 4.10 is not yet fully ready for PHP8.1 you wil receive quite some deprecation warnings in dev mode when you are brave and run it nonetheless on PHP8.1.
Deprecated: SilverStripe\Config\Collections\MemoryConfigCollection implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /var/www/html/vendor/silverstripe/config/src/Collections/MemoryConfigCollection.php on line 13
Unfortunatly we can’t control the error_reporting from SilverStripe since it is set in the kernel of the framework. So we are forced to hack the Kernel which is rather unfortunate.
In the SilverStripe Slack channel someone proposed to use composer-patch which will apply a patch to a given vendor dependency during composer install. This is quite cool because you don’t need to fork the dependency and take care of getting upstream changes.
The psr/log package used to have not only the Interface for PSR-3 Logger, but also actual implementations of the interface like the TestLogger. The TestLogger could be used as mock for any PSR-3 Logger in your test cases.
We will use the csv package from the CSV project which has some sophisticated packages to parse and transform csv data with nodejs streams.
npm install csv
We will further use node as ESM (ECMAScript modules) to be shiningly modern and so lets create a file: index.mjs Note the .mjs extension, which will tell node to interprete this as ESM. (Since nodejs v12.20.0 && v14.13.0)
We import the packages and create the filesystem streams to read the file, then built a pipeline with the streams and the single steps to process the data and write the results into a new file. Ok let’s go: