Define joker character to use value from "this" node

Good idea. However

1. The $node object your code snippet uses is the embedded and not the embedding node
2. Normally asterix means 'all' of something or '0 - ∞'. Maybe someone knows a better character for using a certain property of the current context? Or using option 'translation' without a value for selecting the node language might even be the simplest way for the user? But then the validation and retrieve code will get unnecessarily complex. So I'm fine with asterix if no better idea appears.

While (2) is minor we need a solution for (1) to get the current node object. It is likely very simple but it is too late for me to find the required function right now.

Thanks, this suggestion sounds very good.

But linodef would then be a 2 pass filter: the first pass to replace ~ on node save, the second pass to embed the fields on node display. [...] you can not preview a new node when embedding images from the current node (it currently has no node id!)

I see. So you don't have to edit the node again to embed the image fields of this node.

Also when translating nodes the node id changes and you have to change the node id in the linodef tag.

When replacing tilde on save (what a filter should not do though) this function does not help here since when you translate the node you still have to change the node ID in the tag. So the tilde should be replaced on filtering and not saving. hook_filter() does not provide information about the node using the filter (current node/"this" node) but arg()/menu_get_object() can be used. However this has a major downside. It does not work when the node is used in views/panels (similar problem to buildmodes).

So before starting to work on this we have to find a way to retrieve the object the filter is applied on. Or a workaround for views, e.g. similar to the way I'm using for views in taglists.

+1

Very nice idea. I don't want to have to submit the node before I can use linodef.

What if we left out the node ID to refer to "this" node instead (as a suggestion to the format)?
[:field_name:multi_value_number]

@Format: [#any_character] is recognized as comment so a joker char, e.g. [#~], is fine for an automatic replacement. Well, the for the short syntax [#:content] seems fine, too (using "[#:" to detect that syntax). But this is easy to change and could be discussed later.

I don't like to do a replacement of ~ with the node ID on node save/presave (lets call it "nodeapi solution"). Yes, it solves the problem with embedding fields of a new node - though I'm not sure if this will work when previewing since in that step no node ID is present - but:

• the joker character would be useable only once - after saving the node it is replaced by the node ID
• therefore translation="~" and possible other use cases (e.g. for view arguments) wouldn't work

Investigating of a filter api solution would be worth the headache. So the joker character is saved with the node and is replaced on the fly when filtering.

Summary:
Nodeapi: no performance hit, implementation known, can be used only once
Filter api: slight performance hit (depends on determination of the current node), way of implementation not known, can be used as often as wanted (e.g. copy and paste the text in a different node without having to adjust Linodef tags that embeds fields of the current node - similar to the translation feature requested by druppi)

Indeed you are correct. Besides using hook_nodeapi (insert/update or presave/validate) hook_view might also work. There the substituted joker won't be saved at all.

Maybe with nodeapi->validate it is possible to embed fields from a new node that isn't saved in the db yet when previewing (if the node object already contains the attached field content).

Am I wrong but isn't there a "raw" version of the body text and a filtered version of the text, at least for filters that can be applied on node save (no dynmic text independent from this node)?

No, only body and teaser are saved in separated columns in the node_revision table. Filtered node content is only saved in cache if the filter allows caching. But since nodeapi provides altering when viewing the node this might not be a problem for using the nodeapi approach.

Current research on nodeapi:

• load: viewing ^yes, previewing ^yes, editing _no, translating _no (the joker is substituted like when viewing)
• prepare: viewing _no, previewing ^yes, editing _no, translating _no (substituted)
• view/alter: doesn't work at all since content is already filtered

I've done a workaround for "load" by excluding edit (node/NID/edit) and add-urls (node/add) by using arg() arg(0) == 'node' && (arg(2) == 'edit' || arg(1) == 'add'). This might not work when a module is altering the edit node paths (url aliases are not affected) - however no popular module does this (if you know one then let me know, please). Also the replacement when previewing doesn't work.

So the only downside of this approach is the lost substitution when previewing:

• load default: viewing ^yes, previewing ^yes, editing _no (substitution), translating _no (substitution)
• load exclusion: viewing ^yes, previewing _no, editing ^yes (no substitution), translating ^yes (no substitution)

The attached patch replaces node IDs [#~] and language translation="~". The functionality can be expanded.

But in preview mode the full node preview looks odd (see the attached screenshot)

In preview the linodef nodeapi hook is not executed and therefore the "~" is not replaced. It seems as if another filter is removing the tilde. Please provide a list of the filters you are using.

by the way, why does linodef not depend on filter module?

Thanks, added dependency.

Happy New Year! :)

In the new patch I implemented joker replacement also when previewing (based on path). That way other filters won't interfere since the joker is replaced in the prepare filter step (before processing filters).

Using "#" seems to be more convenient than "~". I've changed that. And an admin definable joker character is a meaningful feature, will add that later

The next step is to make tags working for fields of new nodes without node ID. I assume that the node object contains all the fields when previewing. Atm I be afraid that I can't use the existing replace functions (in linodef-filter.inc) without changing their structure at a whole (reading an object instead db records). I think I have to write new functions for this purpose.

I see. The preview for new nodes will use the current node object (instead of a saved node). The same technique will fit for previewing of existing nodes. Thanks for pointing out!

In views the nodeapi hooks are not called for every loaded node. So in some fields of the view the joker works and in some not. It seems we have to rethink the nodeapi approach and investigate why views doesn't use hook_nodeapi for each node: This seems to be intentionally for performance reasons, e.g. #178153: hook_nodeapi 'view/alter' not called for list and table view.

hook_nodeapi is not invoked at field views at all. I'm searching for a view function/hook that allows retrieving the corresponding node object of the displayed field. Maybe this also could fix the buildmode detection within views.

This patch supports views and uses the current node object when previewing/adding a new node.

Thanks for testing! :)
In another issue there was also a problem with computed fields i think (can't find it yet) where the value was not stored in database. For preview I use the node object but the computed field isn't even there. I need time to look into that problem. Perhaps the computed field project needs a patch. ;)

