CCK fields (filefield,imagefield,emfield) and fieldgroups for Inline API

anyone working on this?

Hi, I am interested in this functionality and I could spend some time developing it.
But right now I don't know much about CCK or Inline_API, yet.

Is the basic idea working already? Just to see a rough results. Sorry, but I could not even make inline_filefield_inline() to be invoked at all :|

As a side note, I tried the http://drupal.org/project/filefield_insert but it does not fully satify me, a filter based solution is more flexible indeed.

Thanks,
Antonio

Ok, after reading the Inline doc at least I managed to call the hook using [inline_filefield|file=1], even if nothing happens it is a first step.

It looks like the render op is never requested, I'll let you know if I figure out anything.

Ok, here's a first working version.

Attached is a patch against previously posted code.
An inline_imagefield module can be done with the same idea, which would be great!

Regards,
Antonio

Hi,

now the module (attached) works also with imagefield and thanks to the CCK api it handles automatically the case of imagecache installed. Still not complete: it misses proper context detection (teaser/full body) and it looks like the filter does not work in teaser mode at all.

A review would be appreciated, maybe even from CCK people?

Thanks,
Antonio.

I'm interested too, I'll try to have a look at this.

Ok, this version looks usable to me, now I can detect the right context for the fields, and the issue with fields missing in teasers was due to #442016: Images are not displayed in excerpts because nid parameter is missing.

Attached version 0.2; should I resubmit this as a patch against the inline module itself?

Ah, file detection during preview is still missing: I don't know yet how CCK/filefields handles uploaded files, any hints?

Thanks,
Antonio.

Hi Ao2, here are some problems with your module :
- you're supposing that the fields 'field_file' exist for Filefields, and 'field_image' for Imagefields, but the part after 'field_' is the field name as defined by the admin and is different on each website
- then you're supposing each of these fields do have values, but they don't always have

You should :
- detect the fields the node has, and select the Filefield ones and the Imagefield ones
- for each, test if there is a value before doing anything else

Otherwise it works !

Yes, guix, you are obviously right, the simplification helped me during development, but wasn't meant for the final version.

I already fixed that and the result is that the module could be generalized to support any other field! However right now it only recognize the 'filename' field parameter. Moreover I will see if the code can be simplified using content_view() and drupal_render() calls.

I thought that the module could use a syntax similar to [inline_cck|type=filefield|index=1] but that needs more discussion, and I'd like to hear Inline API devs and CCK ones too.

Now it also supports preview when editing an already existing node, I don't think there's a clean way to have preview for newly created nodes as well, see the comments insde code.

Also in the archive you can find a NON working module for inlining fieldgroups, any help is appreciated here as well :)
node_load_content() gives WSOD. But Mybe I should open another thread for this...

Regards,
Antonio

Hi Antonio,

OK no problem, anyway it wasn't hard to spot. I haven't tried your latest version yet but will tomorrow, however one thing is I guess like you said that fieldgroups should have their own issue & patches.

The other thing... but first let me congratulate you especially on the node/teaser context detection, which is very drupalistically talking awesome :D
The other thing, and it's totally subjective and maybe not very Drupally, that I think we should provide more flexibility in the output. If you have time I've just posted in the WYSIWYG group a point of view on Inline + WYSIWYG. See especially STEP 1 : manual insertion of the tags + imagecache preset + display method + overridable template files at the theme layer.

To sum up, I'm proposing an optional output "method" that could be added to the tag, like : [inline_filefield|file=N|method=METHOD]

If there's no method parameter, the output would be the default module version, as you're defining it in your module : depending on the context. If a method is provided, then the method would only take the $field array and would allow any kind of output with it. The output would be defined in kind of a content-field-FIELDNAME.tpl.php in the theme directory, except it would be a content-field-FIELDNAME-METHOD.tpl.php. That would allow an infinity of Fields output, and variety is important especially for images. In the drupally way, we can just specify an imagecache preset for the teaser, and another one for the node. But inside the node, it would be nice to have tags that allow to mix different imagecache presets, and maybe more : same preset, but inside a right-floated div, or left, ... anything.

Let me know what you think about it.

About inserting inline macro automatically I thought something along the lines of http://drupal.org/project/filefield_insert could be used as a starting point. See its issues, there are some common problems discussed there.

About supporting different display methods, I am not personally interested in adding them, but I agree it would be a useful thing for many. Better to add that in a later version tho. First things first?

If we lack time/motivation I guess a basic extra_class parameter to add custom style at css level could alleviate the problem you arise. And this should be fairly easy.

Anyhow, your approach sounds more than reasonable to me, but my limited knowledge of drupal doesn't allow me to comment more in depth.

The question on which I'd concentrate for now is: should we support arbitrary field types? What interface to use to do that?
And: is the content traversal done the right way? or we should use some other APIs?

Thanks,
Antonio

inline_cck would be nice indeed and could handle the tags for CCK fields and their output. On the usability side, we would need tags generators, that could work like in the filefield_insert approach or better, like image_assist with WYSIWYG API.

