WordPress antaa säätää kommentoitavuuden postauskohtaisesti, eli jos julkaisit tuon ennen kuin olit ruksannut mainitsemasi valikkokohdan, siinä julkaistussa on vielä vanhan asetuksen myötä kommentointi suljettu (tuon yleisasetuksen muuttaminen ei vaikuta vanhojen postausten kommentoitavuuteen). Postausten muokkausnäkymässä, ylälaidassa on (suomenkielisessä wp.comissa) ”Näyttöasetukset”-namiska, jolla saa muokkauskilkkeitä piiloon ja näkyviin. Yksi niistä on ”Keskustelu”, jolla sen postauskohtaisen kommentoitavuusasetuksen (”Salli kommentointi”) saa näkyviin, jollei se jo ole.

— 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');
     	}
 }

If your theme has a searchform.php, you’re probably hitting Ticket #16541: get_search_form() ignores $echo if searchform.php exists.

Your workaround is fine if you’re just echoing the search form anyway, but if you need to capture the output in a variable, you can work around this with output buffering:

<?php ob_start();
get_search_form();
$my_search_form = ob_get_clean(); ?>

For the image labels, you could publish a brief spec/howto of how you create the default labels, crowdsource translated versions and then pick the right one in the code based on current locale.

But then again I think simple text instead of images would work even better. I’m not sure what you mean when you list ”Style (e.g. prev/next buttons) cannot be customized”: surely that applies to images more than text, which can be bent any which way with CSS?

Köhöm, WordPress != WordPress.com (mikäli ulkopuolisella alustalla jälkimmäiseen viitattiin).

Mutta asiaan: onko tuo looginen captcha yleisessä jakelussa oleva Drupal-lisäosa vai talon sisällä kehitelty? Onko se tehokas? Kiinnostaa, koska se on täysin suomenkielisenä poikkeuksellisen käyttäjäystävällinen.

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.

Is it just me, or do the plugin’s settings get reset back to defaults with each update? Is this intentional and if so, why?

This looks related to a test case I was preparing to demonstrate how flawed the output from wpautop can get inside lists:

<ol>
<li>
foo

bar
</li>
</ol>

renders as:

<ol> 
<li> 
foo</p> 
<p>bar
</li> 
</ol>

whereas I’d expect it to be

<ol> 
<li> 
<p>foo</p> 
<p>bar</p>
</li> 
</ol>

I’m changing the summary to generally cover wpautop’s problems within <li> elements.

Apparently either results.php or head.php (in view/admin/) refers to an image called small.gif by a path that doesn’t work: every time I use Search Regex I get 404 hits for a ’/images/small.gif’, when it should in fact refer to [site root]/wp-content/plugins/search-regex/images/small.gif. Apparently $this->url() precluding the path in the code doesn’t work — maybe $this is out of scope?

On a hunch, I instead opted to change Upload Url Path (of the main site) to point to where Fileupload Url already was pointing, and lo and behold, now the uploads get url’s with a /files/ base (which I feel is best).

Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base (like I mentioned in the previous comment), as if Upload Url Path didn’t have an effect. There doesn’t seem to be a Fileupload Url setting there — perhaps it’s deprecated? (The testing site runs trunk, whereas the main site runs latest stable.)

(Usually it’s the other way round: something that works in testing won’t work on the production site.)