Skip to:
Content

BuddyPress.org

Opened 11 years ago

Closed 11 years ago

Last modified 4 years ago

#33 closed defect (bug) (fixed)

Front end profile links broken when using sub-directories

Reported by: sollaires Owned by:
Milestone: Priority: major
Severity: Version:
Component: Keywords: profile, subdirectories
Cc:

Description

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)

Change History (5)

#1 @sollaires
11 years ago

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>



#2 @sollaires
11 years ago

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.

#3 @apeatling
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#4 @(none)
10 years ago

  • Milestone Extended Profiles - v0.3 deleted

Milestone Extended Profiles - v0.3 deleted

This ticket was mentioned in Slack in #buddypress by imath. View the logs.


4 years ago

Note: See TracTickets for help on using tickets.