reptags + cck not working properly
westwesterson - September 3, 2008 - 04:18
| Project: | Rep[lacement]Tags |
| Version: | 6.x-1.x-dev |
| Component: | Code / API |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
reptags doesn't work with cck. I have enabled it for the node i am working on, and it only can see the body field. I have enabled the individual cck fields and i cannot figure out why this is not working.
#1
CCK for Drupal 6 is still a moving target, although we are getting closer to a stable release. I already adapted my local development version of reptag for CCK 6.x-2.x-dev, what means a CCK-compatibility patch will be available soon.
edit: ... the same is true for ConTemplate support ...
#2
i remember seeing a tentative release date for stable cck around mid September. So hopefully this will be very close.
#3
Duplicate issue
http://drupal.org/node/309354
#4
SiteWide tags work with cck-6.x-2.0-rc6. Any newer version breaks it.
#5
CCK devs (again) refactored field rendering/preprocessing. So I will have to update the code in reptag once again to get compatible. I'm really getting tired of major last minute changes. But hoping for no more surprises after RC7 I still need to figure out the difference between
$item['view'], $item['safe'] and $item['value']and what each value is good for. Anyone familiar with this?#6
My guess is it has to do with themed output. Found this info here:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/theme/R...
- $FIELD_NAME :
Contains the raw values of the fields, in the usual array-format used internally
by CCK. What you find in there depends on the field type.
Each value also contains a 'view' element, that holds the ready-to-display value
as rendered by the formatter. For instance :
array(0 => array(
'nid' => 5,
'view' => '<a href="node/5">Title of node 5</a>',
),
);
Raw data are *not* sanitized for output, it is therefore *not advised* to use them
directly. Use the 'view' value, or run the values through content_format().
that would leave me to guess that safe has the cck node run through the drupal security system, and that value is the raw data of the field.
There is some additional documentation here which is somewhat related.
http://drupal.org/node/191796
#7
Yes, it has to do with theming. The point is that atm it is impossible to predict what field is actually printed. By default its the 'view' field, but other modules (e.g. ConTemplate) use 'value'. Also there is
$node->fieldand$node->content[field]. While ConTemplate uses$node->fieldAFAIR other modules, like RSS or PrinterFriendly layout modes, use drupal_render() to transform$node->contentinto html for output. And finally a themer can ignore all this preprocessed output and simply use the raw value (although it is advised not to do this, but still check_plain($raw_field) is OK to use).All in all there are at least 4 places for each field that must be processed by reptag in order to get compatible with all possible output modes and modules. Thats not much of a problem to code, but it apparently adds a lot of (unnecessary) overhead. In general its a good idea to use a pull model, what means other modules should ideally call reptag_process to filter their output, but on the other hand that does not seem feasible right now as it requires additional code in CCK & Co.
I hope the debate about rendering modes for xml, html, json, etc in Drupal 7 will streamline the output process and make it easier for reptag to latch. But we need to find a solution for Drupal 6 now taking all the changes that have been made to the release candidates of CCK 6.x into account (e.g. build_mode feature that enables modules to add additional output modes).
#8
Another questions is: Do we need per field settings in reptag? Would it be sufficient to enable reptag processing per content-type, so that the replacement process happens for all fields of a particular content type?
#9
for my purposes rep tag per content type would be perfect, but I could see someone asking for field level permissions as a feature request.
#10
Latest -dev version of reptag should now work with CCK 6.x (post RC6) again ...
#11
After installing latest dev, I ran update.php and got the following failures...
Failed: ALTER TABLE {reptag_registry} ADD INDEX weight (weight)Failed: ALTER TABLE {reptag_registry} ADD INDEX enabled (enabled)
Failed: ALTER TABLE {reptag_registry} ADD INDEX static (static)
Failed: ALTER TABLE {reptag_registry} DROP PRIMARY KEY
Failed: ALTER TABLE {cache_reptag} ADD `serialized` SMALLINT NOT NULL DEFAULT 0
I ran update.php again and go no errors the second time.
Then when I tested SiteWide reptags, ALL my replacements were wiped out (the "tags" were still there though). So I manually went to Reptag settings to reinput every single "Replacement".
Now it seems like Reptags and SiteWide Tags work fine.
So for those with LOTS of reptags enabled... beware! You may have to reinput every single replacement...
#12
@spiffyd: I didnt make any changes to the table structure with the latest patch. Did you update directly from a 5.x release to the 6.x development snapshot? Or did you miss to run the updates before?
I will test the 5.x -> 6.x migration as time permits, but people already on the 6.x branch shouldnt have any additional updates to run.
#13
@#12, No. I am using 6.4 and I updated from the previous latest 6.x dev snapshot to the this latest one.
#14
The latest dev on 2008-Sep-29 broke CCK+SiteWide Tags functionality again. Had to revert to a previous build.
I am using cck-6.x-2.0-rc7.
#15
yup, still not working here. just tried it on my installation. And I got the same errors as spiffyd too.
#16
Can any one confirm whether CCK 6.x 2.0 rc9 fixes this or the problem still exists?
#17
I believe this problem may still exist? I got the following after updating drupal to 6.6, CCK to 6.x-2.0, CCK Blocks to 6.x-1.1 and Reptags to the latest (Sep. 28) 6.x-1.x-dev:
* user warning: Duplicate key name 'weight' query: ALTER TABLE reptag_registry ADD INDEX weight (weight) in /home/path/mywebsite.com/includes/database.mysql-common.inc on line 434.* user warning: Duplicate key name 'enabled' query: ALTER TABLE reptag_registry ADD INDEX enabled (enabled) in /home/path/mywebsite.com/includes/database.mysql-common.inc on line 434.
* user warning: Duplicate key name 'static' query: ALTER TABLE reptag_registry ADD INDEX static (static) in /home/path/mywebsite.com/includes/database.mysql-common.inc on line 434.
* user warning: Can't DROP 'PRIMARY'; check that column/key exists query: ALTER TABLE reptag_registry DROP PRIMARY KEY in /home/path/mywebsite.com/includes/database.mysql-common.inc on line 386.
* user warning: Duplicate column name 'serialized' query: ALTER TABLE cache_reptag ADD `serialized` SMALLINT NOT NULL DEFAULT 0 in /home/path/mywebsite.com/includes/database.mysql-common.inc on line 298.
Edited to add: Forgot to mention, Reptags stopped rendering tags completely after the above updates, and when I fired up my tags admin console I found that everything I had put there was gone.
#18
I got the same error message as silurius above when updating to the latest reptags release and cck 2.0.
#19
I think I am getting the same problem with no replacement in CCK text fields: cck-6.x-2.1, reptag-6.x-1.x-dev.
I think I have the field selected as replaceable in the content types config ok for reptags (see attached images).
I make very heavy use of RepTag (for which module I am very grateful), both in node body and fields, so I am
very interested in any news on progress on this. I need to make a decision soon on whether to persist with
$reptag$ content in fields for a high content site (am willing to use devel status updates for it). Many thanks.
#20
Subscribed. I am anxiously awaiting reptag compatibility with the latest CCK.
#21
I believe I'm seeing this, too. Using a CCK field to display sidebar content, and when I try to insert a reptag, it seems to just never parse it -- leaves the tag there.
Reptag 6x-1x-dev, most current available build, plus CCK 6.x-2.2.
#22
$bump$ {bump} $cck$ {please}