Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Benjamin Birkenhake

    (@benjaminbirkenhake)

    I just reviewed the plugin for a customer. The PHP/Wordpress part is very clean and lean. And the included JS library is up to date as far as I can see. But I currently cant’s say how it works with Gutenberg, and I didn’t make a line-by-line review. So: It makes an overall good impression. But that doesn’t garantee that there’s vulnarability hidden somewhere. Plus: The older a plugin gets, the more likely it is, that it brakes with furhter PHP-Versions …

    That’s not a real answer to your question, but I hope it helps a bit. We will take a look at the plugin again in summer, when we review the site for accessibility more thoroughly.

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    I take everything back and claim the opposite!
    I just recently noticed the “Choose your Language” Option on the Login.

    Ashes on my Head!

    Mea Culpa!

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    I could give you access to a clone of the site, if that helps …

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    Ahm. Yeah. It was on 5.0.1 when we found out about it. But I updated it right away and now its on 5.0.3 and still the DB-queries as high as before.

    Aaand like before … when I deactivate the Plugin, the Queries go down to 16.

    Can I help in anyway?

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    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 … ??

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    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?

    Thread Starter Benjamin Birkenhake

    (@benjaminbirkenhake)

    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

Viewing 7 replies - 1 through 7 (of 7 total)