smurkas

Thanks for the answer!

I just want to say that in theory I agree with you and I also think we should be trying to move forward but realistically we’re still a long way away. Support for the 5.2 line just ended though so you never know.

I personally think the bigger players like WordPress should push the button on this issue since if WordPress went 5.3 then a huge amount of people and hosts would have to switch but right now, the incentive isn’t strong enough.

The numbers are about 6 months old but then 3.56% of the WordPress community and Ilias latest stats found here put 5.3 adoption at 4% so it seems like there at least isn’t a bias against 5.3 in the WordPress community.

A potential user base of about 4% is very small but if the goal is just sharing your stuff then more power to you. I might be able to keep an updated 5.2 branch running, at least as long as you don’t start using late static binding or __callStatic().

In one word: Yes!

From the start your widget has been kind of mimicking the normal add image process that you have when editing posts in the wysiwyg editor so I think taking it all the way sounds like a really good idea, especially if you already got some help with it.

I personally think that the image upload process in the wysiwyg editor is really nice and making the controls in the thickbox usable with your plugin makes alot of sense.

Adding this to core sounds like a great idea too since without your widget there is no hassle free way of just adding an image to the sidebar.

You have done and are doing most excellent work with this plugin! Mad props to capnhairdo for helping out too!

Is there any chance that I/we could try out the version you got from capnhairdo?

You seem to be on to something there capnhairdo.

I tried turning off the offending javascript in custom field template and I still ended up with an empty thickbox but no javascript error.

The weird part is that everything works on my live server if I turn off custom field template so something else is causing som kind of conflict.

It sounds like the same kind of error that we’re getting from the conflict with custom field template. When I have custom field template on I get the exact same behaviour.

What plugins are you running?

If you have the possibility it would be very appreciated if you could turn off all your other plugins and see if the problem persists. If it works without the other plugins on I would be even happier if you could help us track down the plugin that’s conflicting.

