Posted by escoles on April 3, 2009 at 2:32am
Jump to:
| Project: | Rep[lacement]Tags |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I'm trying to use Reptags on D6. I've implemented it on a couple of D5 sites (where I mostly use it to create sitemaps, but have also used it to embed a webform in a block), and don't remember having any problems getting it to work. But this is my first time using it on D6.
What happens: When I insert codes to be replaced, nothing happens.
I've tried several variations on block, information, and node tags, and haven't been able to get any replacements.
I've made sure that user 1 has a role and that role has permission to use Reptags. I've triple-checked to make sure that the content type I'm using is enabled, and the reptag modules I'm trying to use are enabled.
What could I be missing?
Comments
#1
Had to leave off working with this for a while, but back to it again. I'm going to constrain the issue a bit since in the interest of sanity I'm really only testing one type of replacement.
I've done a fair amount of testing with menu blocks, in particular the Primary and Secondary links, and unfortunately I can only report very, very inconsistent behavior.
Here's the scenario:
I enabled Reptags.
Activate the Blocks replacement.
Set the permission for the role corresponding to my current user. (Since these are sites I'm just now building, and since I'm mostly work on dev servers, the user for all of these tests is user 1.)
Select a content type.
Create a new node in the selected content type.
Enter reptags for Primary or Secondary links nav (see following).
Result: Nav may or may not display. If the nav displays on load, it will continue to display until the node is edited, at which point it may or may not fail to display.
Whether or not the block will display seems to be due to some revertable characteristic of the node, because if I revert to a version of the node in which the replacement functioned, the replacement will function again.
I found after some brute-force experimentation that I could get nav to display if I used the following tag syntax:
{BLOCK:menu:Primary links}
But ONLY in some instances. I have not been able to reliably determine what those instances are.
The only thing that I believe I am able to say is that the tags will not work if there is no other content in the body field. E.g., there has to be sme copy in the body field -- simple empty HTML tags won't do (I tried using an empty paragraph tag so it would collapse and disappear), it has to be something that the filters can parse. I think.
I've seen this on two separate Drupal 6 installs so far.
Does anybody have any ideas why it's happening or what I can do about it?
#2
Some more data. It looks as though the P (paragraph) tag is the culprit: When the reptags are wrapped in P tags, the replacement doesn't happen in the expected manner. This is a problem at least with FCKEditor -- if I recall correctly, it will also be a problem with
that other one (not slighting it, just can't remember right now, too many migraines killing too many brain cells)TinyMCE, since they need to put everything in a block container and the default block container is 'P'.Using hard returns (
<br>) alleviates the issue but only slightly, and in an interesting way. See following examples.Given this code:
<ul><li class="first"><a href="/" class="first">Home</a></li>
<li><a href="/contact">Contact Us</a></li>
<li><a href="/privacy">Privacy Page</a></li>
<li><a href="/sitemap">Sitemap</a></li>
<li class="last"><a href="/rss.xml" class="last"><img width="16" vspace="0" hspace="0" height="16" border="0" src="/misc/feed.png" alt="RSS News Feed" /></a></li>
</ul>
<p>{BLOCK:menu:Primary links}<br />
{BLOCK:menu:Secondary links}</p>
<p>275 Lake Avenue, Rochester, NY 14608 Tel: (585) 935-7800 Fax: (585) 935-7805</p>
<p>©2008 Bivona Child Advocacy Center. All Rights Reserved.</p>
... the Primary links navigation will display.
If I change the section with the Reptags thusly:
...<p>{BLOCK:menu:Primary links}</p>
<p>{BLOCK:menu:Secondary links}</p>
...
... the result is that neither menu will display.
If I change it thusly:
...<p>{BLOCK:menu:Secondary links}<br>
{BLOCK:menu:Primary links}</p>
...
... the result is that the Secondary links will display.
Note that if I view source in any of these cases, I see no artifacts of Reptags -- i.e., it looks as though Reptags has parsed and discarded the tag it's not replacing.
If I go into text mode and manually edit the HTML to remove the paragraph tags, so it looks like this:
...{BLOCK:menu:Secondary links}
{BLOCK:menu:Primary links}
...
... then I can get reliable replacement.
Curiously, I also get reliable replacement of the tags if I format it like this:
...<div>
{BLOCK:menu:Secondary links}
{BLOCK:menu:Primary links}
</div>
...
This variation also works:
...<div>
{BLOCK:menu:Secondary links}<br />
{BLOCK:menu:Primary links}
</div>
...
Using DIV tags is a feasible workaround for FCKEditor, at least. But this is going to bite a lot of people on the butt unless they know to do this. (A lot of less sophisticated users will, like, totally tweak over having to learn what a "DIV" is. Seriously, though: my main in-house user and my next client-side user will probably handle it OK, but others will perceive this as something that makes them lose confidence in the system.)
Should I reclassify as a bug?