Thanks for linking, couldn't remember. I tested it and could reproduce the problem with computed fields [cf] not stored in db [nsid]. However in #21 my statement was wrong. The node object of the current loaded node when using the joker includes the cfnsid value. I don't know yet why this isn't part of the object when just using node_load. Maybe there is an additional CCK function that needs to be called.

But this problem isn't related to joker and likely deserves an own issue. If no other problems are detected I'll commit the changes this week.

My test above was erroneous. The values of computed fields without storage in db do work for me in all cases (preview, view node, views, views only with fields). I've tried the tags embedded with joker and id, embedded in same node and in other nodes. Can you verify that computed field no db values do not work?

EDIT: Ah, you mean the computed field values don't get updated when previewing? This is related exclusively to computed field indeed and should be fixed there.

the computed value before save is shown in preview, if the value is new, an error is displayed instead.

Ah, this I could reproduce. I have a computed_field that uses the value from another field. If that other field has no value an error is returned - as it should be.

And it is a problem with joker character (as it does not arise without joker)

No, the error message appears when using the normal id (and the computed field has no value), too.

But did I understand the problem you are referring to correctly? Btw, I'm online at Drupal irc (RoiDanton). There such issues can be solved faster. :)

@Hook_field: Unfortunately this is just for creating new fields. Something like hook_nodeapi fields don't have (hook_nodeapi is also dropped in D7 for good reason ;) ).

The problem is hook_field is called after hook_nodeapi (load, validates) that creates the node object:
1. node:load
2. node:validate -> object is retrieved
3. field -> computed field is updated
4. filter -> computed field is embedded with object from step 2
5. node:view

So the node object doesn't include the updated computed value done in computed_field_field/_computed_field_compute_value. Calling _computed_field_compute_value in the filter as mentioned in IRC might be a solution but I'm looking if there is a better, more simpler way (e.g. retrieving the object in hook_field).

Btw, 'sanitize' is a common operation for all fields.

There was no other solution but to include hook_field of computed field into linodef. I had a little trouble to fix the problem when creating new nodes since the computed field without stored db values is not part of that node object when the filter is invoked. However I could solve that by including a new check with content_fields().
Added admin option to set another joker character. Limited to one character for aesthetic reasons (though technically the number of characters for the joker is not limited).

Please test if everything works now.

The last lines of the patch are minor documentation fixes, some are not directly related to this issue.

Thanks for testing! Committed.

When working with views (e.g. editing a view and try to preview it) I get this warning message: "warning: Cannot modify header information - headers already sent by (output started at /www/htdocs/w007f3dd/drupal/sites/all/modules/contrib/linodef/linodef.module:188)". Can someone confirm this (using dev release)?

Nevermind, this was due to a Debug print output in my testscript. I've updated the view hook slightly to make it more safe against potentially errors.