Also the javascript error could be occurring inside the thickbox which is in an iframe so in that case I don’t think we’d actually get a warning from firebug :(.

Ok I can confirm that the conflict is coming from custom field template. It appears that he hooks in to when the image is “transferred” from the thickbox to its final destination.

When his code runs on the widget page it gets confused since the code he’s depending on is not there, his function fails and so does your script along with it.

I see two (maybe three) ways to fix this:

1. The fast (and painful): Simply choose which plugin you need the most and deactivate the other one
2. The long road: We talk to the guy who made custom field template and ask him to solve this. His plugin is very active so I think there might be a good chance that he will comply.
3. The sneaky (and untested) solution: Hit his plugin with a remove_action() to remove the offending javascript when on the widget page. If we can make sure this plugin gets loaded after custom field template it should theoretically be possible to remove the action hook that adds his code.

That’s all the options I can come up with. I’ll be exploring option three and see if I can get that to work.

Oh wow what a mess (not your plugin :P).

I have tracked this down and it appears to be a javascript conflict. In my case the conflict was with custom field template, can anyone else confirm that they get the error when using custom fields and image widget together?

If I turn off custom field template then everything works. I am using version 1.3.7 of custom fields template, I will try it with version 1.3.8 as well.

For anyone else tracking this, the thickbox is an iframe with its own scripts loaded. Some plugins load their scripts into the thickbox and I’m not sure if they belong there.

Peter can you confirm if the thickbox actually needs your javascript loaded inside it or if it’s only needed in the admin section?

I’ll try to help you out since I’m having this problem on my production server which is a linux system.

Just so everyone is on the same page here, does everyone who’s having issues end up with a blank thickbox when trying to add the image? I get a blank thickbox and this error in firebug:
win.send_to_custom_field is not a function

I don’t get this error on my local windows machine that I’m doing all the development on and it’s a weird javascript error if it’s server related.

I’ve got some javascript chops so I’ll try to track this down and fix it. This widget provides some really essential functionality that wordpress has been lacking for quite some time so I’m hoping I can find what’s causing this.

If anyone else out there who’s having issues could check what happens in firebug and confirm that you’re getting the same error I would be very grateful.

Ok I did the following to fix this.

1. Changed the class of the Add image-link to image-widget so thickbox doesn’t touch it on its own.
2. Add some jQuery event delegation.

jQuery(document).ready(function() {
	jQuery("body").click(function(event) {
		if (jQuery(event.target).is('a.image-widget')) {
			tb_show("Add an Image", event.target.href, false);
		}
	});
});

As you can see here, we’re binding an event to the body (ugly I know) and looking for when an a-tag with the image-widget class is clicked. We then call tb_show directly since we know what options we want to pass.

I’ve tried it out and it seems to work. Let me know if there are any issues or if you don’t have the problem I describe above at all. I’m running WordPress 2.8.4.

Hey again all.

I’ll have another go at it if you want Mikko to see if we can get this fixed. Hopefully I’ll have some time to do a run on it in a couple of days, I’ll send you an email with my progress.

This has to do with how Navt figures out what page it’s on. If you have set up a static front page you have to edit get_current_location() in navt_fe.php line 837.

Mind that these changes will probably break the plugin for the normal use case without the static front page. On line 847 the function starts figuring out the location and this is where it goes wrong.

When you’ve set a static front page both the posts page and the front_page are of the type page but Navt sets them to TYPE_LINK which signifies an internal link.

If these are set to TYPE_PAGE instead it works. You still can’t use the special home link but just grab the page you set instead and put that in the menu as home.

Replace line 848 to 866 in navt_fe.php with this

if( $wp_query->is_posts_page ) {
	$p = get_page(get_option('page_for_posts'));
	$loc['parent'] = '';
	($p->post_type == 'page') ? $loc['page'] = TYPE_PAGE . $p->ID : $loc['page'] = TYPE_LINK . $p->ID;
	$loc['set'] = 1;
}

if( $is_front_page && !$loc['set'] ) {
	if ( 'posts' == get_option('show_on_front') && is_home() ) {
		$loc['parent'] = '';
		$loc['page'] = TYPE_LINK . HOMEIDN;
		$loc['set'] = 1;
	}
	elseif('page' == get_option('show_on_front') && get_option('page_on_front') && is_page(get_option('page_on_front')) ) {
		$p = get_page(get_option('page_on_front'));
		$loc['parent'] = '';
		($p->post_type == 'page') ? $loc['page'] = TYPE_PAGE . $p->ID : $loc['page'] = TYPE_LINK . $p->ID;
		$loc['set'] = 1;
	}
}

The whole thing resets when you do a quick edit.

I added this to line 568:
echo "<input type='hidden' name='p2c_active' value='1'/>";
and then change the function that starts on line 584

function page2cat_trigger_save($post_ID){
	global $wpdb;
	if ($_POST['p2c_active']):
		$values = $_POST['p2c_bind'];
		$via = "DELETE FROM {$wpdb->page2cat} WHERE page_ID = '".$_POST['post_ID']."'";
		$result = $wpdb->get_results($via);
		if(count($values) > 0):
		foreach($values as $key=>$cat){
			if($_POST['post_ID'] != ""):
			$sql = "INSERT INTO {$wpdb->page2cat} (rel_ID, page_ID, cat_ID) VALUES ('','".$_POST['post_ID']."','".$cat."')";
			$result = $wpdb->get_results($sql);
			endif;
		}
		endif;
	endif;
}

All I have added is the first if clause that checks for the new form field value that I added. Since this form element isn’t present when doing a quick edit the function won’t fire and delete all your connections.

The function will fire normally when doing a real page edit and everything should work fine. I am running the latest wordpress version and everything has worked so far.

Ok there seems to be quite alot that needs to be replaced in order for Relevanssi to work properly with utf8 content all the way.

Since I really need something like this I will try to fix everything utf8 related, hopefully I can do it!

strtolower() in relevanssi_tokenize() ruins utf-8 characters as well. I will try to follow your search function step by step and fix stuff along the way. Hopefully the search function will get a hit on the search term I’m using when I have gone through it since the word is in the posts in my database.

Kindly, Marcus

The issue seems to be the three occurrences of preg_replace() in the code. Preg_replace is not utf-8 safe so it should be switched to mb_ereg_replace() instead.

When I switch over the search works properly for me. I get weird characters in the database now instead of cut off words. Don’t know if this impacts the plugin overall in some way.

Kindly, Marcus.

Also if I search on only Swedish letters I get mb_strpos() [function.mb-strpos]: Unknown encoding or conversion error. in relevanssi.php on line 756.

The page character set is set to UTF-8 as well.

Kindly, Marcus.

I am having the same issues when using Swedish letters like ? ? ?. Whenever a search word contains one of the above characters Relevanssi seems to cut off the search word at that letter. So if I search on ler?gare (not a real word) Relevanssi searches on ler.

Also the index seems to cut off the files at the special character, only the remainder of the word gets stored.

? ? ? are stored as real characters in the database and all the tables are utf8.

When do you think the strip occurs? Do you think it goes wrong when Relevanssi hits the database or before that?

Kindly, Marcus.