Symlinked plugin url issues

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

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]

WooCommerce installeren via Composer

Door GrimaceODespair op zondag 7 december 2014 10:36 - Reageren is niet meer mogelijk
Categorie: -, Views: 1.308

Eentje voor de naslagwerken: het installeren van WooCommerce via Composer. Let op: de plugin wordt niet automatisch geactiveerd. Daarvoor zou eventueel nog een WP-CLI-script toegevoegd kunnen worden, maar dat valt momenteel buiten de scope ;)

composer.json

JSON:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "woothemes/woocommerce",
        "version": "2.2.8",
        "type": "wordpress-plugin",
        "source": {
          "type": "git",
          "url": "https://github.com/woothemes/woocommerce",
          "reference": "2.2.8"
        }
      }
    }
  ],
  "require": {
    "woothemes/woocommerce": "2.2.*"
  }
}

Wordpress en private forks

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

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

In-band bulk import met SqlServer

Door GrimaceODespair op maandag 16 december 2013 01:53 - Reacties (4)
CategorieŽn: C#, SqlServer, Views: 2.725

Telkens als ik grote hoeveelheden data moet importeren in SQLServer, zoek ik het even opnieuw op, en kom ik er ook weer telkens opnieuw achter dat dat kan met BCP (command line) of met BULK INSERT (SQL commando). En beide opties hebben hetzelfde nadeel: het leent zich niet voor een dynamisch systeem, omdat je ( A ) het schema van de tabel in een format file nodig hebt en ( B ) de data in een bestand moet gooien. Bovendien duurt het altijd weer even voordat je de juiste configuratie-opties op de commandline hebt achterhaald.

Aangezien ik me niet zomaar kan neerleggen bij dergelijke beperkingen, vroeg ik me af of het misschien mogelijk was om de fysieke bestanden te vervangen door named pipes. Dat zou namelijk mogelijkheden openen om dergelijk imports niet "out-of-band" te doen, maar rechtstreeks in C#-code.

Een kleine speurtocht later bleek het antwoord op die vraag gedeeltelijk "ja". Dat antwoord was voldoende voor een proof of concept dat uiteindelijk resulteerde in een NuGet package.

Lees verder »

Performance counters in C#

Door GrimaceODespair op maandag 14 oktober 2013 02:14 - Reacties (6)
CategorieŽn: C#, Windows, Views: 4.225

Windows performance counters zijn een (misschien vooral door mezelf) erg misbegrepen topic en goede, begrijpbare codevoorbeelden zijn moeilijk te vinden. Daarom deze kleine utility class, waarmee het mogelijk is op een intuÔtieve manier enkele standaardmetingen te verrichten.

De class kan na creatie als volgt aangeroepen worden:

code:
1
2
3
4
using (perfCounters.Monitor())
{
  // do some task
}



Van de code binnen de using wordt dan automatisch bijgehouden hoe vaak ze wordt aangeroepen, hoe vaak dat gebeurt per seconde en hoe lang de code gemiddeld duurt.

Lees verder »