Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Just evaluating this version on a clean install, D5.5, sIFR from CVS DRUPAL-5.
Got it working.
Small errata. sifr-README.txt has instructions to install the 3rd party distro into modules/render/sifr/
I instead placed it in modules/render/plugins/sifr/ As I guessed that was what was meant. It was :-)
The help page (good help in general BTW) refers to http://sifrfonts.com/ which is now a squatter domain.
Simple so far. I liked the auto-examples in the rule editor.
But when I changed my rule [.node h2] to [.node h3] it didn't work - the files/render/sifr-rules.js was changed - but to the old values.
Saving AGAIN did work.
It looks like the order of operations is backwards somewhere - save, then update the rule definition. Are you using caching somewhere?
work-around so far is to save everything twice.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | render-DRUPAL-5.rule-update.patch | 1.63 KB | sun |
Comments
Comment #1
dman commentedI guess this comes under the 'component' issue queue
Comment #2
sunThanks, I've removed that link.
Actually, Dynamic Rendering searches for the 3rd party plugin directory, so both locations are working.
Regarding the rule update bug, I've no clue currently. Did you look into the actual sifr-rules.js file or did you view it in your browser? While working with this module, I discovered that some browsers do not immediately update their cache after the file has been rewritten. Thus, one needs to click on "Rules" (loading the rule overview again) to have the updated rules applied.
Comment #3
dman commentedNo, it was definitely the filesystem file that I checked.
I'm aware of hard-cache-clearing [CTRL-F5] being needed for scripts often, but the problem is visible in the text editor.
The file actually does get touched "File has changed on disk, reload?" when I submit a change, BUT the new file contains the old setting. Saving a second time with no changes works. As does using the modules 'flush cache' after every change.
Regarding the recursive directory searching, I also found it was scanning, finding and using the contents of "uncompressed js source (do not use)" that came with the sIFR distro. Following the hint from the dirname I decided not to use it... renaming it to ".uncompressed js source (do not use)" was enough to hide it from the plugin scanner.
When I saw how random the scanner was behaving, I did figure that the module directory issue was probably being recursed...
Comment #4
sunMeh. The cause for this bug was pretty trivial. All rules are statically cached within one request - since Render already runs early on each page request and populates this cache, the edit form is submitted and new files are written, but render_get_rules() returned the previously set and cached rules only.
Committed attached patch to all branches, along with some other fixes.
Comment #5
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.