some people like me have the problem of having several wordpress installations at the same time; people like me and some others i know. i have one wordpress running for this blog, one for my math blog, one for a hidden, password protected project which might or might not ever see the light of the world, and anther one for another music related project showing up soon.
whenever a new wordpress version comes out, a question bugs me: how to update all of these installations without doing it manually for every one? of course, there’s the automatic update, but i don’t really trust it. and i don’t have an ftp server installed, so i’m not sure if it would work at all. so i need another solution.
a first idea was to use symbolic links. have one wordpress installation in a directory outside the web tree, and link these files into all wordpress directories in the web tree, so for updating i only need to change one directory, and i only have to touch the others when the configuration file has to be changed.
unfortunately, this doesn’t work, thanks to php and wordpress. wordpress determines the path to the config file by the path names of the files, and since the files are symbolic links, the paths of the files pointed to are used. but in that directory, no config file is available, and wordpress fails. too bad.
now i got another idea. namely, have a wordpress directory outside the web tree, and put it into subversion. then, in all other wordpress directories, drop in the files using subversion, except the configuration file, uploads, latex caches, etc. so to update an installation, i have to go into its directory and type svn up. that’s it. there’s one thing left to do: namely hide the .svn directories from the web server. i didn’t found the perfect method yet, but adding this to the apache configuration makes them forbidden:
<DirectoryMatch “^/.*/\.svn/”>
Order deny,allow
Deny from all
</DirectoryMatch>
then every access to something in an .svn directory results in an access denied error:
Forbidden
You don’t have permission to access /.svn/ on this server.
comments.
Löst auf jeden Fall dein Problem…
Aber das fehlende Design deines Blogs heute hat nichts mit dieser Umstellungen zu tun, oder?
Anscheinend mag mein Firefox das HTTPS (bzw. das Zertifikat dafür) in der folgenden Zeile nicht:
link rel=”stylesheet” href=”https://spielwiese.fontein.de/wp-content/plugins/lazylatex.css” type=”text/css”
Er benachrichtigt mich aber auch nicht darüber. Nur wenn ich die CSS-Datei direkt per HTTPS aufrufe, wird mir mitgeteilt, dass er dem Aussteller des Zertifikats nicht traut. Wenn ich es dennoch akzeptiere ist wieder alles okay.
das hat was damit zu tun, dass ich im style die hard-kodierte url entfernt habe und durch eine von wordpress generierte ersetzt habe. dabei bin ich auf ein problem gestossen, dass wordpress die url aus einer konstanten generiert, die definiert wird bevor z.b. plugins geladen werden. (diese konstanten kann man in php nicht umdefinieren.) und aus irgendeinem grund wird ein https davor gesetzt anstelle eines https. gestern nacht hatte ich keine lust mehr das noch zu beheben irgendwie, also hatte ich es auf heute verschoben… dass es offenbar zu problemen führt wegen dem zertifikat habe ich nicht bedacht. ich werde es mir gleich mal anschauen… manchmal ist wordpress echt nervig ;-)
ok, es geht jetzt. hab zwei filter eingebaut (für content_url und plugin_url). wo auch immer dieses problem herkommt…
Hihi, nicht immer ist ein Genitiv-S sinnvoll… ;) SCNR
Das Firefox damit so schlecht klar kommt, könnte man aber fast als Bug melden. (Auch das aus dem Quelltext-Fenster man zwar eine Zertifikatsuntersuchung angeboten bekommt, jedoch der Button nicht funktioniert.)
LOL, das ist mir gar nicht aufgefallen beim schreiben :D
und die ssl-zertifikat-unterstützung beim firefox ist wirklich nicht sehr gut. ich finde auch, dass sie eher schlechter geworden ist in den letzten jahren als besser…