since wordpress 2.8.4 (maybe .3) i'm getting a strange error. i just updated with web-app config and installed a new instance. after a restarted apache only the first accessed instance is provided from each install. this is probably not an apache issue, i put an index.html file in each htdocs and it works fine. with wordpress i can reproduce after each apace restart that for all 4 installations the first accessed is shown. Reproducible: Always Steps to Reproduce: 1.install wordpress > 2.8.4 with vhost flag 2.install two or more installations with webapp-config 3. restart apache Actual Results: only the first acccessed installation is provided Expected Results: any installation should be provided this is very strange. especially i cannot run more than one instance at the moment.
do you have eaccelerator, xcache or some other opcode cacher enabled?
i think i've no eaccelerator, xcache or some other opcode cacher enabled, see info below. i fixed the problem with a fresh and direct tar.gz install from the wordpress homepage without using webapp-config -I ... therefore i guess it is no database issue nor an apache issue. i do not really know how this webapp-config system works, but i guess there is sth. wrong with the hardlinks. i have still 2 wordpress installations offline (very old fun projects) i can do some testing. but i don't really know what tot do. Installed versions: 5.2.11(5)(15:08:01 12.10.2009)(apache2 berkdb bzip2 cgi cli crypt ctype curl debug dird-path doc force-cgi-redirect gdbm gmp imap ipv6 mysql mysqli ncurses nls pcre posix readline reflection session spell spl sqlite ssl tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter xsl zip zlib -adabas -bcmath -birdstep -calendar -cdb -cjk -concurrentmodphp -curlwrappers -db2 -dbase -dbmaker -empress -empress-bcs -esoob -exif -fastbuild -fdftk -filter -firebird -flatfile -frontbase -ftp -gd -gd-external -hash -iconv -inifile -interbase -iodbc -java-external -json -kerberos -kolab -ldap -ldap-sasl -libedit -mcve -mhash -msql -mssql -oci8 -oci8-instant-client -odbc -pcntl -pdo -pic -postgres -qdbm -recode -sapdb -sharedext -sharedmem -simplexml -snmp -soap -sockets -solid -suhosin -sybase -sybase-ct -sysvipc -threads -tidy -wddx -xpm -yaz)
I would like to confirm this (currently with 3.4.2). It can be worked around by forcing webapp-config to copy files instead of hardlinking them all. I suspect that making a few files server-owned instead of virtual should solve the problem, namely the potential entry points where dirname(__FILE__) is used (eg wp-blog-header.php), so that the result of this function call resolves to the actual wordpress instance instead of the link target.
See bug #481420 for more info (oddly marked as fixed when the issue is still current). I now do all my installs with -u, -g and config-owned vfiles and vdirs, and using mpm-itk.
