Hello..

Sorry if this is the wrong way to approach this, but I've been customizing inline.module to fit better with how I'd like to see it function. I think some of the features might be of interest, however it's a rather fundimental change of the base code so I don't think submitting it as a "patch" would be appropriate.

In a nutshell:

  • Uses hook_filter when making the replacements so that caching can be used (hook_nodeapi is just used when adding/updating content to store or strip a small nid/field tag that is invisble to the user)
  • Looks up [photo] or [image] tags to inline cck imagefields on the node
  • Added CSS class information based on mime type
  • Automatically alternate inline-even and inline-odd classes to to inlined images so that alternating classes can be used. (ie right side then left side, etc)
  • Can take an optional argument for an additional class to apply to the image or file link ie. [photo:4=My Photo:crazyborder] would add a class of inline-crazyborder to the photo

Etc...

Anyways, I'm still polishing up a few things, but it's working well. Because their is such a fundimental change (_filter vs. _nodeapi for tag replacement) I wasn't sure if this is something the maintainers are interested in or if I should just create a new project down the road when there is time.

As I'm pretty burried with development work right now, but I'd be happy to post the file once it's complete and you can integrate whatever you want. Just don't have time to particpate a whole lot more right now.

Let me know.. :)

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Great to hear. You really shouldn't create a new project for a module with similar functionality. Create patches against Inline instead.

My first question is: how are you implementing specific image/attachment assignments in the form of [inline:3] resp. [inline:myfile.pdf] with hook_filter()? Because AFAIK hook_filter() does not know which node is currently processed. Many people are using Inline just because of that - placing a particular image or attachment at a particular position.

Richard Archer’s picture

Richard Archer commented

I also wrote a hook_filter patch a long time ago. It won't apply, but the logic should still be valid:

http://drupal.org/node/32093

http://drupal.org/files/issues/inline_use_filter_not_nodeapi.patch

Moonshine’s picture

Moonshine commented

Your correct, hook_filter just sees $text and has no access to node information. (From what I've read this is because anything "could" get filtered, not just nodes. Like say the site slogan.) So I was left with two choices. a) hacking filter.module - No thanks! or b) give hook filter access to it, which I did via a small tag that's automatically prepended to the content field being filtered.

I currently have it tagged in the form [node:$nid:$field]. It's automatically inserted via nodeapi:submit (right after clearing anything a tricky user might try to add by hand :) ) and removed via nodeapi:prepare so the user is never aware of it when editing, etc.

Then hook_filter just takes that info to start (and removes it from the text), does node_load and processes things.

Once I'm done cleaning up I can post a patch against inline.module, the only thing is that I've actually modified a lot of other things (including the help, css stuff, etc) so I guess you'll want to pick and choose what you may want to use.

I literally started out wanting to change a couple things which I was going to submit. But then at some point along the way I just decided to run through it and make it work exactly like I wanted from the ground up. (I plan on using this module a lot) It's working fine at this point but I'm not completely finished. Still have some work on letting it fiter individual CCK text fields that are marked with filters that include inline.

Overall I think the inclusion of the a small [node] tag that nobody ever sees is a good tradeoff though. Especially when delivering a page with 15 teasers or so that can now be fully cached.

Moonshine’s picture

Moonshine commented

I guess I should have made this more clear, but the tag is really [node:$nid:$fieldname] so for example [node:212:body] or [node:121:teaser] might come through. Or what I'm working on right now something more like [node:141:field_description] -- a cck field.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

@Richard: Thanks for this pointer. Seems like that issue was lost during a clean-up...

It seems that the key for using hook_filter() is:

function _inline_substitute_tags($text) {
{...}
    // retrieve from db all files for this node and store them in an array
    $result = db_query("SELECT * FROM {files} WHERE nid = '%d'", arg(1)); 
    for ($i=1; $a_file = db_fetch_array($result); $i++) {
      $fileinfo[$i] = $a_file;
    }
{...}

That patch for Sidecontent module also relied on a node id somewhere in the url. So Inline tags have to be extended with the actual node id to use hook_filter(). However, this is what the draft for Inline API already states for a quite some time. Storing the nid in each tag (i.e. [inline|nid=123|...]) is definitely the basis for many other improvements we can think of (see Inline API issue for details). Any opinions or information related to this should definitely follow-up Inline API or New Inline filter code. Anyway, well proven Img_assist module uses pipes (|) instead of colons (:) as delimiter which allows URIs in the tag arguments. Inline should benefit from that, too.

Why do you want the name of the content field in the tag?

Moonshine’s picture

Moonshine commented

Not sure if that question is for Richard or me... but a couple things..

I didn't put the node info "inside" the inline tags as it seemed a little repetitive for a piece of info that is just unique to the node/field rather then each inline link in the fields. Maybe I'm misunderstanding though, I am new to Drupal.

As nodeapi has access to $node->nid, that is what I'm automatically adding (and hiding) for the nid. Doesn't depend on arg() or anything in the url as that won't work in some cases.

I added fieldname in there because the inline filter needs to know how to do the replacement for images. When run through hook_filter you just get text and have no idea if it's a "teaser" or "body" or cck field, etc.

For example I have larger imagecached/greyboxed linked images in the body and then smaller ones in the teaser. So at this point passing the fieldname is mainly used to key what image sizes are used. Unfortunatly I just realized that inline is really only set up for a body or teaser size specification w/ imagecache. So in the case of CCK fields I'm sending in "body" for sizing currently.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

If I understand you right, your third argument is actually not the CCK field name but rather the imagecache preset you want to apply to an image. I.e.

[inline|nid=123|imagecache_preset=teaser]

suits your intention best.

Bearing the goals of Inline API in mind, we might start to implement the new syntax along with support for the parameter nid. That sounds minimal, but we also need either backwards compatibility support, a quite expensive database update or at least an update function that is invoked on hook_nodeapi(), similar to the already existing function _inline_replace_numbers().

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (duplicate)

Marking as duplicate of http://drupal.org/node/163806