MY b2evo version: 1.9.2 and 1.8.7 and 0.8.6 (and I sure would like to see what 0.8.2 looked like!)

It depends on what you're changing. If all you change is the mechanics of how your plugin does it's thing then nothing more than re-loading the page where the plugin rendering would be visible should be required. If you are changing something deep like the database your plugin builds, or even the available settings your plugin will use, you will certainly want to increase the rev number and then uninstall and reinstall the plugin again. In the case of using a preview to check the results, I'd close the preview window and re-preview. Actually I'd save a post in protected mode and reload it just in case preview does weird stuff. Just in case...

I'm no expert on this topic! Just sharing what I learned the hard way when writing a couple of simple plugins. Once I actually found a bug, but it took TONS of trial and error to be sure I was dealing with a bug and not something I was doing wrong.

It's not much, but I hope it helps some. BTW if I remember to after I post this I'm going to move this to the plugins help request forum since you're asking for help developing a plugin.

If you add/remove events from your plugin you must go to your plugins settings and just click save or whatever so the event gets enabled.

And there's also the pre-rendered content cache which needs clearing ;)

¥

I tried saving the post instead of previewing, and using the 'delete prerendered cache' (which I assume means 'clear' - not delete the actual cache). I also tried reloading the page in my browser. I even tried closing the browser window. Changes to the plugin code showed up one time when I viewed the test post, but now no combination of these things has gotten the changes to show up. Here is the code I am changing:

  function RenderItemAsHtml( & $params )
  {
      $params[ 'data' ] = preg_replace_callback( '#<div class="xx">([^>]+?)</div>#i', array( & $this, 'codeBlock_callBack' ), $params[ 'data' ] );
  }

  function codeBlock_callBack( $matches )
  {
    return 'you will be assimilated';
  }

Earlier I had something else in place of 'div class="xx"' and '/div'. That didn't work - no substitution was made. When I changed the code back to as it is above, I could not get the replacement text to be substituted.

Here is a test post:

<div class="xx">
<p>
here is text to be replaced
here is more
hhh
</p>
</div>

I also tried removing the lessthan p greaterthan elements and that seemed to have no effect.

Another question I have is about the 'priority' value in the plugin. I searched the forums and docs and could find no info about this field. I made the priority 80 because that's what the smiley plugin uses, but I have no idea how to decide upon a good value for this setting. It's unclear whether a high value means the plugin gets processed earlier, or whether a low value means the plugin gets processed earlier. In fact it's unclear what effect the priority value has at all. Is there some documentation about this?

What I really want is to at least try out recognizing lessthan code greaterthan XHTML elements. When I tried changed the regular expression to recognize code elements instead of div elements, I couldn't get the text substitution to show up. I can't tell if this is because of the non-update problem, a problem in the pattern recognition, a problem with the priority (maybe some other plugin is already processing these elements?), or something else.

The lower the priority number the quicker it gets applied, which may be part of why your not seeing rendering. So imagine plugin "foo" does something to an image tag, and has a lower priority than the smilies plugin. Foo will not affect the smilies image tag because it doesn't exist yet. Change foo's priority number to something greater than smilie's and suddenly foo will do it's thing to the smilies.

Also AFAIK the inclusion of the divs happens after rendering happens, meaning a renderer won't find "<div class="xx">" because the post is not stored in the database that way. Unless you're posting with divs in the textarea, or your plugin has already added those divs to params[data]. I could be wrong on this given that I've never actually drilled down into this detail.

Ah. Well I had tried changing the priority and it seemed to have no effect. I still am not sure how one goes about choosing the priority.

The substitution of 'div' elements does happen sometimes. I had tried including 'div' elements in the original post that I typed in. In fact that is the only substitution I was able to get working - with 'code' I couldn't get anything at all to happen.

Your problem is the regex ;)

'#<div class="xx">([^>]+?)</div>#i'

Which equates to " search for all blocks that start with '<div class="foo">' and keep going 'til you meet a '>' and then check that it's '</div>' " ...... ish

If you replace the '[^>]' with '.' then you'll probably get further before you run into other problems

¥

I was just using the regular expression that you gave me here! http://forums.b2evolution.net/viewtopic.php?t=10756&start=30

I tried changing the regular expression and didn't notice any difference.

LOL ... that would likely fall under the "ish" disclaimer that ¥åßßå so often employs. (I've learned that he likes to crack open the door, but leaves it to you to enter and sort out [a few] of the details). ;)

I'd recommend looking @ line 92 of _am_code.plugin.php, it might help?

Thanks, maybe I will do that.

By the way, what is the purpose of the '#' at the start of and the '#i' at the end of Yabba's regular expression?

$params[ 'data' ] = preg_replace_callback( '#<div class="xx">([^>]+?)</div>#i', array( & $this, 'codeBlock_callBack' ), $params[ 'data' ] ); 

# is simply the REGEX begining|ending delimiter (I've seen it more commonly as a forward slash /)

However, if a forward slash is used, in combination with escaped characters, the REGEX can look like a badly aligned combination of "/\</\\/s" ... and is difficult to read.

I think that's why ¥åßßå often uses #, instead.

AFAIK, the trailing 'i' means "case Insenitive".

When testing, you should always use something simple, like just

function RenderItemAsHtml( & $params )
{
  $params['data'] = str_replace( 'div>', 'h1>', $params['data'] );
}

to make sure the error is not there.

There will be at least one little bug be fixed in 1.9.3, so this may help in this regard. There may still be other bugs according to the pre-rendered cache of course.

EdB wrote:

Also AFAIK the inclusion of the divs happens after rendering happens, meaning a renderer won't find "<div class="xx">" because the post is not stored in the database that way. Unless you're posting with divs in the textarea, or your plugin has already added those divs to params[data]. I could be wrong on this given that I've never actually drilled down into this detail.

Inclusion of what divs? b2evo itself does not generate DIVs automatically as far as I know.
It only replaces e.g. the more anchor and "read more" link.

btw: http://php.net/pcre might be interesting to someone.. :)

It is not likely that the error is in the regular expression, because once in a while it works.

..what might depend on the post content!?

It's likely that there's a bug somewhere, but it makes finding (being able to reproduce) it much easier if it's for sure, that it's not the regular expression.

You could even use $params['data'] = 'TEST!'; instead.

I am not sure this completely explains what I've seen, but could it be that plugins are not used when a post is viewed in BackOffice (in a URL ending with something like 'blog/admin.php?ctrl=browse&blog=0'), but BackOffice still updates the cache?

blueyed: what I was thinking of was the divs that the skin will wrap various bits of the blog in. Typically a bPosts for the actual content eh? AFAIK plugins do their rendering before the skin gets to decide what divs to put various bits into, meaning there's no divs for the renderer to find. Unless the post content is stored with a div in it, which seems to be the case here.

EdB, the bCointent DIV comes from the skin. Never mind, it does not seem to be important.

AndrewShapira, once a post gets viewed (backoffice or frontoffice should not matter), the content gets rendered and then stored in the render cache. Afterwards it gets pulled from there.
When only previewing a post, the rendered content does not get saved into the cache. All AFAIK, I've not looked at the code right now.
I really need a procedure to reproduce this.

I am not talking about previewing. I am talking about viewing an existing post in BackOffice. I gave a URL for the type of viewing that I am talking about. I don' t know the right b2evolution terminology for this kind of viewing. Maybe it's called "BackOffice browsing". As I said, I do not even know if this causes the problem. I was asking whether it might.

Yes, it might.