Ich hab ja in letzter Zeit mal sporadisch mit dem wunderbaren Wordpress zu tun gehabt und konnte mich eine Weile damit beschäftigen. Viele Sachen gefallen mir nicht, unter anderem die Tatsache das Wordpress URLs immer komplett haben muss. Wie soll ich bitte lokal entwickeln wenn alle URLs komplett sind?
Dem lässt sich zum Glück relativ einfach abhelfen. Man legt sich einfach eine wp-config.php Datei an die man nur benutzt wenn man lokal entwickelt. Das kann man zum Beispiel am username im System festmachen:
$envUsername = strtolower(get_current_user());
$envConfigFilename = dirname(__FILE__).'/wp-config-'.$envUsername.'.php';
if (file_exists($envConfigFilename)) {
require $envConfigFilename;
}
Und dann kann man in der lokalen Konfigurations-Datei einfach den Wordpress-Installationspfad überschreiben:
define('WP_HOME','http://'.$_SERVER['HTTP_HOST'].'/wordpress/path/');
define('WP_SITEURL', WP_HOME);
So hat man zumindest damit keinen Stress mehr. Wie man die Bilder lokal verlinkt weiss ich allerdings auch noch nicht …
Wie gestern schon beschrieben kann man super ab (Apache Bench) die Performance seiner Applikationen im Web testen. Durch Zufall hab ich in meiner Ports Sammlung noch ein anderes Programm gefunden das auch sehr vielversprechend aussieht: siege.
Dort kann man auch mehrere URLs testen, einen User simulieren und noch viel mehr. Damit habe ich allerdings noch nicht so viel Erfahrung. Hab aber gleich mal meine App getestet:
siege -c 100 -t 10s http://localhost/myProject/
Die Ausgabe sieht fast so aus wie beim ab:
Transactions: 545 hits
Availability: 100.00 %
Elapsed time: 17.85 secs
Data transferred: 1.33 MB
Response time: 1.02 secs
Transaction rate: 30.53 trans/sec
Throughput: 0.07 MB/sec
Concurrency: 31.01
Successful transactions: 604
Failed transactions: 0
Longest transaction: 3.31
Shortest transaction: 0.03
Mit einem Config File kann man aber auch noch mehrere Urls abfragen und so ein realistischeres Ergebnis erzielen. Mehr dazu steht in der Docu von Siege oder in Tutorials die man so im Netz findet: Regression testing with Siege.
Ich denke mal das solche Tools auch eine wunderbare Möglichkeit sind verschiedene Hoster zu testen oder einem Kunden zu zeigen wie Vorteilhaft eine Optimierung seiner Applikation wäre oder einfach nur welchen extremen Effekt der Einbau eines Caches hat.
So, wie gestern schon angekündigt, kann ich jetzt endlich code Zeilen posten! Was für ein Spass! So, jetzt hier das aller erste mal richtiger Code. Einfach und nützlich.
Wer auf -NIX Systemen (oder auch OSX) arbeitet kann das hier vielleicht gebrauchten:
# configuration
projectName=$1
projectsDir=projects/
deployDir=download/
# display help message, when -h or --help passed
if (test "$projectName" = "-h" || test "$projectName" = "--help") then
echo "this is the help message for your help - nice huh?"
echo "this script was created for deploying a project"
echo "example usage:"
echo " sh deploy.sh ephReggy -- deploys the ephReggy project"
echo " sh deploy.sh all -- deploys all projects found in the $deployDir"
echo
exit
fi
# no param given, no projectname passed
if (test "$projectName" = '') then
echo "empty project name, please specify a project name"
exit
fi
# deploy all projects? hu?
if (test "$projectName" = "all") then
echo "okay, deploying all projects? Sure? (Y/N) c"
read deployAll
if (test ! "$deployAll" = 'Y') then
echo "okay, no deployment done. see ya!"
exit
fi
projectsToDeploy=( ephReggy ephScrobblrRead ephVat ephWatts )
# deploy only project that was passed
else
projectsToDeploy=( $projectName )
fi
# create deploy directory
if (test ! -d "$deployDir") then
echo "creating deploy Directory $deploy ..."
mkdir "$deployDir"
fi
# start deploying projects
for projectName in ${projectsToDeploy[@]}
do
projectDir=$projectName
# test existence of project folder
projectDir="$projectsDir$projectName"
if (test ! -d "$projectDir") then
echo "project directory for $projectName was not found: $projectDir";
exit
fi
# start deploying
# add exclude if found
if (test -f "deploy_exclude.lst") then
excludeStatement="-x@deploy_exclude.lst"
fi
projectZipFileName="$deployDir$projectName.zip"
echo "deploying $projectName to $projectZipFileName c"
zip -rq $excludeStatement $projectZipFileName $projectDir/*
echo "done!"
done
echo "Everything done, now quiting. See Ya!"
Im groben nimmt dieses Shell-Script einen Ordner den man per Paramter angibt und im $projectsDir liegen muss, zippt diesen und platziert das Zip in $deployDir. Sehr hilfreich wenn man mehrere Projekte, also Ordner zippen möchte und keine Lust hat alles per Hand über den Finder zu machen - Anklicken, zippen, verschieben entfällt.
Man gibt einfach so was in die Console ein:
$ sh deploy.sh all
"deployed" alle Projekte in dem Projekte Ordner die in dem $projectsToDeploy Array angegeben sind. (wie auf dem Screen weiter unten gezeigt)
Einzelne Projekte, oder halt Ordner kann man folgendem Befehl "deployen":
$ sh deploy ephReggy
Wenn man es total funky will kann man auch sog. Escape-Sequenzen benutzen um die Ausgabe des Scripts farbig zu gestalten. Hier ein Screenshot, der zugleich farbige Ausgabe zeigt, als auch die Funktionsweise:
Joar, vielleicht etwas wirr, aber probiert das mal aus, das bringts voll!
Denkbar ist das man das ausbaut, das Script die Dateien auch auf einen Server hochlädt, Teile des Quellcodes löscht, die man nicht drin haben will (offline Code, Testing-Code, Kommentare usw.) und was weiss ich.
Okay, jetzt ist es sogar möglich alle cookies zu löschen, n filter einzustellen und die Anzahl der Einträge pro seite zu speichern. Auf der linken Seite unter Config.
Jetzt bin ich glaub ich erstmal durch, mit dem Kram den ich noch einfügen und ändern wollte.