plugin development / caching issue

Hi Ty,

I’m probably going to be way off here but how exactly are you storing the number after it has been incremented? Also how are you setting it in the first place?

If you aren’t storing the new value anywhere then each time the plugin is called then it is just going to restart it’s programme as it were and so always start from the beginning again.

If you were to store the new value in a database table or perhaps a session variable (all depends on what you are using this for or if you need the values to carry on between users) then you should theoretically be able to pull back in that value at the start of the plugin to set a start value.

Hope that helps a bit and hopefully I haven’t got the completely wrong end of the stick on this one.

Best wishes,

Mark

the value is updated in the database and then the new value is read and stored in $SESS->cache for subsequent non-new=”yes” calls to the plugin in case the user needs to print the number in multiple places.

The updating/storage part of this plugin works just fine as you can see in the second test result I pasted above. All users are updating and reading from the same field in the DB so the IDs generated are unique across users.

furthermore if I print entry and exit from the plugin you can see that it only gets called three times: 1 for {exp:unique_id}, 1 for {exp:unique_id new="no"}, 1 for {exp:unique_id new="yes"}. The plugin doesn’t bother executing again if the plugin parameters are identical because I guess EE decided that parameters are the only determining factor in output?

entered
new = 
updating
new value: 1040
return value: 1040
exited

entered
new = no
return value: 1040
exited

entered
new = yes
updating
new value: 1041
return value: 1041
exited

Hmm that’s truly interesting and not something I’ve ever come across before. Sorry I missed your second part of code in your first post. I’m really not certain why in your second test that works yet the first doesn’t.

I think this will definitely have to be one for the dev crew here as I’m really not sure why it would be doing that. Also I’ve never really used the $SESS->cache so not really sure how that all works.

Seems from what you are saying though that you have what I would think is the plugin setup correctly but there’s definitely something hokey going on there.

Hope you get a reply from the moderators / dev crew on this one as I’m interested in this myself now.

Sorry I couldn’t be of any more help on this one though.

Best wishes,

Mark

any EE devs lurking out there know what’s going on with this?

this also has another interesting side-effect:

{exp:unique_id}

{exp:weblog:entry_form weblog="content"}
<input type="text" name="field_id_4" value="{exp:unique_id}" />
{/exp:weblog:entry_form}

results in:

entered
new = 
updating
new value: 1055
return value: 1055
exited

1055
<input type="text" name="field_id_4" value="M00o93H7pQ09L8X1t49cHY01Z5j4TT91fGfr">

(SAEF code removed for brevity)

sending a unique garbage parameter to the plugin solves the issue as above… indicating the same caching ‘feature’ is at fault.

I’ve been developing another plugin that is crippled by this issue.

I finally decided to investigate this issue myself and the core code responsible is line 884-891 of core.template.php:

if (stristr($raw_tag, 'random'))
{
    $this->template = preg_replace("|".preg_quote($chunk)."|s", 'M'.$this->loop_count.$this->marker, $this->template, 1);
}
else
{
    $this->template = str_replace($chunk, 'M'.$this->loop_count.$this->marker, $this->template);
}

The first issue is that this is completely undocumented and took ages to pinpoint (a couple hours feels like ages when going through the template parsing code 😛). It would’ve saved a whole lot of time if this was mentioned somewhere in the plugin or module development docs.

Second, If the plugin’s tag has the word “random” in it, it won’t have this caching performed, otherwise it will. the word “random” doesn’t fit terribly well into my plugin’s title or parameters and I’d rather not have to have the user have to remember to put the word ‘random’ into every plugin tag call. Maintaining a core hack is equally obnoxious. Could we look at what it would take to allow the plugin itself to indicate whether it should act as random or not?