New Inline Filter code

Looks pretty interesting. Haven't tried it yet, but I noticed a little bug:

function inline_attr_value($text, $value_type = INLINE_WORD) {
  // Strip off initial and final quotes.
  $first = substr($text, 0, 1);
  if ($first == "\"" || $first == "\'") {
    if (substr($text, -1, 1) == $first) {
      $text = substr($text, 1, -1);
    }
  }
  switch ($value_type) {
  case INLINE_WORD:
    return preg_replace("/\W/", '', $text);
  case INLINE_INLINE_INTEGER:
    return preg_replace("/\D/", '', $text);
  default:
    return check_plain($text);
  }
}

it should be case INLINE_INTEGER: and not case INLINE_INLINE_INTEGER:

Sounds interesting; please explain what you mean by that.
I'm sorry but I'm very busy with my job and cannot follow what's going on with the module, but I like to see that people is using it...

I like all th changes you did to the syntax, but remember thaqt inline is also made to put files inside text, not only images....

Please let me know...

Matteo

I'll take a look asasp ath the code; did you preserve also the possibility to use file name instead of id ??

I understand, but what about referring by file name ?? This is a possibility I would like to maintain because of potential problems with images out of order (see http://drupal.org/node/28834).
Please let me know...
Matteo

Hi Bert,

I am going to be helping Matteo out maintaining the Inline module.

I've had a quick look through your patch and I really like it.

I intend to merge it with several other patches in the tracker and have a much-enhanced Inline ready for 4.7.

...Richard.

I like this patch but the "align", "border", "hspace", and "vspace" attributes of the image element are not supported in XHTML 1.0 Strict DTD.

I believe it would be better to do it in css instead. That is how the current inline module does it.

A also noticed some tabs that should be replaced with two spaces in the code.

i looked at your examples at #6
it uses DEPRECATED html attributes. it woud be better to use classes or for width and height style-tags!!!
we are using only valid xhtml at drupal and why are you using html 3-attributes?

(maybe you can introduce a theme_ function which allows me to change the classes for align left, right, center, etc)
for align right use
a class with:
margin-right: 0;
margin-left: auto;

for center use (i hope i did not shift the two values...)
margin: 0 auto;

for hspace and vspace you could use padding...

but in general it is a good idea.

why should the classnames have "inline-" as suffix?
because so it is easier to see which class belongs to which module...

why?
1. xhtml does not use this attributes anymore
2. one of our main-goals at drupal is to seperate the content from the theming.
means that you only need to change the theme/the css to see the website in another way.
and that the writer of some content does not look for theme-related things.
so we want to use classes and if really needed ids heavily.

things like the align or the hspace are visual components so they should be done by the theme
--> you cant use hspace or align
--> you have to define a class which has this values

Just because image filter uses deprecated HTML does not mean that a shiny new 4.7 inline should use them too.

(poor Bert, creates such nice code and now has Tobias, Richard and me all over because of some HTML attributes. we still appreciate your hard work.)

Hey chx, don't blame me... I didn't say anything!!

It is important that we get the new format of the inline tag right. We're going to be stuck with this format for a long time. And the beauty of inline is its simplicity. And I'm wary about doing anything which complicates it.

But as long as the original [inline:1] continues to do its job I think we can implement some extra optional attributes.

I'm thinking though... rather than defining specific attributes which are allowed, would it be better (and by 'better' I mean more flexible and easier to use) to allow free text which gets copied into the img tag? Some keywords could be search/replaced to allow the title and other things to be inserted.

So something like:
[inline:filename.jpg class="inline-right" title="{title}"]
gets replaced with
<img src="files/filename.jpg" class="inline-right" title="filename.jpg">

This would allow the user to insert HTML3 attributes if they wanted to without actually encouraging them to do so.

It might also be worth researching the way other CMSs and wikis allow images to be placed. Although I read through an instruction page for placing images in some wiki or other and I remember thinking, "If they need 6 screen-fulls of instructions they must have really screwed their syntax".

We also run the risk of making inline so complex that it's just as easy for the user to key in the full img tag!

I also like the feature from (I think) img_assist where you can specify the HTML used to place the image. This allows the description of the upload to be placed as a caption, which I've used to good effect on one site. But I found myself needing more than one template.

Don't get me wrong... I think the current patch is heading in the right direction... but I want to make sure we've considered all the options before settling on this format.

I have expanded on my suggestions in "Add setting for inline image style attributes" http://drupal.org/node/16101 and put the result in my sandbox.

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/frjo/

This version of inline.module lets the admin set three "Extra styles" and choose one to be the default. The styles are css style attributes like float:right; margin 5px;.

Users can then e.g. choose style 2 for file 1 with this syntax [inline:1:2=Title] ([inline:1:Title] still works also). On my site I have set extra style 1 to float right and to be the default, extra style 2 to float left etc.

It's a problem how to tell the users what the different styles will do, I just tell them to test for them self.

I think we have different needs. You want to give users a lot of choice/control, I want to give them a few selected choices that I can control.

I also want to keep the syntax as short and non verbal as possible. Some of my users don't know how to spell "title" and "align" since the don't know English well (or at all, and have different native languages).

I think the best way is to include a parser which
reads through code like this:
[inline:123 class="foo" caption="test" alt="moooooo" someotherattribute="100"]

it should take all atributes and save their name and values in an array
then this should be send to a theme-function which does the rest

then everyone can change the function how he/she wants it

eg. rename "title"....

As I see it, the main benefit of this patch is that it gives us a way of adding new attributes in the future without breaking the Inline API or having to extend it in arcane ways.

The old =title mechanism was very restrictive. frjo's patch implements an ingenious way to extend the old syntax, but still only offers users a limited and pre-defined set of formatting options for an image.

Tobias is correct in that all these display options should be moved to a themable function. My concern with that is that the function would be very complex. The current theme_inline_html function contains both image scaling code and some fairly complex code to generate the tags. I wouldn't want themers let loose with that.

In response to frjo's concerns about the words used in attributes... with a well-designed themable function the attribute names could be overridden. So you could create a theme function which implements a tag like: [inline:1 n=2 t="Lorum ipsum"] where n triggers a specific set of styles to be applied.

I'll spend a couple of hours on this later today and see if I can write up a spec for people to comment on. I think it best at this point to define the solution before writing more code.

+1 for identical syntax of inline and image module.

I can get Bert's point on explaining users (and customers) how they can include stuff into their contents. We're technicians, so we always know what we've got to do. But the rest of the world does not.

A user would expect an option to align an image/file by entering [inline:1 align=left]. He would also consider (for himself/herself) that [inline:1 title=Shoot me!] might change the title. Probably he/she would simply test it in front of reading the help.

"Shoot me!" consists of spaces which would break the syntax of these filters. So an approach like the current image assist filter with [img_assist|nid=14|title=Shoot me!|desc=|link=none|align=left|width=81|height=100] should do the job best. Indeed, the comlete tag looks quite cryptographic but I think we would give the most options to all sides with such a model.

I'm completely with Richard - the view has to be modelled by themable functions. So a designer or site administrator has full control over the possible filter attributes. One would likely do a conversion from |align=left| to class="left {...}" or perhaps even style="float: left; {...}". To achieve this, any passed argument has to be provided in one array which is then processed by the theme_ function.

Maybe it is relieving to know that other CMSs have issues on this topic, too. (In Joomla any filter ("Bot") has its own syntax...) As stated before, I would love to see an general approach for all Drupal filters. So I would raise the question if it wouldn't be helpful to have a filter tag parser in core?

In conjunction with additional media types for inline module it maybe should also be possible to change the processing extension (described there) by passing a special filter parameter.

This looks like a great addition to the inline module! But the latest patch appears to be for 4.6.3 (old Form API). If someone could provide a patch for 4.7 or CVS HEAD, that would be greatly appreciated.
-Steve

Here is the patch (fast one) for HEAD. Use with caution. I do not recommend to use this modified version of inline module on productive sites. Although I believe that this version is a step into the right direction it seems clear to me that this patch still needs much work.

Bert also removed some functionality from the module, in particular the auto_add function. This version actually looks - in terms of functionality - like a half-clone of img_assist module. I appreciate the work been done for additional tag parameters but I would rather tend to remove the whole image embedding functions from inline module, because image & img_assist modules are simply far beyond the possibilities of the inline module now. Regarding Drupal module deveopment policy this separation should already been done.

Thank you, gentlemen. I'll give that a try.

Bert, I appreciate your work very much. I am questioning the whole image methods in the inline module itself. I would love to hear your votes, opinions and comments in the offshoot of this issue: http://drupal.org/node/65200.

I'm still very much interested to see this evolving. Especially regarding current thoughts for a complete rework of inline module to an inline API. I don't want to move this discussion to that issue. As you can see (there) we have to take much more inline attributes into consideration.
As already mentioned in #27 and #31, I'd still vote for a pipe-based notation.

Inline API has quite evolved and introduces a new, generic syntax for Inline macros in Drupal. There is no upgrade path currently, but that's definitely another issue.