Roi Danton, I really like your module, but please, do not change the filter syntax in alpha2 as desired. With the next extension of the module, you will have to change the syntax again. Here is my suggestion:

[#id,option,option,... comment]
[#id:field_name,option,option,... comment]
[#id:field_name:field_num,option,option,... comment]

where

  • id is a node id or a term id (or even something else? see below)
  • option can be any combination of:
    • term the id is the id of a taxonomy term
    • nid the id is the id of a node
    • nl or nolink (it is more readable!) do not create a link
  • comment is not output. A comment begins after the first blank space and ends before the closing bracket ]

Of course, not all combinations are possible: term and nid exclude each other but if both missing, nid is assumed, nolink can be combined with any.

And here is my first extension:
A new option tnid: the id is a node id, but it should be replaced by the id of a translation node.
Example: you have a node 1 (de) and translate this node into 2 (en). A third node 3 (de) is also available. In node 2 (en) you want to reference the translation (en) of node 3. As it is currently not available, you can't reference it. Instead you must reference node 3 (de). And when the translation of node 3 (de), say node 5 (en) becomes available, you have to change node 2 (en) to no longer reference node 3 (de) but node 5 (en). With tnid you won't suffer from this hassle. A [#3,tnid] will reference node 3 (de) as long as node 5 (en) is not available, but if it becomes available, it will reference node 5 instead.

The rule to replace the nid in [#nid,tnid] is:

  1. get the tnid (the database column!) of nid(the source node for translation)
  2. get the language(the database column) of the referencing node
  3. get the node with this tnid and language
  4. replace the nid with the nid (the database column!) of the translation node
  5. if any of above fails, use the nid as is

Comments

Roi Danton’s picture

Roi Danton commented

As I plan to support the embedding of comments, too, this sounds really good (option = comment). I just want to find a way to allow a random order of the options (e.g. [#5:field_name,nid,nolink] and [#5:field_name,nolink,nid] should output the same result) with regular expressions - and without writing a link for each ordering possibility (with each more option the function would increase in size exponentially).

@Extension:
I've never used multilanguage nodes in Drupal. Is the default behavior of the D6 core module "Content translation" that the language versions are saved in different nodes?

Roi Danton’s picture

Roi Danton commented

Regarding the options the new syntax works now on my testsystem. Only the comments could cause possible bugs if I don't limit them to certain characters (I need to exclude at least ] ). So currently I have limited the characters a comment may include to [a-zA-Z0-9_-,+ ]* but so characters from many language won't be supported in a comment (which is bad). I'd like to exclude "]" from the possible characters and allow the rest.

Is that possible with RegEx in php?

pepe roni’s picture

pepe roni commented

@#1
Yes, translations are separate nodes in Drupal (D5 and D6). I don't like that, too, but I have to live with this :(
When you look into the database schema of the node table, you will discover a column "tnid", that links translation together. "tnid" contains the nid of the source node (the first created node of a translation "set" or "group"). A node that has not been translated seems to have a tnid=0.

pepe roni’s picture

pepe roni commented

@#2
I don't know RegEx and I don't also know how to write a filter in Drupal :(

But in my naive opinion you can extract the string between the two brackets, split the string at the first blank (if any) and ignore the right part (this is the comment). Of course, the comment must not include a closing bracket, but that can be changed by the editor himself/herself.

Roi Danton’s picture

Roi Danton commented

@#3:
I see. I'll have a look at it but can't promise anything.

@#4:
Nevermind, I've already solved it yesterday. Also the buttons already can have (if the admin wishes) default comments attached to the tags.

I'll commit the changes tomorrow. If then no bugs are covered in the dev release, rc2 should be ready next week (depending how quick I'll make progress with updating the documentation and the translation files).

Roi Danton’s picture

Roi Danton commented
Status: Active » Fixed

Well, it wasn't "tomorrow" like said in the post above because I wanted to finish the documentation and translation files before submitting (to avoid question because of lacking documentation).

With the new syntax the Code for BUEditor Buttons has changed one more time (since dev releases after rc1). This one will (hopefully) be the last time because now it uses options, too. Hence it is more flexible respectively it is extensible without the need for code change now.

Comitted to D6 branch. Please test the dev release on a test environment for bugs/flaws since with this dev update Linodef got tons of new features. RC2 will be released before Christmas unless major design bugs are found. If you find a bug relating this issue then reactivate it, please. Thx!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.