Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't waste time providing data not actually required in a REST request #120

Open
bobbingwide opened this issue Jan 31, 2019 · 3 comments

Comments

Projects
None yet
1 participant
@bobbingwide
Copy link
Owner

commented Jan 31, 2019

I re-raised Gutenberg issue 5376 as WordPress/gutenberg#13618 but don't know if the problem will addressed quickly.

So I need to investigate ways to avoid wasting time providing answers to the REST APIs' rhetorical questions.

i.e. Don't expand shortcodes during the_content processing when the client doesn't need the information to do its job.

Requirement

A performant Page Attributes block when using the Block editor to edit a hierarchical post type's post which is likely to contain a number of shortcodes that could take a long time to expand.

Proposed solution

I'm working on it.

@bobbingwide

This comment has been minimized.

Copy link
Owner Author

commented Jan 31, 2019

The elapsed time to populate the Parent Page: dropdown for the oik_file post type was approximately 4.5 seconds per REST request.

https://s.b/oikcom/wp-json/wp/v2/oik_file?per_page=100&exclude%5B0%5D=23607&parent_exclude%5B0%5D=23607 &orderby=menu_order&order=asc&context=edit&_locale=user&page=2

Each post contained the following content

<!--more -->[file][bw_fields]

For each post found the REST api returned the content as both raw and rendered.
Preventing the server from processing the_content reduced the server elapsed time to 0.9 secs.

@bobbingwide

This comment has been minimized.

Copy link
Owner Author

commented Jan 31, 2019

The first part of this fix is to ensure that the REST requests do actually complete. There were a couple of routines that failed due to functions not being available.

@bobbingwide

This comment has been minimized.

Copy link
Owner Author

commented Jun 5, 2019

but don't know if the problem will addressed quickly.

Nope. It hasn't been addressed yet. It's still a problem. I reproduced the issue in my local environment in s.b/hm with just 54 pages. The server timed out after 122 seconds. The page for which the excerpt was being produced at the time contained a shortcode that was satisfied by HTTP requests to other sites since the transient data that's normally used had expired.

Workaround

That page did not have a hand cranked excerpt. I added one to reduce the time taken to perform respond to get_the_excerpt.

Proposed solution

In the hook to respond to rest_api_init, if the request is with context=edit then disable all filter functions for both the_content and get_the_excerpt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.