Inline API: Solve all problems.

Some question arising:

• How is cross-referencing handled? There exists a timestamp if the current node changes, but what about the current node referencing an image in another node and that image changes? How can you make sure the cached filter output is invalidated? Or will referencing foreign data not be supported?
• "check_markup() does not activ(at)e the filter" seems to be not true. Is this a Contemplate specific issue?

Will this work?
[inline|cck_filefield_name=file.pdf]
Don't we need a fixed 'provider' identifier on the left side of the equal sign, to know which module provides the actual data replacement? That is, sort of
[inline|cck=filefield_name|item=file.pdf]

A quick review of the patch:

• _inline_filter_info() should have the $op as first argument, as everywhere else in Drupal.
• We should try to exchange the hardcoded file related code and replace them with generic API hooks. However, this requires us to define a tag format that is suitable for work with plug-ins. Note that I am aware of the fact this is actually a separate issue, but since it is critical for the final filtering results, I'm recommending to do it first. Otherwise we risk to end with a working filtering solution, but a tag format not suitable for plug-in extendibility.

Completely disable the filter cache for all input formats that include Inline filter.

Sorry if I sound slightly confused, but: wasn't the main reason for the switch to hook_filter() the ability to cache the filtered output (vs. hook_nodeapi() which has to process the node on every page view)?

Store cross-referencing information in a database table, as already suggested by benshell.

This approach actually looks interesting. IMO to be able to efficiently resolve cross-references we always need to store some information in the database, without taking into account the actual implementation we'll choose.

However, I'm a bit afraid that Inline tags would become cumbersome without any additional javascript supplying user-friendly widgets to automatically insert Inline tags.

Don't care for a moment about how cumbersome the result will be &emdash; this module should 1. work flawlessly and 2. its API serve as a powerful base for other modules to extend it. A TinyMCE extension would be purely for convenience and is not the topic of this issue.

such as Image Assist, which AFAIK has successfully implemented CCK support

From a quick peek I can say there is no CCK support. And filtering doesn't seem to take changed images into account.

While we're shaping the new features of Inline it seems like a good idea to point Ben to this issue and talk with him about his ideas since the mentioned post is already a year old :s.

Well I'm certainly late to the party here. :) A few comments first on background info:

Node id should be stored in a hidden tag:

- Would need to be extended for other Drupal objects, such as blocks or comments, which at least would need a block id or comment id to refer to additional object information.

Would it matter if the info was in visible tags? Seems that they would also need to be "extended" to include any necessary info also for things like comments or blocks.

Node id should be stored in a hidden tag:

- Would probably lead to inconsistent Inline tags, if multiple Inline tags in a content would refer to additional object information of different objects (f.e. a comment with an inlined file uploaded to the commented node and an inlined image uploaded with the comment using comment_upload module).

I'm not really clear on this one, but it seems that what is considered "inconsistancy" is just tags that only reference the relevant information.

Node id should be stored in each Inline tag:

+ Would be appropriate for a completely customizable plugin system (hook_inline) to allow integration of other modules with Inline.

I'm not sure why the info wouldn't be available to plugins either way. hook_inline would just get at the hidden tag info and pass it along to the module.

Node id should be stored in each Inline tag:
+ Node id info could be added upon save and removed upon view.

So the advantage is that it could be made into a redundant version the hidden tag approach? Sorry I couldn't resist. :)

Anyways, more importantly...

I see some references to fieldnames. Personally I think the fieldname should be included in the hidden tag as it's required for any intellegent processing of inline tags. (ie. user wants inlined images in teasers to be smaller, or wants large inlined images in a certain cck field) That's the reason it's included in my nodeinfo tags, it allows for processing flexibilty which is really necessary. There were 3 parameters in the hidden nodeinfo tag: NID, fieldname and timestamp. Also you don't want to let an author tell the filter what fieldname it is.

As for hook_inline capability, I see references to adding another tag parameter to indicate the module being used. Personally I think that's pretty sloppy. Hook inline should just base the hook_inline module to used based on the initial key in the tag: [inline=1] uses a module for older compatibility code, [image=1] use inline image module, [file=1] use inline file module, [audio=1] use the inline audio module etc. Much cleaner and more professional IMO. If it can't find a module match than it just leaves the tag alone (for another filter to possibly hit) I had already started some code for this but another project has come up. It's certainly doable though.

As for using content from other nodes, another table would seem to be the cleanest approach. Personally I think there are a lot of things to consider security wise when offering to include content from other nodes, which is a whole other topic.

As for filtering CCK field, I don't entirely understand what's being questioned. If you get a chance to go through my code you'll see they are being filtered and it is using hook_filter.

Node preview and initial node save not working.

I'm sure this just has to do with the hook_nodeapi implementation (and potentially issues with imagecache preview, imagefield preview or thickbox preview depending on what you're using) . If you walk through my code you'll see how these cases are handled via nodeapi though.

Really in the end I think it might be a lot easier process to just take my hook_filter and hook_nodeinfo code, rename "nodeinfo" to "inline-info", and question whatever you don't like during walkthoughs. There shouldn't be much (other then auto add code) in those two functions that you won't need in the end I think.

Subscribing.

Also, would it be useful to implement support for imagefield, whilst we're about this? It's something I've been thinking about, but given the present company, I'm pretty out of my depth.

I was just about posting an issue asking why we use hook_filter instead of hook_nodeapi after reading http://drupal.org/node/106249#comment-184886 :)

I found my answer in the fact that alterations of a node through hook_nodeapi are not cached. On the one hand, no cache, on the other hand, no context like $node. Is there a general issue for D7 on this ?