Upgrade naar Symfony 4

Onze developers hebben iteratie #154 opgeleverd. De grootste wijziging is deze keer het live gaan van de upgrade naar Symfony 4.

Symfony 4 werd al in mei 2017 aangekondigd en werd uiteindelijk in november 2017 vrijgegeven. Het was echter ook meteen duidelijk dat het, net als bij Symfony 3, een flinke kluif zou worden om te upgraden. Aangezien de door ons gebruikte lts- (long-term support-) versie 3.4 nog tot eind 2020 wordt ondersteund, hebben we deze upgrade als een van onze technische projecten op 'de lijst' gezet. Op die manier konden we die upgrade ook de aandacht geven die nodig is.

Drie sprints geleden was dit Symfony 4-project aan de beurt. Daarbij hebben we gelijk de nieuwste stabiele versie (4.2.7) genomen. Bovendien hebben we ons best gedaan om nieuwe deprecations op te lossen, zodat we makkelijk(er) naar 5.0 zouden moeten kunnen. In de praktijk blijkt echter steeds weer dat zo'n upgrade een flinke opgave is en dat deprecations oplossen meestal slechts de eerste stap is van een lange lijst taken. Deze upgrade bevatte uiteindelijk meer dan veertig commits waarin bijna duizend bestanden werden verplaatst, verwijderd of veranderd.

Aanpak

Zoals veel softwarelibraries bereidt Symfony je voor op upgrades door onderdelen die in een latere versie worden verwijderd, alvast als deprecated aan te merken. Na het oplossen van de deprecationmeldingen uit 3.4 konden we daadwerkelijk beginnen aan de upgrade naar Symfony 4.

We hebben ervoor gekozen om niet alleen de Symfony-versie in composer.json te veranderen in 4.2.*, maar om een nieuw, kaal Symfony-project te maken en daar al onze code naartoe te kopiëren. Toen alles daarin werkte, hebben we alles behalve de .git-directory in het normale project verwijderd en dit nieuwe project daarvoor in de plaats gezet. Hierdoor hadden we de minste kans om vast te lopen met conflicterende code tussen Symfony 3 en 4, en was de kans kleiner om iets te vergeten, achter te laten of fout te doen.

Bundles

Een van de grootste wijzigingen waar we tegenop zagen, bleek uiteindelijk gelukkig niet direct nodig te zijn. Eigen bundles werden als verleden tijd beschreven, maar konden, in ieder geval bij ons, in werkelijkheid gewoon gebruikt blijven worden. Onze bundles zijn voor ons vooral handige plekken om controllers, routes en templates te groeperen. En daardoor werkten ze ook goed samen met Symfony 4. Dat groeperen kan echter ook met praktisch gebruik van directories en namespaces. Daarom zijn we nadat de upgrade naar Symfony 4 was afgerond, doorgegaan om ook onze paar bundles met elkaar te integreren.

Nieuwe deprecations

Ondanks het oplossen van de deprecationmeldingen uit 3.4, kregen we bij het testen weer allerlei nieuwe deprecationmeldingen doordat Symfony met 4.1 en 4.2 nieuwe code zo heeft gemarkeerd. Deze meldingen vervuilden de console-output en -logging, waarop we hebben besloten om die ook gelijk op te lossen. Dit waren onder andere deprecations met betrekking tot routebeschrijvingen en translations.

Oud:
['_controller' => 'TweakersFrontpageBundle:Crew:overview']
Nieuw:
['_controller' => [CrewController::class, 'overviewAction']]

Voorbeeld van een wijziging van de routes, van bundlenotatie naar methodereferentie van de controllermethode.

Voor de routes was het vooral een uitgebreide find-replace. Met in totaal iets meer dan zeshonderd routes hebben we dat overigens niet allemaal handmatig gedaan. Uiteindelijk bleek de log-output van Symfony goed te gebruiken om die in een php-scriptje in te lezen en met wat regular expressions de routes allemaal automatisch te vervangen

Translations

