Als ik XAMPP gebruik voor lokaal werk aan PHP scripts, schakel ik telkens de Xdebugger aan en uit vanwege de vertraging van PHP door Xdebug. Als ik geen foutopsporing nodig heb, schakel ik Xdebug geheel uit.
Er zijn goede aanbevelingen voor het versnellen van PHP bij gebruik van Xdebug, bijvoorbeeld hier en hier. Desondanks schakel ik Xdebug liever helemaal uit.
Omdat ik in een Windows omgeving werk, schreef ik twee batch-bestanden die ik in de XAMPP directory plaats naast de bestaande batch-bestanden van XAMPP, apache_start.bat en apache_stop.bat.
Het eerste script, apache_debug.ps1 start Apache op met actieve debugger. Dit doet hij door een blok met Xdebug instellingen in het PHP.ini bestand te injecteren, vlak voordat Apache wordt opgestart.
Het tweede script herstart Apache zonder actieve debugger. Hier wordt het blokje Xdebug instellingen in commentaar verstopt, voordat Apache opstart.
Voor het gemak heb ik ook een derde script dat de huidige debugstatus meldt. Soms vergeet ik of de debugger aan staat.
Alle scripts werken ook al Apache als service draait.
Installeren
Kopieer de drie scripts naar de map met de XAMPP installatie, standaard is dat C:\XAMPP. Als XAMPP zich ergens anders bevindt, pas dan de $xamppDir declaratie aan die aan het begin van de scripts staat.
Gebruik:
Voer de scripts uit vanuit een terminal venster. Of gebruik onderstaande automatisering.
Optionele verbetering:
Gebruik eventueel deze VS Code integratie:
Om VS Code de debugger automatisch aan en uit te laten schakelen, kunnen de volgende twee .vscode/tasks.json worden toegevoegd:
1. Add two shell tasks in `.vscode/tasks.json`:
– één taak om `apache_debug.ps1` uit te voeren voor foutopsporing begint;
– één taak om `apache_restart.ps1` uit te voeren na de foutopsporing.
2. Zorg ervoor dat deze taken worden uitgevoerd in PHP-debug configuratie in `.vscode/launch.json` door gebruik te maken van:
Samenvatting: een gebruikelijke manier om paginering weer te geven is om de link ‘vorige pagina’ aan de linkerkant van de bladspiegel uit te lijnen, de link ‘volgende pagina’ aan de rechterkant en de pagina nummers ergens in het midden. Dit kan bereikt worden door in de taakbalk van het paginering-blok te kiezen voor ‘Wijzig uitvulling van items’ en dan voor ‘Afstand tussen items’. Deze layout houdt evenwel geen stand als de eerste of laatste pagina van de Query loop bereikt wordt. Dan worden de elementen ‘vorige pagina’ respectievelijk ‘volgende pagina’ niet weergegeven en zal de uitlijning van de items plotseling veranderen. In deze notitie worden twee pragmatische oplossingen voorgesteld.
Het Gutenberg paginering-blok kan in een Query loop-block worden opgenomen en bevat zelf drie blokken: een blok dat een link toont naar de vorige pagina, een blok met een link naar de volgende pagina en een blok met pagina nummers. De blokken ‘vorige’ en ‘volgende’ kunnen een pijl tonen, een tekst of allebei.
Een voor de hand liggende weergave hiervan is om de pijl naar links uit te lijnen met de linkermarge, de pijl naar rechts met de rechtermarge en de paginanummers er in het midden tussen te zetten. Om dat te bereiken kies je in de taakbalk van het paginering-blok voor ‘Wijzig uitvulling van items’ en vervolgens voor ‘Afstand tussen items’.
Dit werkt, maar deze uitlijning houdt geen stand op de eerste en laatste pagina van de getoonde berichten. Dit komt doordat het blok ‘Vorige pagina’ niet als een leeg item wordt getoond als er geen vorige pagina is, maar in het geheel niet. Dan heeft het paginering-blok opeens nog maar twee items en die worden dan anders uitgevuld: de paginanummer verhuizen naar de linkermarge.
Ikzelf vind het in de meeste gevallen wenselijk dat die navigatie-elementen op een vaste plaats blijven staan en niet verspringen als je bladert.
Een eerste gedachte om dit te bereiken was om de drie sub-blokken van het paginering-blok los te gebruiken. Ik maakte een kolom-blok met drie kolommen met de bedoeling in iedere kolom een van de paginering-elementen te plaatsen. Op die manier zou, bij afwezigheid van een van de paginering-elementen, de layout in stand blijven want de kolommen blijven op hun plaats.
Ik nam daarbij aan dat deze sub-blokken zelfstandig kunnen functioneren doordat ze hun context ontvangen van het Query-loop block. Helaas bleek het niet mogelijk de paginering-onderdelen los te gebruiken.
In het block-metabestand (block.json) van het query-pagination-previous blok is te zien dat alleen het pagination blok is toegestaan als moederblok:
Je kunt het Vorige-pagina blok niet het paginering-blok uit slepen naar bijvoorbeeld een leeg kolom-blok of naar een ander blok om de positie te fixeren.
Oplossing 1
Je kunt sub-blokken dus niet van het paginering-blok naar een ander blok slepen, maar je kunt wel zo’n sub-blok verwijderen. Daarnaast kun je meerdere paginering-blokken per pagina plaatsen. Wat je kunt doen is dus drie paginering-blokken met daarin telkens alleen maar één van de drie sub-blokken. Dus een paginering blok waarin ‘paginanummers’ en ‘volgende pagina’ zijn verwijderd. Een paginering-blok waarin alleen ‘volgende pagina’ is blijven staan en een paginering-blok met alleen de pagina-nummers. Deze drie pagineringblokken kun je vervolgens in een rij plaatsen en op de gewenste manier uitvullen.
Ik heb niet onderzocht wat de server-belasting van deze oplossing is, waarschijnlijk niet eens zo hoog want de paginering-blokken zijn onderdeel van één en hetzelfde query loop-block. Er zal niet telkens een nieuwe query worden gedaan. Het is geen elegante oplossing, maar het werkt.
Oplossing 2
De blokken ‘vorige pagina’ en ‘volgende pagina’ leveren bij de render-functie van WordPress lege inhoud op als ze niet van toepassing zijn. Maar na de render-functie wordt alle resulterende inhoud wel door een aantal filters gehaald, óók als die inhoud leeg is.
Een filter toevoegen aan het render-resultaat van de sub-blokken maakt het mogelijk om in plaats van lege inhoud, een leeg, plaatsvervangend element aan het paginering-blok toe te voegen. Voor het gemak kan dan wat inline-style worden toegevoegd om de marges in overeenstemming met het oorspronkelijk blok te houden. Dit kan natuurlijk ook bereikt worden door wat class-namen en css toe te voegen *
Aangezien het hier om een vorm-aanpassing gaat, ligt het voor de hand deze filters aan het thema toe te voegen, dus in functions.php of bestand dat daardoor wordt aangeroepen.
Conclusie
Twee pragmatische oplossingen: een waarbij geen code hoeft te worden toegevoegd en een die wat minder belastend is en die de opmaak in de blok-editor wat rustiger houdt.
* Je kunt copilot hierom vragen maar dat heb ik ook al gedaan. Ik kreeg er wat toegankelijkheids verbetering bij cadeau: