Summary: | www-apps/wordpress USE=vhosts does redirects only to the first accessed install | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | gregor fellenz <gf_public> |
Component: | Current packages | Assignee: | Gentoo Web Application Packages Maintainers <web-apps> |
Status: | CONFIRMED --- | ||
Severity: | major | CC: | gentoo |
Priority: | High | Flags: | tampakrap:
Bugday+
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=481420 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
gregor fellenz
2009-11-04 19:41:11 UTC
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. |