As for the display methods, I agree with the "first things first", only that if we want to do this at a later stage, better think about it a little now.

Just thinking out loud anyway, let's see what the Inline & CCK people say !

For my "problem" I don't think CSS is enough since I want to output the Imagefield descriptions too, so I think I'll end up with my custom Inline module for now and my custom tags (and I must acknowledge your module was of a great help for me !). I'm using a method parameter but all the methods are hard-coded in the custom module.

Hi guix.

You can record me as very interested in your vision for CCK/Image API integration. That's exactly how I'd like to insert media in my nodes (I'm mostly thinking of filefield/imagefield and emfield, there; lightbox2 should fit in the picture admirably), with possible captions and other media-dependant metadata.

I don't have that much spare time these days, but I'd be pleased to lend a hand. Antonio's module looks like a damn good start.

Hi mt-i,

Here's the code I use, of course anything could be done like lightboxes. It's based on Antonio's module v0.2, so the fields must be field_filefield for files and field_imagefield for images. I'd like to see the "methods" elsewhere like in the theme folder, I'd just need to know how to call them properly from the module, like at line 114:

if (!empty($params['method'])) {
  [call_the_theme_file_named_inline_method_METHOD.tpl.php in the themes folder]
}

There's no WYSIWYG integration so far, also. The tags must be like [inline_imagefield_methods|file=N|method=right]

I found these developmets interesting, but I couldn't understand if using this module we will can add images from nodes different from the current one.
I'm thinking about let the user re-use images from imagefields in old nodes, just inserting a tag.

For the moment no, but I want that too !

@gerlos: I haven't tried that, but that could be working already. Try specifying the nid parameter, example:

[inline_filefield|nid=x|file=filename.ext]. Where x is the id of another node, and filename.ext indicates the file you want to embed.

Regards,
Antonio

@gerlos: I verified, and inlining fields from other nodes works quite well.

Moreover I added support for inlining emfields, really useful.

Note that the module is called inline_field now, because it can inline different fields types, this is an example of its use:

Testing emfield in this node (nid=7):<br />

[inline_field|nid=7|embed=http://www.youtube.com/watch?v=0Q2aPi9ZEgs]

Testing inlining content from another node (nid=3):<br />

[inline_field|nid=3|file=drupal_logo.png]

Wow, both work!

If you experience problems inlining complex objects check you Input Filters chain, some filter applied before Inline can alter the inline macros and drive to unexpected results, other filters after inline can strip or modify the results.

I think we need to advertise this module a little more in drupal community, it has a great potential :)

Regards,
Antonio

Interesting work again Antonio ! I still need to find how to implement my "methods" in a clean drupal way ;)

It's more concerning Inline API itself, but two questions :

1) why allowing 2 ways of selection (by filename or FID for example) ? Shouldn't we focus on 1 way to do it for CCK fields which can be identified by their # in the DB (at least those I know : filefield (and imagefield)). However leaving another kind of "manual" entry in Inline API is nice if you want to insert other things that are not fields.

2) I wonder if the tags couldn't be less complex. Let's use the filefield file as an example :
[inline_field|file=drupal_logo.png] OR [inline_field|file=N] => seems good (where N is the number of the drupal_logo.png file in the DB)
[inline_field|nid=3|file=drupal_logo.png] OR [inline_field|nid=3|file=N] => if we know the filename or the # of the file in the DB, couldn't we omit the nid parameter ? I understand the nid has to be known to check for example if the user has access to the node and therefore its fields. The nid could be found back at the cost of a query per inline tag. Which brings the question : is there any kind of cache for Inline API ?

Yay! Thanks for your work on this!

But why do I see only archives attached to this issue? Can you do a proper patch instead? cvs diff -Np should do the trick. See http://drupal.org/handbook/cvs/quickstart for more info.

@guix:
about 1) I am ok about simplifying the macro format, I just don't know if there is a global unique identifier for fields, I need to find out that. But in the end this could even turn to be unimportant if we have a way to insert a macro with zero typing, I mean a-là filefield_insert. I am looking at this too.

about 2) with this patch #442016: Images are not displayed in excerpts because nid parameter is missing we can avoid putting the nid manually, but it is still nedded internally because I navigate the node in order to get the fields. Again, I don't know if I can get a field regardless of the node using a global ID.

@sun:
I attached archives because I didn't know if that would be integrated in inline module, and I also thought a standalone archive could be handier for casual testers.
Should I send further developments as patches against the inline module itself? I have no problem with that.

Wow, a lot of don't know and didn't know in this comment :)

Regards,
Antonio

@global unique identifier for fields: Often you need the nid + field_name (see the db "content_%type" or "content_%field" tables). Therefore Linodef uses this tag layout for fields [#nid:field_name].*

@Archive vs patches when using a new submodule/new files: For people who doesn't have a cvs client installed archives are great. If you can afford the time provide both. :) Creating patches with new/deleted files is sometimes tricky (-N doesn't work always). If you have trouble, the topic "Changing CVS/Entries to add and remove files manually" at the patch documentation page should be helpful.

