Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

#3964 closed defect (bug) (fixed)

Two BP top-level Dashboard menus appearing before install wizard is run

Reported by: boonebgorges's profile boonebgorges Owned by:
Milestone: 1.6 Priority: normal
Severity: normal Version:
Component: Administration Keywords:
Cc: johnjamesjacoby

Description

I believe one is created by the installation wizard, while the other is being created by plugin backpat.

Change History (7)

#1 @boonebgorges
12 years ago

Probably it makes the most sense to suppress the plugin backpat top-level menu, since we don't really want people accessing BP-dependent content before BP has been installed.

#2 @boonebgorges
12 years ago

Correction: This only happens when upgrading from 1.5.x.

#3 @boonebgorges
12 years ago

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

(In [5660]) Do a better job of detecting when an upgrade is taking place, so as not to load multiple instances of the BuddyPress top-level menu before the installation wizard is run.
Fixes #3964

#4 @boonebgorges
12 years ago

  • Cc johnjamesjacoby added
  • Resolution fixed deleted
  • Status changed from closed to reopened

OK, it turns out that that [5660] actually breaks more than it fixes. The problem has to do with the fact that we don't have a reliable way to check whether we're in an upgrade/installation situation. Before I sink time into straightening it out, I would like to understand our version/db numbering scheme. jjj, as you introduced some of the new scheme in the 1.6 trunk (I'm thinking in particular about _bp_db_version, which you are storing with update_option() instead of update_site_option()), I was hoping you could explain definitively how you envision it working. Where are we getting the DB version number from? And how does this relate to our old way of setting bp-db-version? Why are we doing it on a site-specific, rather than networkwide, basis?

In the meantime, I'm going to revert my recent change.

#5 @boonebgorges
12 years ago

(In [5661]) Reverts [5660]. See #3964.

#6 @johnjamesjacoby
12 years ago

The reason this is stored per site rather than per network is to avoid needing to move settings around all the time between sites and networks. It also has to do with multiblog, as it's possible that one site can be updated when others are not. It's a mess. If the db version isn't stored per site, it's possible that sites will appear up-to-date when they are not. Storing it at the site level is the only way to ensure the accurate bits are (or need to be) updated.

#7 @johnjamesjacoby
12 years ago

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

(In [5749]) First pass at refactoring update/install wizard to remove code duplication:

  • Rename and move admin images, css, and js into bp-core/admin/ folders
  • Load the wizard from inside BP_Admin instead of selectively alone, so that basic functions are available
  • Properly enqueue admin scripts
  • Remove duplicated _update_ functions in bp-core-updater.php
  • Remove weird redirect hack as it's no longer needed
  • Remove purpose built functions that are no longer needed
  • See #4005.
  • Indirectly fixes #3964.
Note: See TracTickets for help on using tickets.