Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 291900 - www-apps/wordpress USE=vhosts does redirects only to the first accessed install
Summary: www-apps/wordpress USE=vhosts does redirects only to the first accessed install
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Web Application Packages Maintainers
Depends on:
Reported: 2009-11-04 19:41 UTC by gregor fellenz
Modified: 2014-09-24 10:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---
tampakrap: Bugday+


Note You need to log in before you can comment on or make changes to this bug.
Description gregor fellenz 2009-11-04 19:41:11 UTC
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.
Comment 1 Benedikt Böhm (RETIRED) gentoo-dev 2009-11-15 11:48:48 UTC
do you have eaccelerator, xcache or some other opcode cacher enabled?
Comment 2 gregor fellenz 2009-11-15 15:19:36 UTC
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)   

Comment 3 Romain Riviere 2012-12-18 17:27:12 UTC
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.
Comment 4 Romain Riviere 2014-04-30 14:28:22 UTC
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.