*Regarding simplified tag format you might also be interested in Linodef. This module is for embedding fields/nodes/terms/etc in general and uses variable tags: [#identifier,element_type,options comments]. However, development for image field, file field and WYSIWYG API support is still ongoing and will come in the next two RC releases. (sorry for hijacking this issue)

@Antonio: Good work! I am also interested in collaborating on this functionality. Specifically I would like to see *any* CCK fields inline. Are you any closer to this goal? Or can I work from version 0.4 as a base?

@sun: tried to create a patch but having difficulty using the -N switch to add directory and files within it. Not going to sink too much time, would rather be writing code. ;)

@Mark: If we find a general way to identify a CCK field then we are done. I use formatters in a field-agnostic way, so the output rendering part should be already OK. I haven't done any further improvement over 0.4 so you can start from there, or we can setup (even on my server) a remote repository (under GIT in my case) and collaborate more comfortably, and we then post here only significant changes.

BTW, you can produce patches also using plain diff against /dev/null or tools like quilt.

@guix: The content is cached by the standard Drupal filter system, although this is disabled by Inline by default, for debugging reasons.

Right, here are some points on the code:

1) This won't work:

$context = (arg(0) == 'node') ? 'full' : 'teaser';

On the front page, the arg(0) will be 'node' but that's actually a view of node teasers.

2) Use the && operator rather than the word 'and'.

3) I have the code outputting a field of my choosing. So I use the inline tag [inline_field|field=field_related]. Then I can put any field inline, and control the output using CCK output formatters.

Thanks for the good work all.

Not so keen on moving code somewhere else, sun how 'bout a commit or alternatively we can set up a new project for this submodule?

Hi all!

I've been a bit busy with work lately. There seems to have been great work going on here, thanks!

