Any chance of tweaking it so that I could give +1′s to articles irrespective of and in addition to sharing them in G+ posts? From what I can tell, giving +1′s isn’t currently supported by the plugin.

Google Reader had +1 tied to sharing so that in order to share on G+ I had to +1 it first. That was okay but not entirely optimal: +1 and posting on G+ about something could IMHO very well be two separate functions, so that you could

* only +1 something
* only share it in a G+ post
* do both if you like

— wp-status-net.php 2012-07-16 20:51:15.604960940 +0300

+++ wp-status-net.php.new	2012-08-01 21:04:36.392944461 +0300
@@ -700,7 +700,7 @@
 function wpstatusnet_options()
 {

-      	if ( 'save' == $_REQUEST['action'] )
+      	if ( array_key_exists('action', $_REQUEST) && 'save' == $_REQUEST['action'] )
 		{
 			$options = array(
 				"apitype" => $_REQUEST[apitype],
@@ -931,7 +931,7 @@
 {
 	if (function_exists('add_options_page'))
 	{
-		add_options_page('WP-Status.net', 'WP-Status.net', 0, basename(__FILE__), 'wpstatusnet_options');
+		add_options_page('WP-Status.net', 'WP-Status.net', 'manage_options', basename(__FILE__), 'wpstatusnet_options');
     	}
 }

There was a topic about replacing br tags with newlines on Urban Giraffe, but it seems to have led nowhere, so I’m posting this here just so that I can find it when I again need it, and maybe of help to others too.

I modified the search_and_replace function on line 37 of models/search.php so that $this->replace is assigned a replaced string itself:

$this->replace = str_replace("\\n", '
', $replace);

This means I want to replace any occurences of ”\n”’s in my replacement string with actual newlines just prior to applying the replacement.

It’s an ad hoc solution which I’m reverting once I’m done with newlines. I’ve not explored any possible side effects this solution may have, so use with caution.

Edit: Forum ate my br.

No problem, and thanks for the rapid response to my bug-report-turned-support-request!

Yes and no. :) No, I’ve never used anything but SLB. Yes, it’s apparently always activated links, but it also used to have the ’Activate all image links in item content’ option. Being able to uncheck that option I could use SLB as I have until now: with lightboxing only on links I’ve manually specified as rel=”slb”. The automatic url-snooping thingy just doesn’t work for me, since I use lots of image links pointing to wiki pages of those images.

FWIW, it was easy to fix this for myself: I just cut process_links() so that it immediately returns with unprocessed $content.

So, uh, how do I retroactively extend this reversed behavior to all the links on my blog relying on the previous behavior? I think it’s easier for me to just downgrade and freeze the plugin back to where it works the way I’ve relied on it functioning up until now.

(Not to be critical of your work; it’s your code and you do with it as you will. It just seems my use-case was niche even until recently, and now it’s no longer supported at all.)

It looks like 1.6.1 now automatically adds a rel=”slb” (plus some slb_group) to image links pointing to url’s ending in a known image postfix. While a nice idea in theory, this does not work well with links pointing to non-image content that ends in an image postfix.

Steps to reproduce:
1. Create an image link pointing to a picture page in Wikimedia Commons.
2. Try clicking the link with SLB activated.

What happens:
SLB tries to lightbox the Commons page.

What I expect to happen:
I’d expect SLB not to mess with the link so that when I click the image, I’m taken to the Commons page as usual.

Other notes:
I don’t think there’s any way around this other than disabling the automatic rel=”slb”’ing feature entirely (which the plugin currently, AFAICS, doesn’t allow me to do). There’s no reliable way to determine a link *really* points to an image just by looking at the url.

Aikoinaan kun Squeezeä Lennyä testasin, tuota hidastelua aiheutti se, että Nautilus (tai jokin) halusi nuuskia verkossa näkyviä Windows-verkkokansioita. Sen keksittyäni sen estäminen oli helppoa, mutten kyllä enää kuollaksenikaan muista että miten.

Edit: Taisi olla niinkin vanha kuin Lenny se jota testasin.

Yksi helposti kokeiltava niksi on ottaa laitteistokiihdytys (Hardware Acceleration) pois päältä flashin asetuksissa. (Mikäli sillä ei ole vaikutusta, se kannattanee palauttaa takaisin oletusasetukseen.)

Mitenkä on, onko bugien raportoinnissa syytä olla tavallista harkitsevaisempi näin varhaisessa vaiheessa kehityssykliä (ennen feature freezeä)? Järjestelmähän on tässä vielä liikkuva maali, eli bugeja tulee ja menee jatkuvien muutosten myötä joka tapauksessa. Vievätkö bugiraportit tällöin kehittäjien resursseja turhaan, vai olisiko ongelmat päinvastoin hyvä raportoida mahdollisimman pian, jotta mahdollisimman monta myös ehditään korjata ennen julkaisua?