Symlinked plugin url issues

Door GrimaceODespair op maandag 7 december 2015 03:40 - Reageren is niet meer mogelijk
CategorieŽn: Windows, WordPress, Views: 1.101

Ik had het onzalige idee opgevat om tijdens het ontwikkelen van een WordPress-plugin van OS te switchen. Windows 7 naar Windows 10 om precies te zijn.

Ik ging voor een clean install op een verse SSD. Het nieuwe systeem was eigenlijk in geen tijd up and running, inclusief de nodige dev tools (IIS7, Sql Server, Visual Studio, Notepad++, TortoiseGit, ...). Big up voor MS op dat vlak.

Zelfs de migratie van mijn WordPress-dev-omgeving was een fluitje van een cent. Op 1 struikelblok na: mijn wordpress-plugin. De plugins_url-functie van WordPress bleek namelijk koppig dienst te weigeren. In mijn module verschenen hierdoor urls van het type:


code:
1
http://localhost/folder/c:\/dev\/myplugin



Na het nodige debugwerk, kwam ik erachter dat realpath de boosdoener was, of beter, het effect van ťťn van mijn symlinks op realpath.

De oplossing was gelukkig eenvoudig: gewoon symlinken naar een pad met een hoofdletter voor de drive:


code:
1
2
3
4
5
6
7
8
9
cd C:/dev/wordpress/wp-content/plugins

dir myplugin*
07/12/1015 03:22 <SYMLINKD> myplugin [c:/dev/myplugin]
rmdir myplugin

mklink /d myplugin C:/dev/myplugin
dir myplugin*
07/12/1015 03:22 <SYMLINKD> myplugin [C:/dev/myplugin]

Wordpress en private forks

Door GrimaceODespair op donderdag 27 november 2014 00:06 - Reacties (3)
CategorieŽn: PHP, WordPress, Views: 2.265

Als je vaker WordPress opzet, loont het de moeite om te kijken naar een geautomatiseerde oplossing voor een standaardinstallatie. Enter composer. Composer is de apt-get, de NuGet, de npm, de rpm, ... van PHP. Met andere woorden: het zou de bedoeling moeten zijn om enerzijds gemakkelijk packages te maken, die je anderzijds even gemakkelijk kunt consumeren.

Eťn van de problemen waar je met package managers wel eens tegenaanloopt bij het ontwikkelen, is dat je graag een eigen aangepaste versie van een package zou uitproberen, alvorens je het in het wild loslaat. Het goede nieuws is dat Composer dit ondersteunt, het slechte nieuws dat dit redelijk ondergedocumenteerd is.

De meeste handleidingen gaan ervanuit dat je een eigen Satis or Toran repo moet opzetten. Het kan echter ook zonder.

Voor mijn eigen welzijn en om te voorkomen dat ik dit over een aantal maanden opnieuw moet opzoeken, volgt hier hoe je te werk moet gaan.
packages.json
Maak een custom repository aan (C:\Development\packages.json) met maar 1 package, bv:


XML:
1
2
3
4
5
6
7
8
9
10
11
{
    "package": {
        "name": "myfork/bedrock",
        "version": "1.2.7",
        "source": {
          "url": "C:/Development/MyFork/bedrock",
          "type": "git",
          "reference": "master"
        }
    }
}



Merk op dat dit geen reguliere packages.json is, aangezien er "package" (enkelvoud) in plaats van "packages" staat. Dit is een ongedocumenteerd feature van Composer.

In deze repo kan je naar hartelust je eigen rotzooi committen zonder het openbaar te maken. Ik weet niet zeker of composer ook je openstaande changes meeneemt, dus het kan zijn dat je wel alles lokaal moet committen.
fork
Maak je eigen lokale fork van de repo die je wilt gebruiken voor je create-project. In mijn geval is dat roots/bedrock, een coole Bootstrap-install van WordPress. Mijn issue met de standaardinstallatie, was de locatie van de web-root, die ik per se "public_html" wilde laten heten ipv "web". In mijn eigen fork kon ik dat gemakkelijk aanpassen, en via onderstaand commando deze adaptatie installeren.


code:
1
composer create-project MyFork/bedrock --repository-url C:\Development\packages.json Web



Bovenstaand commando installeert dan WordPress in de Web folder, relatief tov je huidige pad.

Geen rocket science, maar als je niet vertrouwd bent met Composer en Satis, kan bovenstaande samenvatting je aardig wat tijd schelen.

Geen dank :P