I think I'm around the same point as Mark. Allowing a syntax like [inline_field|field=image|index=3] to insert image number 3 of field_image (possibly from another node with nid=42) as was proposed by ao2 in #10 is easy, with a snippet like:

      if (!empty($params['field'])) {
        $field_name = 'field_' . $params['field'];
        $field = $fields[$field_name];
        $formatter_name = $field['display_settings'][$context]['format'];

        $index = $params['index'];
        $field_value = $params['#node']->$field_name;
        $item = $field_value[$index];
      }
      else {
        foreach ($fields as $field) { // etc.

Is it better to have unique IDs or indexes like the above? With this code, it's easy to reference image 3 out of 5 attached images in a node, whereas it's not that simple for a user to find the fid of a given attached file, say (and duplicating information by inserting the full filename/emfield url is not really desirable). The fact that indexes change when the order of items in a given field is modified might be a good thing for some applications and a bad thing for others, though, I suppose.

Not sure how to fix the issue with $context. Mark, did you have a workaround in mind?

Perhaps it's best to keep this work separate from the Inline main code for the time being -> new project?

As for fine-tuned theming of such inline elements, the logical way to do it is probably to let the user choose the formatter she wants to use on a per-element basis, say [inline_field|field=image|index=3|format=captioned], which calls a user-defined formatter like theme_inline_field_formatter_captioned (which might be a metaformatter calling in turn theme_lightbox2_formatter_imagefield or whatever the user wants).

We can pass our own arguments to this formatter, so it could use something like [inline_field|field=image|index=3|format=captioned|align=left|caption=Hello World].

Does this make sense?

It might be necessary to provide a context-sensitive choice of formatter, though, which can quickly makes things cumbersome: [inline_field|field=image|index=3|format_full=captioned|format_teaser=small|...]

We can pass our own arguments to this formatte
Makes total sense for me.

quickly makes things cumbersome: [inline_field|field=image|index=3|format_full=captioned|format_teaser=small|...]
These cumbersome tags need to be generated by a GUI, later.

We must find the best defaults for the formatters included in the module (teaser or node context) and allow user-defined formatters !

Anyway, I've discovered the filter module, awesome !

Hi,

In order to detect the context:
$context = (arg(0) == 'node' && is_numeric(arg(1)) ? 'full' : 'teaser';
could be enough.

About the way to identify the fields: if the index parameter can change its meaning (because of fields reordering), then I don't think we should use it, after all. I am more toward a key,value oriented interface (file=file.png, embed=http://youtube.com/whatever) rather than a positional interface. I can see the limit in it, we have to add support for new field types one by one, but it seems a more readable and more stable scheme to me, just let me think some more about that :)

Before concentrating on the implementation, let's step back to the presentation aspect for a moment, the question I would like to pose is: is the macro going to be written by humans? Or we should primarily think that it will be inserted by some automatic mechanism (a button attached to the field to paste the complete macro, the WYSIWYG api, and so on)

In case one we should use in the macro only elements visible to the user who is writing the content, something he can copy and paste to build up the macro (the actual field name, for instance, is not easily accessible from UI AFAICS).
In case two we have more freedom in deciding the macro format.

Regards,
Antonio

@guix: about defining custom formatters give a look at extend CCK-fields with custom formatters. I have only scrolled it quickly so I don't know if that is enough for you. Sorry for the OT, this is not directly related to this post :)

I mostly agree with what has been said here.

Minor, but important note though: We want to re-use existing formatters. Inline macros are representations of data stored elsewhere. Just like Views does, we're fetching that data into a completely different context; so we are talking about fields and structured data, and the framework for that is already in shape (and already in core for D7) - called "fields". We just need to use it.

@sun: We're using the Inline module and a variant of this Inline Field module for the big redevelopment of Economist.com on Drupal. HEAD is already in the current development branch, and I have a modified version of Inline Field in there too. ;)

I would very much like to collaborate the development of the Inline Field module, as well as help bring the Inline module to a stable release. How can I help? Would you like me to create a new project for Inline Field so we can push ahead? I would be happy to help you by co-maintaining Inline. We have some reputable Drupal consultancies (Four Kitchens and Cyrve) working on and reviewing the code in Economist.com so at least from that perspective we are going to be very careful.

@mt-i: Yes using CCK formatters is what I have in mind. In fact, I already have the code working. If you want some easy to follow examples of custom formatters, take a look at http://drupal.org/project/cck_formatters

The problem I see with CCK formatters as they stand is the fact that they're somewhat difficult for themers to setup/override (compared to, say, CCK fields themselves). As I see it, it would be convenient to have an easy way to create a new CCK formatter that piggy-backs on an existing formatter, exposes some extra variables (such as, say, the "align" and "caption" arguments in my message above), and lets the themer write a simple .tpl.php file to put these elements together as she sees fit. I assume that this was (is?) more or less the idea behind the MetaFormatter module, but it seems particularly relevant in the context of Inline Field since we're exposing individual field items (which is unusual).

@guix: Choosing a default formatter is really not a problem, because that's what we're already doing (picking the formatter attached to the given field in the current context).

Which filter module are you thinking of?

@ao2: Note however that there are more downsides to the key,value approach than the need to add support for one field at a time.

Taking embed as an example, the key,value scheme seems to break down as soon as the user changes the video URL (to update it to a newer version, say) unless she also modifies the inline tag accordingly. From a usability viewpoint, that's a bit of a letdown (unless we hook ourselves to the node editing form and try to do dirty magic, but even then, there are serious usability concerns). Moreover, a key such as filename for imagefield is not a unique identifier: it's possible to have two or more attached imagefield items with the same filename. And while fid is unique, not all field types seem to provide such a unique identifier.

Wow, Economist.com, a big project can bring big benefits to Inline API and modules, that's a good news.
I started to work to Inline Field for ao2.it, not exactly comparable :)

@Mark: have you done any experiments with inlining fieldgroups yet?

FWIW, I am ok with creating a new separate project for Inline Field.

Regards,
Antonio

@mt-i, ao2, Mark Theunissen : thanks a lot for pointing me to CCK formatters, I'll have a look at them.

@ao2 for the written by humans/GUI question : most desirable are GUIs of course but it's more related to WYSIWYG API, FCK, ... projects. In the meanwhile, information like FIDs can be added in node editing pages in a custom module with _form_alter, in fact I use this to add a selection of pre-written tags in the #description entry of fields.

For the unique IDs / values / keys :

First for the values : I guess if we have to insert the values in the tags, then some of them are not fields tags any more, but just tags, and we don't even need the fields. Like for emfield, why would you enter the URL to embed in the field AND in the tag ?

For unique IDs / keys :

- solution 1 :
- stick to unique IDs for the fields that provide them, in order to ensure the contents don't change when the order changes, at least for them
- use keys for others

- solution 2 :
- use keys for all the fields. At least it is consistent.

Maybe to decide, we could have a look at what fields in D7 core do, but I don't know. Are there unique IDs for all the fields or not ?

CCK fields that have unique IDs
- Userreference
- Nodereference

- Filefield (and Imagefield)
- Date in a certain way (there's always only [field_date][0] with [value] and [value2] inside)

CCK fields that don't have unique IDs
- Text

- Emfield

... to complete

Re: Separate project I disagree. Fields are in D7 core already. The plan for Inline API is to provide macros on behalf of core modules like Token/Views does. Additionally, (pre-)alpha stuff like this can be developed/adapted/altered faster and better if it lives in the same project. Furthermore, there still are some major changes to Inline API in a separate patch/issue that (also) make this question obsolete, because Inline API implementations can be moved to other modules easily. Lastly, also due to that patch, all integration for other modules simply lives in include files, i.e. node.inc, upload.inc, field.inc.

I am open to add co-maintainers to increase the pace - but I need an agreement on http://drupal.org/node/363367 first. If you still have troubles adding files to CVS to create a patch, please either try to cvs add them (you should be able even without cvs access to this project), or alternatively, catch me in IRC.

Thanks a lot for making me discover formatters ! I suggest this change to inline_field.module, line 167

        $formatter_name = $field['display_settings'][$context]['format'];

becomes

        if (!empty($params['formatter'])) {
          $formatter_name = $params['formatter'];
        }
        else {
          $formatter_name = $field['display_settings'][$context]['format'];
        }

That way, we can have tags like :
[inline_field|file=FID|formatter=FORMATTER]
or simply
[inline_field|file=FID]
Then the only thing needed is to define the formatter, example :
[inline_field|file=123|formatter=left]
example.module

/**
 * Implementation of hook_theme().
 */
function example_theme() {
  return array(
    'example_formatter_left' => array(
      'arguments' => array('element' => NULL),
    ),
  );
}

/**
 * Implementation of hook_field_formatter_info().
 */
function example_field_formatter_info() {
  return array(
    'left' => array(
      'label' => t('200px floating left with description'),
      'field types' => array('filefield'),
    ),
  );
}

function theme_example_formatter_left($element) {
  $imagefield = $element['#item'];
  $align = 'left';
  $output = '<span class="image width-200 image-'. $align .'"><span class="image-img"><a href="'. base_path() .'images/'. $imagefield['fid'] .'">'. theme('imagecache', 'width-200', $imagefield['filepath'], $imagefield['data']['alt'], $imagefield['data']['title']) .'</a></span><span class="image-description">'. $imagefield['data']['description'] .'</span></span>';
  return $output;
}

with width_200 as an ImageCache preset, and the CSS styles for width-200 {width:200px;} and image-left {float:left;}

Alternatively you might also prefer not to do inline formatting with the tag. So inline tags won't become that cluttered like the img_assist tags. The tag might only contain necessary formatting that can't be done with other (html) tags, e.g. selecting the preferred image cache preset.

With formatters all we need is the formatter name in the tag (and the usual stuff : file, nid if other node) , and all the complexity stays at the formatter level and not in the textarea. Writing a formatter is easy and could be added to the doc.

subscribing

@sun re #38 - do you mean #80170: Inline API makes this issue obsolete?

I've been spending a lot of time trying to find a cck replacement for image/img_assist (with or without Wysiwyg integration). filefield_insert is close, but as ao2 said in #3, filefield_insert doesn't use a filter approach (though there are 2 notable issues relevant to this thread: #479310: Add support for add'l CCK Formatters (Lightbox2, etc.) & #461220: Implementing functionality like this as a filter?).

I'm willing to help contribute & test patches etc. But could someone help clarify one thing for me? Maybe I'm missing something... The main issue for me currently is that no matter what modules I test or patch, on sites that people actually use I still have to install image/img_assist (even if using cck elsewhere on the site), because users need an easy way to add images to text areas -- like right/left alignment, captions, size selection, lightbox & wysiwyg support etc. I realize the goal is to get that all working with imagefield, imagecache options, cck formatters, using a filter rather than just inserting HTML (the big difference between this issue and filefield_insert so far)... but is there any approach that's close to working yet, even if rough around the edges?

My clients are quite familiar using the approach described here and having separated alignment and caption buttons (with custom CSS classes). BUEditor allows easy addition of buttons, however with the WYSIWYG plugin system those buttons can be added, too. The images are selected by using a custom view which lists desired images and append it to a button.

Just provide a small how to in the filter description (below text field) e.g. use a tag (Linodef or Inline or whatever) for inserting the image and caption (I'm using CCK Textfields for captions) and a class for aligning. So e.g. the resulting code looks like this
<div class="image center">[* [#58:field_imagename,nolink] *]<br /><span class="caption">[#58:field_caption]</span></div>

Lightbox2 support can be added when viewing/caching the node and doesn't need to be in the tag/source of a text field.

@scottrigby: Sure - I should have published this elsewhere earlier, but apparently never did. Roughly, the plan/roadmap boils down to:

1) Finish the new API of Inline; @see #80170: Inline API.

Since Image module will be a wrapper around ImageField/ImageCache in D7, to provide a content-type, Image Assist has to be updated to (also) work with ImageFields. Since Image Assist's code is quite old/historical and Inline API is the successor of Image Assist's preliminary custom macro engine/parser/renderer, any take on refactoring Image Assist to also support ImageFields requires to rewrite Image Assist to use the new Inline API first.

2) Rewrite Image Assist to use Inline API as macro engine/processor.

3a) Enhance Image Assist to also support ImageFields.

3b) Rewrite Image module to work with ImageField/ImageCache instead, a.k.a. port to D7.

Since Inline API and Wysiwyg module are closely tied to each other from the beginning, there is also a lot of work to do to automagically provide dialogs to insert/edit inline macro tags, invoked by Wysiwyg module (for compatible editors). Compatible editors are two-fold: a) An editor needs to support a way to parse the editor content prior attaching and after detaching the editor from a textarea. b) An editor needs to support dialogs, or alternatively, Wysiwyg module will provide its own, generic way for handling popups. While a) is mostly dependent on the editor as well as community effort/interest for a particular editor, b) a generic popup/dialog handler will be done as part of the Wysiwyg module 3.x rewrite.

