Hi Steve,

I’m using the 0.8.0b5 build.

Hi,

The micro-fix I mentioned earlier does seem to break the built in functionality for featured images, and could be causing issues elsewhere. Not sure if that may be something that’s throwing a spanner in the works… I’ve tweaked my fix and it seems to have me on track for now. I’ll report back in if anything else crops up!

/** Piklist widget uploader requirement (fix) **/
	
	function add_media_support(){ 
		if(is_admin() && last_url_segment() == 'widgets.php'){
			wp_enqueue_media(); 
		}
	}
	add_action( 'admin_init', 'add_media_support' );

/*
**	Last URL Segment Function
*/
		
	function last_url_segment(){
		
		$uri = $_SERVER['REQUEST_URI'];
		$no_var = explode('?',$uri);
		$pieces = array_filter(explode("/", $no_var[0]));
		
		return end($pieces);
		
	} 

Hi guys, back in the usual fashion I’ve found the problem and got a solution. It’s a simple one really though my implementation most likely needs some actual polishing as it covers the whole admin and not just the area it needs (which may cause issues elsewhere?). I’m sure you know where it’ll need to live in Piklist!

Basically it’s just missing: wp_enqueue_media();

That’s responsible for filling out the vital part to the javascript object that the media uploader uses.

So as a temporary fix I’ve just put this in my functions.php:

function add_media_support(){ wp_enqueue_media(); }
add_action( 'admin_init', 'add_media_support' );

There are a couple of problems that spring up from there but nothing major. Firstly, it seems to make an extra empty media item each time I do it. If I leave it in, it’s not an issue; if I delete it, it’s not an issue; either way it’s a minor annoyance then a show stopper.

The second problem is that you can’t just do $setting[‘field_name’] and have your link as it only outputs the attachment ID. I’m sure this is something you’ll look to clear up though for anyone who might stumble across this scratching their head you can pull the information easily with the following.

<?php $image = wp_get_attachment_image_src( $settings['field_name'], 'single-post-thumbnail' ); ?>
<img src="<?php echo $image[0]; ?>" alt="">

Obviously the above is for images only but can be similarly adapted for files to the best of my knowledge

Hope that all helps! 🙂

Awesome, great to hear.

For me it’d be great to be able to disable them through the functions.php file (as a first choice) or failing that just some tick boxes in the plugin somewhere would be good. I assume though if you set up the second one there presumably it would be re-creatable easily in the functions.php.

OK, I’ve had a dig about and found part of the problem and enough to smooth over it. It doesn’t however fix the cause of the issue, just the symptoms.

The symptom (cause unknown):

class-piklist-universal-widget.php

Line 86:

piklist::render(piklist::$paths[$options[1]] . '/parts/widgets/' . $options[2], array(
      'instance' => $instance
      ,'settings' => $instance // NOTE: So beginners have a more understandable name to store variables from the widget
      ,'before_widget' => $before_widget
      ,'after_widget' => $after_widget
      ,'before_title' => $before_title
      ,'after_title' => $after_title
    ));

This first argument is the one that tells the renderer what template file to use, and this is what is causing the problem, $options[2] most specifically. It should contain the file name (without the extension), but it also has some extra characters crammed in so where it should be ‘example’ it is actually ‘example”;’ ( notice the extra “; )

This happens on both the demo widgets and custom widgets so I don’t believe I’m doing anything wrong in implementation. It looks like this is being pulled from part of the serialised array that’s in the database and overshooting the end of the value. Here is a sample value I had in my database from a widget attempt.

a:2:{i:2;a:4:{s:30:"piklist_universal_widget_theme";s:68:"a:1:{i:0;s:50:"piklist_universal_widget_theme--theme--image-block";}";s:9:"demo_text";s:30:"a:1:{i:0;s:12:"Default text";}";s:11:"demo_select";s:24:"a:1:{i:0;s:7:"option1";}";s:16:"demo_colorpicker";s:24:"a:1:{i:0;s:7:"#aee029";}";}s:12:"_multiwidget";i:1;}

So, not sure what’s causing it and I’ve spent more time then I really should have to try and sort this – but it’s for a good cause 😉

The (temporary) fix:

Before the function mentioned above on line 86, insert the following… this simply trims off those troublesome characters.

 // Quick Fix: Widget Rendering Problem
  $options[2] = substr($options[2], 0, -3);

Then, with any luck you should be back in business. Hopefully the Piklist team can spot what I’ve said and instantly know what’s going on and where it should really be fixed.

Bring up the debug messages I seem to get this if it’s any clue:

Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method PikList_WordPress::get_meta_sql() should not be called statically in /Applications/MAMP/htdocs/dev_sda/wp-includes/plugin.php on line 230