WordPress.org

Make WordPress Core

Opened 7 months ago

Last modified 3 months ago

#49193 new defect (bug)

Parent Page selector not available in Page Attributes when using Block Editor

Reported by: Brandicoot Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.3.2
Component: Editor Keywords: reporter-feedback
Focuses: ui, css, administration, multisite Cc:

Description

We're running a multisite with around 190 child sites on it.

When our users are using the block editor, the "Parent Page" drop down selector does not appear within the Page Attributes box.

I've tried using the default wordpress theme - same result.
Our test platform, on the same server with an identical configuration and plugin set but which only has a couple of child sites is not experiencing this problem - however, it does take a couple of seconds for this individual dropdown selector to load.

The other diference is that the multisite where the issue exists is showing an error in developer tools that says "Uncaught (in promise) SyntaxError: Unexpected token < in JSON at position 6

Attachments (1)

Screen Shot 2020-01-14 at 11.36.23 am.png (9.5 KB) - added by Brandicoot 7 months ago.
screenshot of error in developer tools

Download all attachments as: .zip

Change History (5)

@Brandicoot
7 months ago

screenshot of error in developer tools

#1 in reply to: ↑ description ; follow-up: @SergeyBiryukov
7 months ago

  • Component changed from General to Editor
  • Keywords reporter-feedback added

Hi there, welcome to WordPress Trac! Thanks for the report.

Replying to Brandicoot:

I've tried using the default wordpress theme - same result.

Does the issue still exist with all plugins disabled?

#2 in reply to: ↑ 1 ; follow-up: @Brandicoot
6 months ago

Hi @SergeyBiryukov

Unfortunately, I'm not in a position to disable all plugins as many of the plugins are network activated and this would mean disabling 31 plugins for nearly 200 live websites.

However, our test platform, which is on the same server with an identical configuration and plugin set but which only has a couple of child sites is not experiencing this problem. If it was a plugin confilict, I would expect to see the bug on the test platform.

The only difference between the test platform and the live platform is that the live platform has nearly 200 sites, whereas the test platform only has a few.

Replying to SergeyBiryukov:

Hi there, welcome to WordPress Trac! Thanks for the report.

Replying to Brandicoot:

I've tried using the default wordpress theme - same result.

Does the issue still exist with all plugins disabled?

#3 in reply to: ↑ 2 @Brandicoot
6 months ago

Update:

I've done some more testing and seem to have found where the problem lies...

I setup a test site (site A) on our live multisite network and enabled identical plugins to an existing site (site B).
I then disabled site activated plugins on site A one by one to see if the problem went away.
When I disabled Gravity Forms on Site A, the problem went away for Site A.
I then reactivated Gravity Forms on Site A and the problem did not return.

Great, I thought. So I did the same to site B.
I deactivated Gravity Forms on Site B and, as expected, the problem went away.
However, when I reactivated the Gravity Forms plugin on Site B, the problem returned.

I then went to a third site to try again and noticed a PHP error message that flashed up on the screen briefly before loading the page editing screen. The error stated that page headers had already been sent out by a script in a PHP functions file that I have that affects all sites on the network. I removed the script and the problem goes away for all three sites with Gravity Forms activated.

If you're interested in what the script did, it was to give me the option of making a Gravity Form field read only and is pasted below...

<?php
//Make a Gravity field read only
add_filter( 'gform_pre_render', 'add_readonly_script' );
function add_readonly_script( $form ) {
    ?>
 
    <script type="text/javascript">
        jQuery(document).ready(function(){
            /* apply only to a textarea with a class of gf_readonly */
            jQuery("li.gf_readonly input").attr("readonly","readonly");
        });
    </script>
 
    <?php
    return $form;
}

So, with the above script removed, the problem no longer exists - although, the "parent page" drop down does take longer to load on sites with more pages but I can live with that.

I'll just have to find another way of making Gravity Form fields read-only

Thanks for your help.

Chris

Replying to Brandicoot:

Hi @SergeyBiryukov

Unfortunately, I'm not in a position to disable all plugins as many of the plugins are network activated and this would mean disabling 31 plugins for nearly 200 live websites.

However, our test platform, which is on the same server with an identical configuration and plugin set but which only has a couple of child sites is not experiencing this problem. If it was a plugin confilict, I would expect to see the bug on the test platform.

The only difference between the test platform and the live platform is that the live platform has nearly 200 sites, whereas the test platform only has a few.

Replying to SergeyBiryukov:

Hi there, welcome to WordPress Trac! Thanks for the report.

Replying to Brandicoot:

I've tried using the default wordpress theme - same result.

Does the issue still exist with all plugins disabled?

#4 @knittingand
3 months ago

I'm having the same problem but I don't use the Gravity form plugin at all.

I have to keep turning on the classic editor plugin in order to get the parent page drop down to show up, save my page as a draft, turn off the classic editor plugin, convert whatever I've written to blocks, then continue.

My site is very old and has 1,869 pages. All plugins and wordpress are up to date versions.

Note: See TracTickets for help on using tickets.