4) Rewrite Wysiwyg module to support dialogs for all editors.

5) Integrate client-side editor support for (all) Inline API implementations.

That's it - roughly. I could go on with 6, 7, 8 (mostly even more abstraction/generalisation), but I don't think that would make sense, because that's far away in the future.

The good news is that work on many of those todos already started. The bad news is that every single task on this list is a major development effort requiring a lot of hours/days/weeks to be truly accomplished. Furthermore, each task has to be done in a generic/abstracted way, so one-time/one-use-case solutions do not help at all.

Interestingly, after all of this has been done, we will end up with what I envisioned ~2 years ago in http://groups.drupal.org/node/8707. ;)

@sun: is the 2.x api expecting macros without the inline_ prefix now?

I am playing with inline-2.x and the format [inline_field|params...] does not work anymore. I managed to make [field|params...] work, is this how macros are supposed to look like from now on?

If so the documentation referring to inline_upload should be updated.

Thanks,
Antonio

Yes, every module can provide multiple inline macro implementations now, and Inline itself currently provides [node] and [upload] on behalf of Drupal core. However, the new code in 2.x still contains a variety of (partially major) bugs, which need to be solved as soon as possible.

Additionally, I'm about to investigate whether we can replace the built-in macros with a much more flexible and existing solution: CTools - either by fully replacing them or by wrapping CTools' content plugins with appropriate inline macro implementations.

