Israel Curtis

I’m also thinking that the lack of pluggable.php has to do with the fact that the media upload overlay panel is actually an thickbox iframe. As the iframe is only loading the necessary media upload php files, maybe pluggable.php is not being included, and thus no get_userdata()

the only hint I’m finding is that the function get_userdata() is defined in WP’s pluggables.php, and that some plugin authors have included it manually:

if (is_admin()) require_once(ABSPATH . 'wp-includes/pluggable.php');

I just added this line to the top of your plugin, and it worked fine after that…

How is it working for anyone else without this manual inclusion?

ugh – thought I had the 0.4.1-alpha enabled, but was actually using 0.4

but – when I installed 0.4.1-alpha, nothing at all would appear in the p2p search results. With or without the new My_P2P_Box class. Didn’t change anything else about my p2p setup – just updated to 0.4.1-alpha, so kind of hard to tell if this My_P2P_Box class works with post_status…

did something else change with 0.4.1-alpha?

??

I was hoping to adapt this to restrict the posts that appear in the meta box to only those that are “published”, whereas currently p2p doesn’t seem to care what the status is. I changed the $args to

$args['post_status'] = 'publish';

but I see no difference in the meta box search results – I’m still getting matches for draft posts…

What am I missing?

First of all THANK YOU for making this – I’m building a asset system for a photography company and I’ve been desperate to get away from GD for my image sizing… ??

I’m getting an error on the Edit Media page (wp-admin/media.php?attachment_id=1292&action=edit) only for those files I’ve uploaded since installing ImageMagick Engine:

( ! ) Warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /Users/israel/Server/ram/wp-content/plugins/imagemagick-engine/imagemagick-engine.php on line 587
Call Stack
#	Time	Memory	Function	Location
1	0.0001	58000	{main}( )	../media.php:0
2	0.4407	5510108	get_media_item( )	../media.php:99
3	0.4539	5592800	apply_filters( )	../media.php:1221
4	0.4539	5595600	call_user_func_array ( )	../plugin.php:334
5	0.4539	5595736	ime_filter_media_meta( )	../plugin.php:0
6	0.4540	5596580	array_key_exists ( )	../imagemagick-engine.php:587

Not sure what it’s affecting…

I’m having the same problem, but I’m getting stuck at 5%, after just a few seconds. I’ve left it running for 30minutes, but nothing happens…

I actually successfully ran the import tool earlier on this same installation. Having imported a bunch of new pages, I needed to run it again. The first time, I remember it getting stuck for a few minutes at various points, but then it continued until complete. the Tool does recognize the assets that were already imported and skips them. I just can’t figure out why it’s hanging….

On a side note – is there a reason why the import tool ignores the wordpress settings for “organize uploads into year and month folders”? I’ve got this unchecked, so the posts I create just dump the images into the uploads folder, while the MLITool creates the date folders..

Quick followup – there’s definitely something happening with the wp-admin when W3TC is active. If I disable the plugin, I get virtually no lag going from page to page (comments, edit posts, etc.). With the plugin active (though disabled from cacheing, as confirmed in the debug output on the wp-admin pages), the 7-12 second server response lag comes back – and the debug output shows that the query time was only 0.078!

One thing that will almost always cause the server request to timeout completely (and return a blank page) is clicking “empty all caches”…

Help!

I can second this behavior. I am seeing the exact same results. I was at first just trying to figure out why I had such a long server response time lag with W3TC turned on (even with APC enabled). My page load times were great – but the initial server response was unbearable. It was bad in the Admin too, where you wouldn’t think W3TC would be an issue.

When I finally disabled W3TC, my server response times were near instantaneous, but the page load of course was much longer. I was getting a consistent 7 second lag on an in-house clean development server, but no lag with the plugin off.

I then found this topic, and tried the hint of turning on debug mode. My lag dropped to 2 seconds (and that last 2, as confirmed in the debug mode results at the bottom of the page, included some plugin queries that took far too long).

This is on WP 2.9.2, on a windows server, with everything up-to-date, a slew of plugins, and a DB consisting of 250 authors, 11,000 posts and 140,000 comments.

I never suspected W3TC, which was making my pages load wicked fast, would be causing the lag. When I was observing our live server statistics in real-time, I could see the CPU never got above 5% usage, and our 8GB of RAM was only hovering at about 30% usage. So it made no sense that the server was taking so long to respond (on the live server, up to 15 seconds) and begin streaming the page data – there was no stress on the server of any kind – just a long pause.

Any clues?