Support » Alpha/Beta/RC » vhost to SUBDOMAIN_install not clear

  • Resolved Paul Bearne

    (@pbearne)


    runing the new the beta in debug i can see a new define SUBDOMAIN_INSTALL to replace VHOST can we add instruction for this change if not offer to do it for you as part of the upgrade

    Paul

Viewing 7 replies - 1 through 7 (of 7 total)
  • As far as I know, this is for people who upgraded from wordpressMU only. It is not required for new installs, or for network installs that were enabled in 3.0 and above.

    It does NOT replace the VHOST define. You do not need to change anything.

    The goal with SUBDOMAIN_INSTALL was to have a boolean replacement for VHOST, which stored its value as ‘on’ and ‘off’ for reasons passing understanding.

    If you have VHOST defined as ‘on’ or ‘off’, you can replace this with SUBDOMAIN_INSTALL (defined as true or false) in 3.1.

    In 3.0, when working on an upgraded MU install, this change would break the install, and you’d have to add VHOST back. (Ron and I both missed that.) But in 3.1 it’ll work fine now.

    Thread Starter Paul Bearne

    (@pbearne)

    Thanks for the update.

    How are we going to communicate this change to so that vhost is removed from 3.1 + installs

    I only found it when I turned debuging on

    We need a method to tell admins/devs about deprecated values so that they get we move from the install base otherwise the code debt is just going to make wordpress bloated

    … otherwise the code debt is just going to make wordpress bloated

    That’s a bit drastic, no? You found it when turning on WP_DEBUG. That’s exactly how an admin or dev should find it as well. Turning on WP_DEBUG during development or testing is a must, frankly.

    You can also use the Log Deprecated Notices plugin, http://wordpress.org/extend/plugins/log-deprecated-notices/.

    VHOST still works. It’s not going anywhere. I just really didn’t want to bring the constant into 3.0 because of the way it stores its values as on/off rather than a boolean.

    .. and it really only applies to those who upgraded from mu, right?

    Thread Starter Paul Bearne

    (@pbearne)

    Yes its a bit drastic

    The comment is a bit more aimed at that we have quite a lot of functions and variables that have been deprecated over the years.

    At sometime point we will need to stop marking them deprecated.

    Just a comment as I am not seeing a policy or plan to tackle this.

    “Quite a lot” is open to interpretation. We have very few deprecated functions, compared to a sheer number of functions total.

    There’s a policy — we deprecate functions as necessary, and we strive to always remain 100% backwards compatible. “At sometime point we will need to stop marking them deprecated.” Why? We’re not anywhere near a critical mass of them, and I’m not sure there is one.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘vhost to SUBDOMAIN_install not clear’ is closed to new replies.