replace the built-in macros with a much more flexible and existing solution: CTools

This seems the preferred way to go. Have you had the chance to look if the ctools content module or the context objects (using args to select content) are appropriate for selecting certain content set by a filter tag?

Antonio, any chances you could post your updated code for inline_field ?

@guix: here we are :)

The module is now called inline_cck, because I added a filter for fieldgroups as well, I plan to add also fieldgroups individual items rendering when multigroup will be added to an official CCK release.

I am still using the {key,value} way to select fields, relying on fields name and ordering doesn't convince me yet.

Also, I am experimenting with content_view and drupal_render to render the fields, this makes the code slightly more readable. You're warned, there is still some dead code left in the module.

You can use the fields filter with code like [field|file=drupal.png] and the fieldgroup filter with code like [fieldgroup|group=groupname].

One of the few things I am missing to fulfill my use-case is to pass an extra CSS class to the formatter, something like I propose in #559126: Pass extra CSS class to filefield formatter.

I am attaching an archive here, all the code is about 384 lines, just tell me if you want it “inlined” as well :)

Regards,
Antonio

Thanks Antonio ! I'm still using my own inline implementation but seeing your code helped a lot to update to the latest Inline 6.x-2.x-dev !

subscribing

subscribing

subscribing

subscribing

subscribing

Embedding/inlining fields by using their formatters is now supported in the recommended Linodef release - so it works with filefield/imagefield etc, too. Thx @ao2 et al. to refer to field formatters here.

@ao #50 careful: remove the ?> at the end of the inline_cck.module file, since it is not required. (It actually creates extra empty HTML lines, and consequently breaks RSS feeds.)

Thanks

@antiorario: thanks.

@Roi Danton: how did you implemented this in Linodef?
I don't know whether it is better to use content_types/content_format or content_view/drupal_render. I haven't found some time to evaluate what is better, maybe you did this already.

Thanks,
Antonio

I'm using content_types since content_view is a kind of hook_nodeapi and therefore the usage should be avoided within filters (the same for drupal_render) - it would produce too much overhead to fix the issues that occur with views when using nodeapi inside a filter module (e.g. not invoked for cck fields). So the replaced tags can be altered by other filters of the input format.

@Roi Danton: thanks.

I'm working on trying to create a good way to insert inline links from things like nodereference fields and Inline API generally seems like a good candidate for this. I was reading through the above comments, and an implementation that used concepts like #10 and #39 would create a nice, extensible method of inserting ANY CCK field, since we only refer to the field name and the index. We can then let the user choose a formatter for the field and use content_format() to render the field in the desired way.

So I would love to see an implementation that worked that way. The code in #50 using key/value pairs wouldn't work at all for that purpose. The names of the keys would have to be different for each kind of field, and that code is very specifically only working with filefields, with no way to extend it to work with other kinds of CCK fields. I'd like to see something more generic so that it could be used by other fields.

And no, fields can not be expected to have unique ids, but the field names are always unique, and the combination of a field name and a node nid would be a unique value. The field name + node nid + index would always be a unique value for an individual field element.

