CCK textfield support

I can see the cause of this issue. We're doing:

function inline_nodeapi(&$node, $op, $arg) {
  {...}
          $node->teaser = _inline_substitute_tags($node, 'teaser');
          $node->body = _inline_substitute_tags($node, 'body');
  {...}
}

It looks like CCK support has to be implemented in a separate function.

If I'm right, the problem is that the inline is not using the hook_filter() properly. Using nodeapi for filter is not a good practice because it will filter the whole output note the given textareas. Can anyone confirm this? If I'm right, I'm going to implement a better inline_filter() .

Yes, that is true. hook_filter() does not have a reference to the node it is acting on. And Inline has to know that unless we have the new Inline API.

But let's stay on focus. AFAIK, CCK nodes are still regular nodes and they utilise the nodeapi. The sole difference is that CCK fields are not labeled 'teaser' or 'body' only. So from a high level view, the resulting fix for this issue is to search for node fields that are stored as textareas instead of simply testing $node->teaser and $node->body.

This may not be that easy because AFAIK node fields do not have properties at that time. So it might be required to execute some additional functions to retrieve the fields to which Inline filters are applicable. That additional code must not be executed if…

Hmmm, guys, did you already update to CCK 1.4 ? I've tried to reproduce this issue in my Drupal sandbox with a fresh CCK installation and a custom text field. Can't see any troubles there.

I am using Inline 5.x.1.x-dev with CCK and I am still seeing this problem. However, I am not using a "sandbox" and have a ton of other modules installed too, so my comments are probably not valid. Will have to do some testing it appears...

Sorry to double-post just wanted to clarify that I am using CCK 1.4 with Inline 5.x-1.x-dev.

@dr00b: Could you please write down the field settings of one of those fields that do not work with Inline? I checked against textareas (multiline text) only.

Hi,

I'm using inline in a cck (1.5) text area and hitting the same problem. inline images display fine in "body" but I just see the [inline:1] or [inline:image.jpg] text in the cck fields. This is using the same input formaton both fields.

Still seems to be using

      foreach (filter_list_format($node->format) as $filter) {
        if ($filter->module == 'inline') {
          $node->teaser = _inline_substitute_tags($node, 'teaser');
          $node->body = _inline_substitute_tags($node, 'body');
          break;
        }
      }
      i

Sorry for the delayed response.
I'm not able to reproduce the described behaviour. Inline works fine with CCK 1.5 and custom text fields, even text fields with multiple values. No matter if plain text or filtered text format.

Have you enabled Inline filter for at least one input format?

I have not been able to implement Inline 1.1 on my CCK 1.5 fields. It works fine on a body field in a Page content type, but not on the CCK fields.

I have enabled the inline filter on the filter types relevant to these CCK fields.

Any suggestions? Thanks!

can confirm this bug on 5.x-1.1 - I've enabled inline filter on input format. It works fine on "body", but not on cck text fields.

As I said before, it's using:

$node->teaser = _inline_substitute_tags($node, 'teaser');
          $node->body = _inline_substitute_tags($node, 'body');

which suggests it's not looking anywhere else for this.

The CCK content types have the option to not use the standard body field. If it is set to not use it, the inline files aren't being displayed correctly in custom text boxes, as in, they only display the unfiltered text "[inline:1]". If the content type is set to use the standard body field, the inline files in other custom text boxes display the file links correctly.
Content types that don't use the standard body field can be individually fixed by temporarily enabling the body field and resubmitting the content. This does not fix all of the same content types at once. The content must be individually resubmitted. Interestingly, the inline files continue to be displayed correctly in the custom text boxes even if the body field is again disabled.
This is the behavior I'm experiencing. Can anyone confirm this? This might explain why some people were not experiencing this bug.

We have CKK types from 4.7 when there was no body field option if making new content types, it's these that the filters doesn't work on, so I think you've found the source of the bug.

Here are my updated findings:

The problem is that the inline module can only filter the node body and teaser as a whole. It can't distinguish the filter type for individual fields made by the CCK. Short of creating a module specifically for integration with the CCK module, there isn't a way around this.
If a content type doesn't use the default body field, the format field in the node_revisions table in the database defaults to zero (no filtering). This causes the inline module filtering to not be triggered because of this:

foreach (filter_list_format($node->format) as $filter) {
        if ($filter->module == 'inline')

(for those of you who want a quick hack, just remove the foreach statement and the inline module will filter all text on all nodes)
Because of these limitations there are two options I see: filtering should be enabled based on node settings and not filtering settings, or it should be stated that CCK content types aren't supported.

Since CCK is the future, Inline will definitely follow CCK. I see two options to solve this issue:

• either implement the new Inline filter syntax (as also proposed in Inline API), automatically adding |nid=# to each Inline tag, allowing Inline to act as a regular (and cached) Drupal filter
• or add specific checks to the mentioned condition in #15 for CCK node types.

either implement the new Inline filter syntax (as also proposed in Inline API), automatically adding |nid=# to each Inline tag, allowing Inline to act as a regular (and cached) Drupal filter

caching is always good, and if the issue can be fixed on the back of new features, that makes sense as well.

Better title.

@all: Everyone interested in solving this issue should contribute to the Use hook_filter instead of nodeapi for Inline issue.

Inline API has quite evolved and should already support any node field that has an Inline-enabled input format assigned.