Add SiteTree::$hide_pagetypes configuration property

[sminnee]

Acceptance criteria

• SiteTree has a $hide_pagetype config value which accepts SiteTree subclass class names in an array
• $hide_ancestor is deprecated
• The new configuration property gets defined directly on SiteTree via yaml config - defining it on subclasses has no effect
• classes in that array will not be available in the CMS when selecting page type, for any user.
• Unit tests pass
• Docs exist and are correct

PRs

• API Add new SiteTree.hide_pagetypes configuration #2902
• DOC Document new hide_pagetypes config developer-docs#393

[tractorcow]

This is essentially a tweak of hide_ancestor, so it should be a simple rename / refactor.

[tractorcow]

/**
     * If you extend a class, and don't want to be able to select the old class
     * in the cms, set this to the old class name. Eg, if you extended Product
     * to make ImprovedProduct, then you would set $hide_ancestor to Product.
     *
     * @config
     * @var string
     */
    private static $hide_ancestor = null;

[sminnee]

Yeah I think we can ditch hide_ancestor favour of this mechanism.

[chillu]

Removing from milestone, it's a new API. The old (replaced) API can be deprecated instead of removed once we get around to that in the 4.x release line.

[pxwee5]

As of SS4.1@stable, there's no depreciation notice on $hide_ancestor nor any implementation of $hide_pagetype.

As much as I believe $hide_pagetype is more intuitive to use and have no dependencies on parent classes, please give enough depreciation notice/time before we completely drop the $hide_ancestor configuration.

[tractorcow]

Don't worry, if we deprecate it, it will still work perfectly fine until 5.0 at least. Deprecation notices won't show on deprecated APIs unless you opt in by the way.

// Set to 5.0.0 to show APIs marked for removal at that version
Deprecation::notification_version('4.0.0');

[sabina-talipova]

Solution was implemented. Issue is closed.