WordPress.org

Ready to get started?Download WordPress

Forums

Storify
1.0.5 throws a "Allowed memory size exhausted" on WP-Admin (6 posts)

  1. Benjamin Birkenhake
    Member
    Posted 1 year ago #

    Hi there,

    the last Update of the Storify-Plugin, it breaks our clients Installation on Activation. The problem is, that it takes by far too much memory. After the Limit of 2048M set via php.ini is reached, php kills the process. But 2GB seems a bit too much for a login on the dashboard, imho.

    Also the whole WP-Admin keeps throwing the same error, so it seems to be not only on activation but also on startup of the WP-Admin.

    Our clients installation has about 20.000 Articles and 2.000 Tags. May that's part of the problem.

    Hope this helps debuggin.

    http://wordpress.org/extend/plugins/storify/

  2. Benjamin Birkenhake
    Member
    Posted 1 year ago #

    Some additional Infos:

    The effect happend, when we were updating the plugin to 1.0.5.
    We are running on latest WordPress 3.3.2

    Aaand: The Error
    Fatal error: Allowed memory size exhausted in /wp-includes/wp-db.php on line 1121.

    The same effect doesn't seem to happen on an identical setup, but with faaaar less Content. We'll be testing that by ourselves and give more information on that here again.

    Other Plugins:
    - Accordion Shortcode
    - AddThis Social Bookmarking Widget
    - List category posts
    - MediaElement.js - HTML5 Audio and Video
    - Modernizr
    - Quick Page/Post Redirect DEV
    - Tabber Tabs Widget
    - Tweet Blender
    - Widgets on Pages
    - WordPress Importer
    - WP Permalauts

  3. Benjamin Birkenhake
    Member
    Posted 1 year ago #

    Ah. I guess, I found the reason.
    Line 1100 of the storify.php:

    /**
     * Upgrade the database on plugin upgrades
     */
    function upgrade() {
    
    	$db_version = get_option( $this->version_option );
    
    	if ( $db_version == $this->version )
    		return;
    
    	//1.0.4 upgrade
    	//loop through all previosly published stories and add post meta
    	//prevents description from being added on subsequent updates
    		if ( $db_version < '1.0.4' ) {
    
    		$posts = get_posts( array( 'numberposts' => -1 ) );
    
    		foreach ( $posts as $post ) {
    
    			if ( !$this->is_storify_post( $post ) )
    				continue;
    
    			update_post_meta( $post->ID, $this->description_meta, true );
    
    		}
    	}
    
    	//incremement DB version number
    	update_option( $this->version_option, $this->version );
    
    }

    This is pretty likely going to reach the memory-limit of any Installation with some more content the an few hundred posts, for the get_posts() as well as the subsequentially called wp_get_object_terms() are know to perform pretty baldy on more than a few hundred Articles.

    Doesn't WordPress have some kind of JS-driven Batch-Process, like Drupal?

    Actually: To get my setup running again: What bad will happend, if I out-comment, the function and activate the plugin?

  4. Ben Balter
    Member
    Plugin Author

    Posted 1 year ago #

    The smarter way to prevent the error would be to manually bump the storify_version value in the database, to ,1.0.5, which would bypass the upgrade procedure on subsequent updates.

    Normally, storify pulls the description out of the story and places it into the body of the post, and stores a post_meta to indicate it has done so (so it doesn't do it on subsequent saves). The upgrade procedure marks existing posts with storify urls in them as already having the description added, preventing the plugin from breaking existing posts.

    May make more sense to search specifically for those posts, or to move it to a sub-loop which wouldn't hit the memory limit like that.

  5. Benjamin Birkenhake
    Member
    Posted 1 year ago #

    Ok. That seemed to work.

    One thing, I am still interested in: What means "preventing the plugin from breaking existing posts."
    HOW do they break?
    (Just want to know, what might bei lurking ahead of me … :)

  6. Ben Balter
    Member
    Plugin Author

    Posted 1 year ago #

    Sure. And valid question. My Sorry for the ambiguity.

    In order to better integrate with the look-and-feel of sites, the plugin passes an argument on the embed code to remove the standard border and the "description" text at the top of the story (usually grey/italic below the title).

    Realizing that the description was being stripped, starting with 1.0.4, on save, the plugin grabs the description, and sticks it in the post as normal in-post text directly above the story. Put another way, 1.0.4+ pulls the description out of the story and inserts it into the post.

    Problem being then, from a UX standpoint, what happens if I had a story in a post previously, noticed the problem, and manually corrected it. I wouldn't want the plugin to now start double adding the description. So to err on the side of caution, it loops through prior posts, and if they have a story in them, sticks on a meta flag to indicate not to add the description.

    The actual loop itself, in hindsight, does not scale well, and could have been done a lot smarter (e.g., just running an SQL query directly for post_content LIKE %storify.com%).

    Incrementing the DB version flag should prevent the loop from running, and assuming you don't have 20,000 Storify posts, you should be fine. Even if so, the description would only be inserted on save.

    Hope that clears things up?

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags