Front end profile links broken when using sub-directories

[sollaires]

Revision 204, using sub-directories

Steps I can take to reproduce:

• Log in on the front end (a profile page)
• Click the profile link
• Click Edit Profile

Many navigation links now have an incorrect extra /profile/ portion to them. For example, the 'Change Avatar' link now points to '/user/profile/profile/change-avatar'. Clicking on any of them basically goes back to the main profile page and continues adding directories to the active URL.

This problem happens in a number of other places on the front end as well. Going into blogs or messages can quickly corrupt the URL and most links end up going to the wrong place.

Looks like an issue with relative paths that may or may not happen with sub-domains. (This all seemed to work on testdrivewpmu.com)

[sollaires]

HTML source of the rendered BP navigation:

<li>

<a id="profile" href="profile">Profile</a>

</li>
<li>

<a id="blog" href="​http://website.com/dhendler/blog">Blog</a>

</li>
<li class="current">

<a id="messages" href="messages/">Messages</a>

</li>
<li>

<a id="wp-logout" href="​http://website.com/wp-login.php?action=logout">Log Out</a>

</li>

[sollaires]

This problem actually is an issue with plugin load order. I tracked it down and found that on my server, the xprofile plugin was being loaded before bp-core and so the $loggedin_domain and $current_domain were not being set when the profile links were being setup.

This stems from how WPMU loads plugins - it simply opens up the mu-plugins directory using readdir() and the behavior is as follows (from ​http://us3.php.net/readdir)

"Returns the filename of the next file from the directory. The filenames are returned in the order in which they are stored by the filesystem."

Making all the non-core plugins have to do a require_once( 'bp-core.php' ) should fix this problem.

[apeatling]

Thanks for debugging this. A core include_once has been added to the top of each plugin.

[(none)]

Milestone Extended Profiles - v0.3 deleted