Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 7 years ago

#32285 closed enhancement (maybelater)

define( 'WP_ALLOW_MULTISITE', true );

Reported by: colomet's profile colomet Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords:
Focuses: multisite Cc:

Description

in the default installation of wp define( 'WP_ALLOW_MULTISITE', true ); are almost at the end of the wp-config, but later once you active multisite, you must paste the new lines of code before / That's all, stop editing! Happy blogging. /

i think it will be easy to undestand if the users we just need to write over the wp define( 'WP_ALLOW_MULTISITE', true ); like we did in early versions of wp.

Because i paste over wp define( 'WP_ALLOW_MULTISITE', true ); and it didn´t work, and once i move the lines before / That's all, stop editing! Happy blogging. /, it work.

my first impresion is to go and write over were i can read multisite

thanks

Change History (18)

#1 @SergeyBiryukov
9 years ago

in the default installation of wp define( 'WP_ALLOW_MULTISITE', true ); are almost at the end of the wp-config

There is no define( 'WP_ALLOW_MULTISITE', true ); in the default wp-config-sample.php file.

Everything you insert should come before the /* That's all, stop editing! Happy blogging. */ comment.

#2 @colomet
9 years ago

yes, but i work with plesk. In plesk, by default i have it.

i didn´t know it just a plesk issue

Last edited 9 years ago by colomet (previous) (diff)

#3 follow-up: @voldemortensen
9 years ago

I do think this brings up a question to be asked. Many config files has lines that say something like 'Uncomment this line if blah blah blah'. Would it be beneficial/effective to just add a line?

#define( 'WP_ALLOW_MULTISITE', true); #Uncomment this line if you are going to use multisite.

#4 in reply to: ↑ 3 ; follow-up: @nacin
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Replying to voldemortensen:

I do think this brings up a question to be asked. Many config files has lines that say something like 'Uncomment this line if blah blah blah'. Would it be beneficial/effective to just add a line?

This constant exists as a deliberate hurdle to multisite. We could just as easily eliminate it or make it so you don't need to go into wp-config.php (twice) to get multisite up and running. But multisite remains, even after these many years, not for the faint of heart. So these barriers were purposely put into place as part of the 3.0 work. As the work led by @jeremyfelt and others continues, we will ideally relax this in the future.

#5 in reply to: ↑ 4 @voldemortensen
9 years ago

Replying to nacin:

This constant exists as a deliberate hurdle to multisite. We could just as easily eliminate it or make it so you don't need to go into wp-config.php (twice) to get multisite up and running. But multisite remains, even after these many years, not for the faint of heart. So these barriers were purposely put into place as part of the 3.0 work. As the work led by @jeremyfelt and others continues, we will ideally relax this in the future.

So I'm just ahead of my time :) I'll take it.

On a serious note, if our overall efforts are to make multisite more available, it makes sense to me to make this small step now. Lowering the barrier gradually as we improve gradually will get more people into using multisite, which in turn creates greater need to improve multisite.

In my mind I only see a few situations caused by this.

  1. A user goes through the normal install process and never actually goes into wp-config.php.
  2. A user quickly goes through the minimum changes required in wp-config.php to make a site work, i.e. database info.
  3. A more curious user reads through wp-config.php to see what's there, but doesn't know what multisite is so they move on.
  4. Much like 3, but curious enough to look into what multisite is.
  5. The user who already knows what multisite is and know whether or not they are going to use it.

From my experience, cases 1 and 2 are the most common and this change wouldn't really effect them. Case 3 wouldn't really be effected because they'd just move on, but they will have at least heard of multisite. This change would only make case 5's job easier.

So case 4 is the only one effected. Again from my experience (which is, of course, different from everyone else), case for is among the least common of the 5 cases. I see this as a way to get multisite a little more publicity without putting an option in the dashboard or in the install process.

#6 @voldemortensen
9 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

#7 @nacin
9 years ago

I'll let Jeremy provide his thoughts, I just wanted to provide some background. The intention of the barrier is to make it hard to set up multisite. The thought is if you can't figure out how to add a constant and modify config files [and generally be somewhat familiar with code] then you shouldn't be running multisite.

#8 @voldemortensen
9 years ago