That's why I prefer node id + field name + index + formatter name for the filter, it would always be unique and it will not vary depending on the kind of field being used. Then it would be safe to assume index = 0 if not specified, and formatter = the default formatter for the field chosen on the Display Fields screen if another formatter is not specified. And I would need to have a way to optionally include a nid rather than assuming it is the nid of the current node, so that we can inline things like links to nodereference fields. I suppose you could also assume nid is the current node if not specified, so the filter could be a simple as [field:field_myfield] if you want the current node, the first value, and the default formatter.

I don't want to hyjack this issue to take things off in a direction no one else wants to go, but I would be curious what code the Economist is using and what methods would fit in with their use cases? If this doesn't fit into what others want to do here, I'll go off and do my own thing to meet my own needs.

Oops, I do NOT need to specify the node for a nodereference field, the field will contain the nid. But it still might be useful to make nid an optional value in the filter.

Oh, and we should consider inserting the nid into the filter anyway, since we know the nid when the filter is created and we are only guessing what it is later when we view the node.

@KarenS this does seem interesting for fields - I'd like to keep track of this. Btw, I haven't looked into what's required to print out a multigroup, but could this work similarly like [group:group_mymultigroup:2] etc?

@KarenS: I'll try to address your comments, at first I was more for the key=value syntax, but surely using the field ordering would be more general, I'll see if I can put in both ways to address a field. The main concern I had about using the ordering was about the possibility to reorder fields, but I guess this could be considered a rare event.

Let's test all this in a real scenario, then, I'll come back with a new inine_field version soon.
I am adding the formatter param too.

About the nid, it can already be specified explicitly in order to inline fields of different nodes.

Thanks,
Antonio

Glad to hear my ideas are at least somewhat in line with others :)

A couple more comments:

1) When I say we should include the nid when we create the filter, I mean even if you want to use the current node, not just if you want to use a field from a different node. The reason I point this out is that there is stuff in this code now that tries to 'guess' what the node is when rendering the content. You can do that if you are looking at the node itself, but it won't work anywhere else. If you are looking at a teaser list in a view or content in a panel, the filter will not have any information about which node the text came from and you won't be able to get it from the argument. When the user creates the filter we will know the nid of the current node (if it is a node at all, it could be a block). Since WYSIWYG might be used in other places than on a node, and the user might want to grab a value from some other node, we will have to expose a way for the user to indicate which node they want to get the field value from and we can store that information in the filter. Either way, we will know exactly what nid should be used at the time the filter is inserted into the text and the code should add that information to the filter for later use rather than trying to 'guess' it later when the text is viewed. Even then we won't have 'context'. If we are looking at the node page we know it is a page view, but that is the only place we will know context for sure. The lack of context is a weakness of the current filter system and I'm not sure of the best way to address it. Basically filters have to recognize that they don't know anything definite about context.

2) I would not create more than one method of doing the filter (both key/value and field name/formatter). That will make the code more obtuse and complex. We still have to create a way for the user to select the right value to insert, which will make this more complex. Trying to create two different ways of selecting and inserting values just seems unnecessarily complicated.

3) I would not worry about the fact that the field values can be re-arranged. If the user wants a specific value of a multivalue field, I would assume they have made sure that that will hold the value they want it to. There will be other, fancier, things that people might want to add to this filter later, but I would not worry about that now.

4) I would not mix fieldgroups into this code. Fieldgroups are different animals and the code that will work for fields will not work the same for fieldgroups. I would create two different filters, one for fields and one for fieldgroups. I think the code will be easier to understand and maintain if we have separate filters. And there are lots of more complicated questions to address for fieldgroups. What exactly do you want to display for the fieldgroup? Do you allow the user to select the formatting of each field in the group (a UI nightmare)? It's less straightforward than inserting a single field value, where the use cases seem obvious and relatively simple (insert an image from a specific imagefield, insert the title of a specific nodereference with a link to the node, insert a userreference field that shows the username linked to the user's profile, etc).

Do you allow the user to select the formatting of each field in the group (a UI nightmare)?

Yes, ideally we'd be able to specify formatter when inserting a field too (imagecache preset etc, nodereference as a list of titles or teaser etc). In that sense a multigroup wouldn't be that much different (pick from list of available formatters, same as in 'display fields' settings).

I mention here only because you're proposing to pass more information about the field - why not the formatter option too? And if so, multigroups seem similar in that way. do you really think the Ui needs to be such a nightmare?

Quick note: ALL of these ideas + thoughts + discussion totally is in line with the goals of Inline API.

I'm sorry for not being able to push Inline 2.x further in the past months as much as I would have liked to. However, Wysiwyg 3.x has already been enhanced to properly support new Inline API concepts. I will try my best to get back to Inline API design and development ASAP... and that said, I'd also welcome a co-maintainer, if someone feels brave enough for this complex topic and is comfortable with best practices for co-maintaining projects.

And no, fields can not be expected to have unique ids, but the field names are always unique, and the combination of a field name and a node nid would be a unique value. The field name + node nid + index would always be a unique value for an individual field element.