Bij de translations was dat minder eenvoudig. Dat komt vooral doordat Symfony weliswaar aankondigde dat er een nieuwe manier van werken is, maar niet uitlegde hoe dat nou echt werkt. Het is op zich heel mooi dat ze nu een volgens ICU gestandaardiseerde manier van translations hanteren, maar het bij elkaar rapen van de nodige documentatie over de werking en het uitvogelen van slecht of helemaal niet gedocumenteerde wijzigingen in Symfony heeft ons uiteindelijk enkele dagen gekost.

Gelukkig is de nieuwe vorm van translations ook gelijk wat krachtiger. Zo is het nu mogelijk om niet alleen op basis van aantallen een keuze te maken, plural genaamd, maar ook op basis van tekstuele waarden: select. En het is nu onnodig om dat apart via transchoice te doen, dat is onderdeel van trans geworden.

Oud, twig en translation:
{{ 'number_of_reviews'|transchoice(userReviewCount) }}
number_of_reviews:
  "{0}|{1}1 gebruikersreview|]1,Inf[%count% gebruikersreviews"

Nieuw, twig en translation:
{{ 'number_of_reviews'|trans({'count': userReviewCount}) }}
number_of_reviews:
  "{count, plural, =0 {} 
    one {1 gebruikersreview} 
    other {# gebruikersreviews}}"

Twig-translation voor het tonen van het aantal reviews, waarbij voor 0 reviews geen tekst wordt getoond

Dit is een behoorlijk grote wijziging in de translation, maar dat komt vooral doordat het semantisch anders werkt. Bij transchoice geef je een count mee en daarmee selecteert die functie de juiste translation. En daarin kan dan weer de %count%-tekst worden geïnjecteerd. Bij de nieuwe manier van werken is er een variabele count, die met {} wordt gemarkeerd. En bij die variabele wordt hier aangegeven dat de plural-functionaliteit daarop moet worden toegepast. Daarbij zijn bij de ICU per bekende taal losse regels mogelijk voor meervouden; dat maakt het tamelijk complex als er veel vertalingen moeten worden ondersteund, maar ook erg krachtig. Zo kent het Nederlands slechts 'one' en 'other', heeft India zelfs alleen maar 'other' en heeft het Welsh juist 'zero', 'one', 'two', 'few', 'many' en 'other'.

Bij het veranderen van de translations moet verder nog de bijbehorende translationfile worden voorzien van een nieuwe naam: articles.nl.yml wordt dan articles+intl-icu.nl.yml. Op die manier herkent Symfony dat de nieuwe MessageFormatter gebruikt moet worden.

Op dit moment hebben wij alleen Nederlandse translations. We gebruiken de functionaliteit vooral om, in nieuwe templates, de teksten te ontkoppelen van de html-code. We hebben vooralsnog geen plannen om Tweakers in verschillende talen aan te bieden.

Opvallende zaken

Tijdens dit project zijn ons een paar dingen opgevallen. Daarbij zaten uiteraard ook positieve zaken. Zo lijkt het erop dat Symfony, zoals zelf aangegeven, met de nieuwe versie inderdaad sneller is geworden. We hebben dit helaas nog niet uitgebreid kunnen testen, omdat onze productieomgeving significant anders is en anders wordt belast, maar dat gaan we uiteraard in de komende tijd in de gaten houden.

Met Symfony Flex gebeuren nog wel wat vreemde dingen. Zo worden er soms bij composer install nieuwe bestanden aangemaakt of bestaande aangepast. Terwijl dat alleen bij commando's als composer update of require zou mogen gebeuren. Daarvoor is in de tussentijd in ieder geval één bug gefixt. We gebruiken het nog niet lang genoeg om te kunnen beoordelen of dit vaker gebeurt of alleen tijdens de upgrade van 3.4 naar 4.2. Het ging behalve om symfony.lock om de bundles.php, .gitignore en diverse configuratiebestanden.

Verder bleek dat de upgrade guide op zich wel een nuttige bron van informatie is, maar uiteindelijk ook de nodige gaten bevat. Er staat bijvoorbeeld in dat allerlei files uit de app-directory verplaatst moet worden, maar geen expliciete melding dat die hele directory in Symfony 4 niet meer gebruikt zou moeten worden. En bij de melding dat views uit app naar templates zouden moeten, wordt niet gemeld dat dat alleen voor twig-templates geldt. De php-templates moeten naar src/Resources/views. En als je dat gedaan hebt, word je doodleuk geconfronteerd met een deprecationmelding dat je die directory niet meer zou moeten gebruiken

Xdebug

Ongeveer tegelijk met de start van ons Symfony-project hebben we onze testomgevingen voorzien van een upgrade naar PHP 7.3, met ook de nieuwste versie van Xdebug, 2.7.0. Normaal gesproken betekenen dat soort upgrades dat het allemaal wat sneller wordt, maar echt veel merken jullie en wij daar niet van. Dit keer werd php juist veel trager. 'Gelukkig' gold dit ook voor versies van onze site die nog met Symfony 3 werkten, waardoor die upgrade al snel als oorzaak afviel

Onze systeembeheerder Kees is daarna op zoek gegaan naar de oorzaak. Het bleek dat dit door de nieuwe Xdebug kwam; ook PHP 7.2 werd met die versie significant trager. Na nog meer onderzoeken met strace bleek dat de oorzaak zat in het feit dat er vele miljoenen aanroepen van de 'getpid' system call werden gedaan. Een paar keer aanroepen is niet zo erg, maar die grote hoeveelheid gaf een 'death by a thousand paper cuts'. Xdebug voerde deze methode uit op de plek waar het steeds opnieuw, bij elke functiecall in de php-code, moest controleren of het was geactiveerd. Het probleem kon uiteindelijk eenvoudig worden opgelost met een verandering van een paar regels code. Ondertussen is versie 2.7.1 van Xdebug uitgekomen, waarin de patch van Kees is meegenomen.

En verder

Best Buy Guides op frontpage

Als onderdeel van de al eerder besproken vernieuwingen tonen we nu op de frontpage een product uit de recentste Best Buy Guide met daarbij relevante links naar de Best Buy Guide en de productpagina in de Pricewatch. Verder vullen we het uitgelichte blok aan met verwijzingen naar de populairste Best Buy Guides van het moment.

Custom CSS

Na de release van de recente wijziging aan de frontpage hebben we behoorlijk wat feedback gehad. Daaruit blijkt dat een deel van jullie bij het bekijken van de frontpage vooral behoefte heeft aan een direct zichtbare, compacte listing en minder aan de zaken eromheen. Dat is via custom CSS redelijk eenvoudig te realiseren, maar we snappen dat niet iedereen daarover beschikt. Om jullie hierin tegemoet te komen, hebben we de hoeveelheid karma die nodig is om custom CSS te kunnen gebruiken, flink verlaagd.

Tot nog toe was dit alleen beschikbaar voor hero- en elite-abonnees en via de karmastore voor actieve tweakers die minimaal 500 karmapunten per half jaar haalden. Dat laatste is veranderd. Nu is custom CSS in de karmastore beschikbaar voor iedereen die minimaal 4096 karma in totaal heeft bereikt. En het blijft daarna ook actief. Het is daardoor voor een grotere groep tweakers beschikbaar en je hoeft ook niet meer actief te blijven na het eenmalig te hebben geactiveerd.

We hebben een aantal ideeën om het uitwisselen van custom CSS, zoals dat nu al gebeurt in het Forum, beter te faciliteren, zodat jullie je eigen tweaks makkelijker kunnen delen. Zodra we daarover iets concreters kunnen melden, laten we het weten.

Code:

#categoryBar, .fpAnkeiler {
   display: none;
}

table.highlights td {
  font-size: 12px;
  padding: 2px 0;
}

table tr.inBetweenContent {
   display: none;
}

Deze code past de frontpage aan naar de hieronder getoonde compactere nieuwsfeed.

Andere verbeteringen:

Het welkomstgeschenk voor Hero-abonnees is veranderd. Zij krijgen nu bij het afsluiten van een abonnement de exclusieve Tweakers Bamboo Coffee Cup.
We hebben productcategorieën toegevoegd voor usb, audio en videohubs, voor officesoftware en -suites, en voor servers.