The background was definitely enlightening and I agree with the logic. I just think that case 4 would be the kind of user that could easily add a constant, but would otherwise just be ignorant to the fact that multisite exists.

#9 @SergeyBiryukov
9 years ago

  • Milestone set to Awaiting Review

#10 @colomet
9 years ago

i think is better not to give easy acces to multisite. In my case, i use multisite in some sites, because for my purpose it give me more flexibility than a normal site ( i work with languages). but in the case of the installations from Plesk, it would have to be in a better place, or with comments. Its easy to forget the correct place, and copy and paste above that line.

Look how is the wp-config.php of Plesk:

define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define('WPLANG',       'en_US');

define( 'WP_ALLOW_MULTISITE', true );

define ('FS_METHOD', 'direct');

//--- disable auto upgrade
define( 'AUTOMATIC_UPDATER_DISABLED', true );
?>
Last edited 9 years ago by colomet (previous) (diff)

#11 follow-up: @voldemortensen
9 years ago

If there was a line in wp-config.php by default, it would be in the correct place. There would be no need to move the line, you'd just have to uncomment it.

#12 in reply to: ↑ 11 @colomet
9 years ago

Replying to voldemortensen:

If there was a line in wp-config.php by default, it would be in the correct place. There would be no need to move the line, you'd just have to uncomment it.

Really?, i just did a new multisite installation just for check , and look what i get

define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define('WPLANG',       'en_US');

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'prueba1.lvps84-39-103-206.mammuts-servidor.es');
define('PATH_CURRENT_SITE', '/wordpress/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);


define ('FS_METHOD', 'direct');

//--- disable auto upgrade
define( 'AUTOMATIC_UPDATER_DISABLED', true );

http://lvps84-39-103-206.mammuts-servidor.es/files/public-docs/Captura%20de%20pantalla%202015-05-08%20a%20las%2018.01.14.png

maybe it´s the correct place, but it´s easy to make a mess

Last edited 9 years ago by colomet (previous) (diff)

#13 follow-up: @colomet
9 years ago

But if you put in the correct place, it wil work. But if you do not remove

define( 'WP_ALLOW_MULTISITE', true );

(is not easy to find a place were they tell you: remove that line)

i get that
http://lvps84-39-103-206.mammuts-servidor.es/files/public-docs/Captura%20de%20pantalla%202015-05-08%20a%20las%2018.10.45.png

#14 in reply to: ↑ 13 @JPry
9 years ago

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

Replying to colomet:

But if you put in the correct place, it wil work. But if you do not remove

define( 'WP_ALLOW_MULTISITE', true );

(is not easy to find a place were they tell you: remove that line)

I think what @voldemortensen is trying to say is that WordPress does not currently come with the WP_ALLOW_MULTISITE constant anywhere in the wp-config.php file, commented out or not. This snippet is the end of the provided wp-config-sample.php file:

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

You have mentioned that you're using Plesk to install WordPress. It would be better to bring up this issue with them, because there is nothing to fix in the wp-config-sample.php.

#15 @voldemortensen
9 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Thanks for the reponse @JPry, but there is still more discussion related to adding the commented line in wp-config-sample.php.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


9 years ago

#17 @jeremyfelt
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed
  • Version 4.2.2 deleted

Thanks for the ticket @colomet!

I share @nacin's general sentiment above. It would be great if multisite was in a state where enabling it could be made easier. I don't think we're ready for that yet.

I guess my primary reason right now is this. The workflows existing in multisite for most tasks are still being established, even after 5 years of use. Selfishly, every user installing multisite in its current form makes it a bit more difficult to make sweeping changes in the next few years. Every time these constants are used makes it less likely we'll be able to effectively deprecate them one day.

The lack of a commented constant acts somewhat as an unspoken barrier to those who like the struggle. :)

I'd rather remove the need for the constant entirely once we're in a happier place. That's the target to shoot for.

I'm going to close this as maybelater to keep hope alive. #13921, effectively a duplicate ticket, was closed as wontfix at the time. Please feel free to continue the conversation here on the closed ticket or join us in the #core-multisite channel on Slack.

#18 @johnbillion
7 years ago

#40517 was marked as a duplicate.

Note: See TracTickets for help on using tickets.