This is exactly the way Linodef already handles inlining of fields for ages. The syntax is id:field name:index or id,content="field name",contentvalue="index".

Here we are with an update.

Changes since the previous version:

• Included the changes proposed by mt-i in #28: Now we select the field to render using the (name,index) tuple, I called the parameter name because I liked the writing [field|name=...] in the macro. Let me know if you don't like it.
• Included the changes proposed by guix in #39: Now we can specify a custom formatter, see also the example_formatter module supplied with inline_cck_0.6; try to use formatter=myFormatter with an imagefield.

  The formatter arguments stuff needs some more discussion IMHO.

These changes should also address most of the comments made by KarenS in #62 and #67, let me answer to these latter item by item:

1. If the nid is put explicitly then it is not guessed anymore by the code. The only reference to node context is used to derive the default formatter, if you specify the formatter manually then this will be avoided as well and you should be able to render the fields anywhere.
2. ACK
3. ACK
4. Fieldgroups are already handled by a different filter, even if in the same module, I think this is OK. inline_fieldgroup needs more discussion of course, currently it is just a proof of concept, I guess it will get more interest when used with multigroups from CCK3.

After a little more testing we could finally turn this into a patch for the inline module and mark the issue "for review". @sun, is that ok?

Regards,
Antonio

Thanks for developing this module, GREAT!

But the latest release here (6.x-0.6) allows only one index. In my case (D 6.16, Imagefield 6.x-3.2, Filefield 6.x-3.2, CCK 6.x-2.6) I added two filter snippets ("[field|iid=2|name=images|nid=4|index=0]" AND "[field|iid=2|name=images|nid=4|index=1]") because of multiple imagefield uploads. But after saving the node, both snippets are always changed autmatically at the "index" syntax... ("field|iid=2|name=images|nid=4|index=1]" AND "field|iid=2|name=images|nid=4|index=1]"). So it seems that always the last index is used for all other filter snippets. (e.g. if I put in "[field|iid=2|name=images|nid=4|index=1]" AND "[field|iid=2|name=images|nid=4|index=4]" both will be changed to "[field|iid=2|name=images|nid=4|index=4]"... hope you understand what I want to say :D)

@CKIDOW: thanks for testing, I'll do some more testing myself and get back to you.

Would be nice to assign html attributes like "[...|class=myclass|id=myid]"... maybe there are enough capabilities to implement this feature.

I added two filter snippets ([field|iid=2|name=images|nid=4|index=0] AND [field|iid=2|name=images|nid=4|index=1]) because of multiple imagefield uploads.

@CKIDOW: the problem here is that you are using the same iid, you shouldn't change it, just let Inline API handle it. I can inline multiple instances of the same field type with no problems at all.

@sun: is there a way to avoid iid showing up in the macro in the edit form? Maybe nid could be hidden too if its value matches the current node id?

About passing parameters to formatters, either using a syntax like your [field|...|class=myclass|id=myid] picking up some selected attributes, or an opaque form like [field|...|attributes={class=myclass|id=myid}], the point is that the formatter has to support the parameters we are passing. See also #559126: Pass extra CSS class to filefield formatter for a hint. We should also think to the case when the formatter already define the parameter we are passing, how to we handle this? id could be replaced, but class (if we think to it like extra_class) should be appended.

Regards,
Antonio

subscribing

Subscribing

Sub

Hey guys, great effort. I wonder how is the progress going on? This is what I am currently looking for.

I'd tried using the module from #71, whenever I insert the tag like [field|iid=2|name=images|nid=1|index=0] it will just converted to [inline|iid=2]

I hope to hear about this soon, and hope this new one doesn't depends on upload and imagecache module.

subscribing

It would be nice if the default formatter for inline fields could be specified in the "Display fields", similar to how Token module integrates with it. It will help from a usability standpoint, especially where the default format is at odds with the field's usage (IE imagefield defaults to "Generic files")

thank

If there are users of the module in #71 I can add it to a git sandbox and handle the issues there.

Let me know.

could you, please, provide a patch against latest 7.x-1.x ? IMHO it would ease testing, maintenance and understanding.
(we may also want to reassign from 6.x-2.x to 7.x-1.x)

I would be more than happy to test this with D7 but I'm facing this (apparently common in D7) error:
undefined function content_types() in inline.module on line 308 but while the related code seems to be in ctools/includes/content.inc there is no (more) such a function name defined.

+ there is no more hook_inline() anyway; shouldn't this submodule use the hook_filter directly finally ?

@drzraf I never used inline or inline_field in production actually, for me it was just an experiment.

I could spend some time trying to make it work on D7, but I wonder if there are better ways to inline entities in D7. Have you looked for alternatives yet?

Regards,
Antonio

> I wonder if there are better ways to inline entities in D7
isn't field_view_field() our friend here ?
(but please excuse me if I'm wrong; I'm still starting with Drupal)

Closing as outdated because drupal 6 is not supported anymore.