Scott Bowler

UPDATE:

After some very helpful support from Evgenii we’ve got to the bottom of this issue – seems there is a conflict with the “Admin Columns” plugin.

Are you using this plugin Luis?

After some very helpful support from Evgenii we’ve got to the bottom of this issue – seems there is a conflict with the “Admin Columns” plugin. I’ll raise a ticket with them.

Thanks again for your help Evgenii, 5* support on a free plugin.

Just to add: If you email me on sbowler <<at>> mediafront.co.uk I can give you access so you can see what’s happening.

Thanks for the rapid response – still doesn’t seem to be working:

If I go to wp-admin/upload.php and open the “Net” panel in Firebug I note all image thumbnails have the following malformed URL (note the domain appearing twice):

https://www.mydomain.co.uk/wp-admin/%5C%22https:%5C/%5C/www.mydomain.co.uk%5C/wp-content%5C/uploads%5C/2016%5C/01%5C/Amtico-Spacia_Bronze-845x321.jpg?v=1461749691\%22

This seems to cause a knock-on effect for all admin fuctionality.

Weirdly adding the <script> tags as mentioned earlier stops this from happening.

Here’s a TEMPORARY fix to make it work – don’t ask why this works, it just does (haven’t got the time to look further into the issue as it seems to be a problem in scripts.min.js and as the code is minified it makes it difficult to debug):

Open up class?meauh?attachment.php (contained in /wp-content/plugins/my-eyes-are-up-here/includes) and go to line 224, look for the following line of code:

$button .= '<div class="preview-wrap"><img src="' . $src[0] . '?v=' . time() . '" alt="' . $size . '" data-size="' . $size . '"></div>';

and replace it with:

$button .= '<script></script><div class="preview-wrap"><img src="' . $src[0] . '?v=' . time() . '" alt="' . $size . '" data-size="' . $size . '"></div>';

Adding the script tags seems to fix the issue (probably by causing a selector in the javascript file to no longer trigger).

Just chiming in to say we’re experiencing this issue on WordPress 4.5 – love the plugin, would be brilliant to see this issue resolved ??

Facing the same issue – any input would be really appreciated

Ran into a similar problem after installing it today, here is my function that I wrote (stick it in your themes functions.php). Hopefully the comments make sense!

// restrict post/page access to specific fields
add_action('json_api-core-get_post', 'rmv_restrictAPIFields');
add_action('json_api-core-get_posts', 'rmv_restrictAPIFields');
add_action('json_api-core-get_recent_posts', 'rmv_restrictAPIFields');
add_action('json_api-core-get_page', 'rmv_restrictAPIFields');
add_action('json_api-core-get_date_posts', 'rmv_restrictAPIFields');
add_action('json_api-core-get_category_posts', 'rmv_restrictAPIFields');
add_action('json_api-core-get_tag_posts', 'rmv_restrictAPIFields');

// general function which makes sure that any allowed fields get included in a request
function rmv_restrictAPIFields($query) {
    global $json_api;

    $json_api->response->exclude_values = ""; // make sure that exclude values can't be used

    $allowedFields = array('title','title_plain','slug','url','content','excerpt','categories','tags','thumbnail','thumbnail_size','custom_fields');
    $defaultFields = array('title_plain'); // used if no include options are requested
    $requestedFields = $json_api->response->include_values;

    $theFields = array_intersect($allowedFields, $requestedFields);

    if(sizeof($theFields) == 0) { // no "include" values have been set, or there are no allowed fields defined - use the defaults
        $json_api->response->include_values = $defaultFields;
    } else { // give them what they asked for!
        $json_api->response->include_values = $theFields;
    }
}

Hi Guys – any chance this could be added? Had to reapply this patch after the recent plugin update.

We have a fix which is beautifully simple – as is usually the case with these sorts of things! 3 lines of code is all it will take ??

This has been tested on a custom post type with 76,000+ posts, with the biggest parent having 1,700 children.

In functions.php, find function cms_tpv_get_pages (around line 1252) and alter the $get_posts_args array so that it includes “fields” => “ids”, as shown below

$get_posts_args = array(
		"fields" => "ids", // Memory fix - only get the ids of the post to reduce the memory hog of get_posts
		"numberposts" => "-1",
		"orderby" => "menu_order title",
		"order" => "ASC",
		// "caller_get_posts" => 1, // get sticky posts in natural order (or so I understand it anyway). Deprecated since 3.1
		"ignore_sticky_posts" => 1,
		// "post_type" => "any",
		"post_type" => $r["post_type"],
		"xsuppress_filters" => "0"
	);

Next go to function cms_tpv_print_childs (around line 1328) and scroll down to around line 1353 and look for the “for” loop:
for ($i=0, $pagesCount = sizeof($arrPages); $i<$pagesCount; $i++) {

We need to replace this code:

$onePage = $arrPages[$i];

With this code:

// Start memory fix
$temp_page_id = $arrPages[$i];
$onePage = get_post($temp_page_id);
// End memory fix

And that’s it! Children load fine – I haven’t tested any of the other functionality, but at least the tree loading is working without a hitch now. Will contact the author of the plugin about this and hopefully it can be an official patch so we don’t have to tinker with core functions.

Ok – I’ve found what the memory hog is. In function cms_tpv_get_pages the get_posts query is loading all the fields available, which is very resource heavy. If I switch this to load only the “ID” fields then the page loads lightening fast. Possible solution will be to specify which fields are needed by the tree so that it ignores everything else.

Will give that a shot and see if it fixes the issue and I’ll update this thread accordingly.

Getting to grips with the code.

This page is called when opening a parent in the tree: https://yoursite.com/wp-admin/admin-ajax.php?action=cms_tpv_get_childs&view=all&post_type=places&lang=&id=44

It calls the function cms_tpv_print_childs (in the plugins functions.php file). The first line is:

$arrPages = cms_tpv_get_pages("parent=$pageID&view=$view&post_type=$post_type");
	var_dump($arrPages); // added by me for debugging

This first request loads all the children fine and the output is used in the loop to output the JSON for the tree. This is the area where it starts to eat up the memory until it throws a fatal error.

If I can optimise this code then hopefully I’ll be able to suggest a fix. Will keep this thread updated – feel free to chip in if you have some suggestions!

Thanks for the update – hopefully someone else might come along with an answer! Might have to dig into the code to get to the bottom of it, it’s a great plugin and fits exactly what I need

Did you ever have any luck debugging/fixing this one? I’m running into the same issue.

Alternatively, did you discover any other plugins that will do the trick?