htrex

Tomasz, can you give us an idea about how do you see the future of this plug and if you’d like to receive code contributions?

Good news about WP_Image_Editor, that’s available starting from WP 3.5, so you could drop direct image manipulation code and raise WP minimum version requirement, or use WP_Image_Editor only when available.
No one should be still using WP < 3.5 now, I’m all for dropping.

Would you like to put the plugin on GitHub or something so you can receive contributions to your code?

I’ve just wrote a little patch to show translated image sizes labels instead of their internal ID on crop window tabs…

Cheers!

Thanks for sharing your trick @defries, however it would be great to have this option nativelly, somewhere in the future…

That plugin won a prize in 2008, but google reports known security vunerabilities.

Had a look to it’s code to see how the author managed to add a tag taxonomy to standard WP comments and mostly seems an hack, no idea if that part would work on the current architecture.

The plugin is declared to be working with WP 2.5.1 (!) and I’m not sure about how WP comments internals changed up to 3.5.

I’m exploring this part and at first tought that comments could be just a custom post type and extensible as such, but a first look at WP core gave me the idea that it isn’t like that.

If I’m not wrong we can easily add custom fields to built-in WP comments but using a native tag taxonomy is not supported.

How would you implement that otherwise?

@dwenaus can you share your updated version on GitHub as we can test it and maybe share some plugin maintenance with you?

I’m interested to keep up this little great plugin!

Great catch jorn!

Hi Tobias,
nice to hear from you again!
mmm, look if this library could come in help for backend data editing:
https://jquery-datatables-editable.googlecode.com/svn/trunk/index.html

Another couple of ideas:
* an ecologic improvement that shouldn’t result in a drastic disruption for the current codebase is to implement a final render caching layer, beeing the render an HTML fragment, a json data structure or whatever…
looking at server load and client wait times seems that data is queried on the database and arranged in the HTML presentation every time, with RAM and CPU resources used even if data has not been changed from the last render…

* thinking of a possible ajaxification please consider to don’t disrupt the current frontend behaviour to have the data printed in HTML on the public site, as real HTML can be be good for SEO and a JS progressive enhancement is enough.
Otherwise to eventually allow publishing huge tables on the public site an ajax chunked data loading could be a must, but on my tests up to about 25.000 rows HTML is still an alternative, please leave an option for it! ??

Cheers for TablePress!
–htrex;

found another bug in the italian translation, row 122 of wp-fullcalendar.php should be

'it'=>array('closeText'=>'Fatto','prevText'=>'Precedente','nextText'=>'Prossimo','currentText'=>'Oggi','monthNames'=>array('Gennaio','Febbraio','Marzo','Aprile','Maggio','Giugno','Luglio','Agosto','Settembre','Ottobre','Novembre','Dicembre'),'monthNamesShort'=>array('Gen','Feb','Mar','Apr','Mag','Giu','Lug','Ago','Set','Ott','Nov','Dic'),'dayNames'=>array('Domenica','Lunedì','Martedì','Mercoledì','Giovedì','Venerdì','Sabato'),'dayNamesShort'=>array('Dom','Lun','Mar','Mer','Gio','Ven','Sab'),'dayNamesMin'=>array('Do','Lu','Ma','Me','Gi','Ve','Sa'),'weekHeader'=>'Wk','dateFormat'=>'dd/mm/yy','firstDay'=>1,'isRTL'=>false,'showMonthAfterYear'=>false,'yearSuffix'=>'')

the day names must always start with sunday (domenica) to show a correct calendar, a string in the original code was misplaced resulting in a wrong day number <-> day name correspondance

Sure you’re right Frank, stripping away the prepare statement in this specific case doesn’t seem to directly expose to any risk, but the move from WP core devs is to raise awareness for a better WP ecosystem coding practice, so tought to share that post for reference.

Frank, your hotfix doesn’t seam really risky but according to
https://make.www.ads-software.com/core/2012/12/12/php-warning-missing-argument-2-for-wpdb-prepare/ the code should be changed with something like this:

$count['Today and yesterday'] = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(id) FROM %s WHERE TIMESTAMPDIFF(DAY, time, NOW()) <= 1;", $log_table ) );
	$count['Last 7 days'] = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(id) FROM %s WHERE TIMESTAMPDIFF(DAY, time, NOW()) <= 7;", $log_table ) );
	$count['Last 30 days'] = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(id) FROM %s WHERE TIMESTAMPDIFF(DAY, time, NOW()) <= 30;", $log_table ) );
	$count['Forever'] = $wpdb->get_var( $wpdb->prepare( "SELECT COUNT(id) FROM %s;", $log_table ) );

Sorry for the delay Marcus, had the opportunity to check just today, upgraded to version 5.3.2.1 stable and found this problem is fixed, great stuff!

John, that probably seemed to solve the problem because deleting and reinstalling Jetpack also resets it’s settings and Photon is disabled by default.
If you reenable that option you should see the problem again, or at least that’s what happens on my site…

Please Automattic check this problem!

After the update from 2.0.2 to 2.0.4 I’m seeing this error message appearing on the front end of my site too!

Robert, waiting for a proper solution from automattic, you can place an ‘@’ character in front of array_key_exists statement to suppress the warning.

After the modification line 183 of /wp-content/plugins/jetpack/modules/photon.php should be:

} elseif ( isset( $size ) && @array_key_exists( $size, $image_sizes ) && isset( $image_sizes[ $size ]['crop'] ) ) {

thank you Marcus, I’ll check and let you know if that works for Widget Entries when you release the latest code.

I understand the point, but found a trick to make EM a little more robust, compatible with Widget Entries and maybe other plugins with a little change to EM code that shouldn’t give any other problem:

change row 25 in events-manager/em-events.php from
if( in_array($post->ID, array(....
to
if( isset($post->ID) && in_array($post->ID, array(...

What do you think?