| Project: | Footnotes |
| Version: | 6.x-2.2 |
| Component: | Footnotes |
| Category: | bug report |
| Priority: | critical |
| Assigned: | AlexisWilke |
| Status: | closed (fixed) |
Issue Summary
You use a set of static variables that you do not reset. Maybe you should have used globals though... instead of having an $op variable...
Anyway, if you have a view with say 3 pages and each has [fn] tags, it does not work properly since the 2nd and 3rd pages will think that they already had some footnotes. And somehow, their text is empty (that, I think, is because you use an invalid index. Why don't you use the value as the array index?!)
I have a patch to reset the static on each call of the filter. See attached.
In regard to your comment: indeed, preg_replace_callback() is NOT a function one can use in a multi-threaded environment. So far, I have not seen a replacement for that function. You'd have to do a preg_match() and then do the replacements "by hand".
Thank you.
Alexis Wilke
| Attachment | Size |
|---|---|
| footnotes-reset-6.x.patch | 821 bytes |
Comments
#1
Hi Alexis
Thanks for the bug report.
Actually, the variables are reset as part of the "output footer" operation. The bug is that the newly introduced $used_values array is not reset. So the correct fix should be just a oneliner to reset that variable together with the others. (Even without views there is always the issue that a filter always parses both the teaser and the actual article, that is why resetting of variables exists even if I didn't test with Views. However with the new feature of reusing same label value multiple times, this bug was not caught in the superficial testing I did :-(
About thread safety: I again took a look at this issue and still can't see a way around it, since I have no way of storing things outside of _footnotes_replace_callback(). (For instance, I cannot pass in a referenced array during the callbacks, and I cannot even operate on the full text.) Writing the same functionality without preg_replace_callback() seems to be the only way out. Otoh, so far nobody has reported an actual bug due to "collision" of multiple footnotes threads...
Unless you post a simplified patch based on the above, I'll work on this in the very near future.
henrik
#2
Henrik,
I see the clearing of one of the arrays now. That would explain why the text was empty and yet it looked like another thing ran on that same node.
In regard to multiple threads, I'm thinking of PHP 6.x, in PHP 5.x, you won't otherwise have any problem. (i.e. multiple processes will work just fine, my site receives hundreds of hits a day without a problem.)
There is a new patch.
Thank you.
Alexis
#3
Btw, I do not yet have PHP 6.x, but if you have a Thread #, then you could use that to know which thread is accessing the arrays (with one extra level: $arr[$thread_id][$index] = ....
#4
I have committed the fix and released 6.x-2.3 so that people can download a working version. Thanks for the report and patch!
#5
Automatically closed -- issue fixed for 2 weeks with no activity.