Integrate with Field API instead of random forms and textareas

err. What happened to Lightbox' rel="lightbox" support?

I see.

I'd strongly suggest the following, before starting to implement something:

1. Check what other *box libraries are doing and supporting (e.g., Colorbox, etc). Lightbox should not be the only possible integration, and if there is a common or uncommon solution in the others, we should integrate with that instead, and tell Lightbox to bend itself to the pattern.
2. The abstract problem definition is rather this: Without an anchor, *box does not know where the larger/original/full-size image is located, because it only has the IMG tag at hand. Therefore, the maximum *box could reasonably do is to open the exact same image in *box, which is pretty much pointless.
3. Thinking beyond HTML4: There are universal data- attributes in HTML5, which can hold arbitrary information.

   The lack of this language feature is actually what caused the most trouble for Inline in the past. But who really cares for HTML4 today?

   Nowadays, I would expect that any modern *box implementation is able to work with data- attributes (and potentially an additional class for selector performance, but that's unimportant):

   <img src="/files/imagecache/thumbnail/misc/druplicon.png" data-box-src="/misc/druplicon.png" title="Drupal's mascot" class="box" />
   

If possible, please also make sure to check for existing issues in the queue. :) I'm relatively sure that this is not the first feature request along these lines. ;)

So what you're essentially saying is that each inline tag needs to decide how it gets rendered.

That is, because there is no solid context system in Drupal yet, which you could rely on. It's therefore not possible to figure out at which point which contextual setting would have to be applied. (e.g., node vs. block)

And at that point, we're essentially reaching the general problem space of that the current Inline filter syntax is too limited and does not allow further parameters. ;)

Which, in turn, is the exact same problem space of #394682: CCK fields (filefield,imagefield,emfield) and fieldgroups for Inline API :)

This is why I started to work on #80170: Inline API - which apparently lives in the master branch - and which introduces a whole new macro syntax for inline filters. The current support for "uploaded attachments" turns into just one use-case with that, and hence, has been separated out into a inline_upload.module sub-module.

The whole concept is also explained in sun's vision for handling embedded/inline content and Wysiwyg in Drupal - which explains the architecture, and apparently still makes sense, even 4.5 years later ;)

Some people are even actively using that master branch code already, despite being in-development code only -- e.g., #286792: Allow to define ImageCache preset and image position per inline tag is a patch to extend it.

Needless to say, the master branch code is 6.x-2.x and would have to be moved into a corresponding branch and upgraded into 7.x-2.x afterwards.

I would love, love, love if you would get your hands dirty with that 2.x Inline API code, and could even see myself jumping on the gun to resolve the initial barrier of porting the code to D7. :)

But of course, I do not and totally cannot force you into working on a completely different thing... ;) So far, the plan/roadmap was to retain Inline 1.x with its current, limited feature-set as long as that is needed, and develop the entire new world of 2.x in parallel.

+++ b/inline.module
@@ -333,7 +333,7 @@
-  if (preg_match_all("/\[(inline|file|attachment):([^=\\]]+)=?([^\\]]*)?\]/i", $build['body']['#items'][0]['value'], $match)) {
+  if (preg_match_all("/\[(inline|file|attachment):([^=\\]]+)=?([^\\],]*)?,?(aslink|nolink)?\]/i", $build['body']['#items'][0]['value'], $match)) {

1) The new regex doesn't look correct to me.

- There's a bogus comma added within the old expression.

- The optional comma between the old and the new addition makes a tag valid, which happens to only have a comma after the filename or equal sign.

2) The option names "aslink" and "nolink" are highly confusing, because Inline already supports theme_inline_as_link(), and one would assume that those options refer to that, but in fact, they are not. The options need better names.

- That's more or less essentially why I pointed you to Inline API 2.x... with the 1.x syntax, it's almost impossible to design new parameters for the macro tag that are clean and make sense. (In 2.x, you'd simply refer to an image field formatter name to use, but/and you have a solid macro syntax at hand that allows to specify custom additional parameters, so this would turn into |link=0.)

+++ b/inline.module
@@ -344,12 +344,18 @@
-        if (_inline_decide_img_tag($file)) {
...
+        if ($option == 'aslink' || $option == 'nolink')

The two conditions should be combined, since you cannot render an image if the helper function decides that it cannot be rendered as image, even if the inline macro tag contains the additional parameter.

+++ b/inline.module
@@ -344,12 +344,18 @@
+        else ¶
+        {        ¶

+++ b/inline.theme.inc
@@ -34,7 +35,11 @@
+  if (isset($force))
+    $aslink = ($force == 'aslink');
+   ¶

Trailing white-space.

The added code does not adhere to coding standards for control structures; see http://drupal.org/coding-standards

In general, I don't think that Inline 1.x has a prospering future. It's architecture does not allow any more than nasty hacks.

FWIW, I've renamed master into 6.x-2.x, and ported it to D7:
http://drupalcode.org/project/inline.git/shortlog/refs/heads/7.x-2.x

You can test and see it in action with the built-in default plugin for nodes, by placing this macro tag into a (second) node:

[node|nid=123]

// Or alternatively:

[node|nid=123|view_mode=full]

The inline_upload sub-module has not been ported yet, as it needs to be redone, since Upload module no longer exists.

Upload module is File module now, which is a field. In general, Inline API 2.x should probably be refactored to mainly act on entities and fields (i.e., entity types, and field widget forms + formatters) instead of the random Form API mess it's trying to integrate with now ;)

As a (hypothetical) result, inline.node.inc would become inline.entity.inc, and the inline_upload sub-module would be removed in favor of a generic inline.field.inc implementation. As the names imply:

• You should be able to inline any kind of entity type with the tag [$entity_type|id=123]; e.g.:
  

  [entity|type=node|id=123|view_mode=teaser|links=0]
  

• You should be able to inline any field of any entity with the tag [field|name=$field_name|type=$entity_type|id=$entity_id|formatter=$formatter]; e.g.:
  

  [field|type=node|id=123|name=field_image|formatter=image_default|style=thumbnail|delta=1]
  

For entities, you can globally configure the view modes (and a custom ones). For fields, you can leverage all formatters that exist on your site and the inline macro syntax allows you to specify custom settings for a particular formatter.

But to clarify again, all of that entity + field stuff doesn't exist in 2.x yet. It needs to be developed. :)

Also, as one of the commit messages suggests, Inline API 2.x has (basic) built-in support for Wysiwyg API/module, as envisioned in that years-old g.d.o page. ;) Inline API was and still is the driving force behind that idea and effort, so possibilities are still quite limited. In fact, working on this D7 port revealed a blatant oversight in Wysiwyg module, which I fixed in parallel. If you want to try the (demo) integration, use Wysiwyg with TinyMCE 3, and enable the "Inline node" editor plugin for it.

HTH :)

I'm not exactly sure on that myself right now -- apparently, I wrote all of this code like 2 years ago ;)

However, this is my general train of thought:

1. In D7+, most textareas in which users would want to use inline tags (to reference/embed something else) are text fields.
2. Drupal's Field API has a solid concept of field types, field widget forms, field validation, and field formatting/rendering.
3. I'm thinking that the primary use-case and thus functional integration should focus on handling inline tags that appear within a (text) field.
4. Inline module should thus try to integrate with Field API's field editing/rendering workflow as the primary integration.
5. The current code does not do that - it adds a Form API #process callback to every #type textarea that appears on a site (which apparently needs to be fixed to look for #type text_format instead, if that code remains to stay), and tries to track and record which inline tags have been entered during form submission.

   Then, on a completely different end, it tries to integrate with hook_entity_insert() and hook_entity_update() in order to record whether the entity/field that was added/edited has actually been saved into the database (so the contained inline tags can be marked as permanent).

   Lastly, the inline tags are tried to be processed and rendered as an input filter...

6. The current code is primarily implemented as an input filter - which is bound to a text format. It's important to understand that the current filter system in Drupal does not support any kind of context at all. Thus, the only thing an input filter knows about is the $text to be filtered. However, inline tags - by design - involve context, since they are referencing other resources on the site. This leads to maintenance problems of content; i.e., if a node is updated, and it was it inlined somewhere, then the inlined/embedded representation is not updated.

   So there are a lot of arguments for not making Inline an input filter at all. Instead, it should integrate with the field view/rendering process of text fields, which inherently gives us 1) context and 2) proper content maintenance (just simply relying on the existing field cache; Inline does not even have to do anything about caching).

   Especially the context allows us to properly track $entity_type, $bundle, $entity_id, $field_name, and $langcode. (The idea of tracking inline tags originates from http://drupal.org/project/img_assist module and turned out to be a very good one -- a CMS should know where a content is used - even if it appears only in an embedded form.)

   The one possible pitfall with moving from an input filter to a text field integration is that text formats support a security/access concept, so it is currently possible to decide whether inline tags are allowed for, say, the Filtered HTML format, which might be the default for comments and is allowed for anonymous users. Perhaps Inline needs to remain an input filter for that reason - but perhaps also not; availability and access to inline tags could as well be configured on a field/widget basis.

7. In any case, the current code also tries to handle the special case of referencing something (e.g., an image) that is attached to the very same entity that is currently being created. This means that the entity does not have an ID yet (until it is saved). But in order to render the inline tag, Inline needs to know on which entity (ID) the image is attached.

   IIRC, the current code attempts to do that by integrating with the form submit handler and entity insert hooks, and searching for all inline tags that need an entity ID, but specify the ID 0 (zero). However, the entity only gets an ID after it was written to the database. And in hook_entity_insert(), there's no way to get back to the text field values that contain the inline tags, so they cannot be updated to include the proper/actual entity ID.

   IIRC, that was the primary reason for introducing the {inline}.iid -- the iid is added to each inline tag during form validation already, so all inline tags have an iid. The hook_entity_insert() then goes ahead and reloads all inline macros being stored in {inline} according to the recorded iids and injects the proper/actual entity ID into those {inline} database records. This means that the inline tags that are contained in text values do not necessarily contain all the parameters that the corresponding {inline} record in the database contains...

   This is a huge mess. :)

   By moving to a field workflow integration, I'm relatively sure that we could eliminate almost all of that. That is, because Field API itself basically has the same problem with its own field values: They are attached to the entity, so they can only be written after the primary entity record has been inserted. And alas, the {field_data_*} tables contain the correct entity IDs :) so Field API properly accounts for that already, which means that if Inline would integrate with field widgets, then it could automatically rely on all of that and wouldn't have to do anything on its own.

8. So essentially, I'd foresee this Field API integration:
   • When a text field widget form is constructed, Inline's integration starts. This will likely be hook_field_widget_form_alter(). At this point, Inline might not actually do that much -- it could parse the initial text value (if any) in order to extract and record which macros were contained initially (e.g., to determine whether a macro has been removed from the content).
   • When a text field is saved, Inline parses the text value to extract and record all macros, in order to save them in the {inline} tracking table, along with $entity_type, $bundle, $entity_id, $revision_id, $field_name, and $langcode (essentially the same standard columns that field data tables have).
   • When a text field is formatted/rendered, Inline parses the text value in order to replace all macros with their actual content.

Does that make sense to you?

Do you want to create and use patches against 7.x-2.x and post them here for review?

You could as well branch 7.x-2.x into a 7.x-2.x-field topic/feature branch, so you can commit atomic changes to that branch, and only create patches for review here via git diff 7.x-2.x...7.x-2.x-field

For now, I'd prefer if you'd use a feature/topic branch for this major refactoring.

That is, because we cannot change the git commit history of the main branch(es), so whatever development commits and debugging you do would appear very visibly for everyone. Contrary to that, a feature/topic branch can be changed, rewritten, heck, even deleted and recreated at any time. :)

If you already have commits on your local 7.x-2.x branch, just simply do this:

# On branch 7.x-2.x

git checkout -b 7.x-2.x-field
git push -u origin 7.x-2.x-field

git checkout 7.x-2.x
git reset --hard @{u}

The first two will copy all your local commits on 7.x-2.x into a new 7.x-2.x-field branch, and then push it upstream, automatically adding the upstream branch as branch to track.

The second two commands will hop back to 7.x-2.x and reset it to the upstream 7.x-2.x, losing all local changes in 7.x-2.x.

re: #19:

Yes, that's definitely in line with my thinking and what I wrote in #14. Two possible pitfalls though, which really need more investigation and probably can't be answered out of the blue:

1. Explicit or implicit $this?

   Essentially, by removing the parameters that (basically) point to "$this", you're also removing the possibility for everything that might integrate with inline macros to figure out what $this is. Bear in mind that the raw inline macros will appear in the field widgets, and one of the primary consumers is going to be a wysiwyg editor that is purely working in the frontend/JavaScript side of things, which does not have the implicit knowledge you are presuming. Hence, an implicit $this can easily cause troubles on these other ends.

   If the implicit is merely preferred over the explicit to make the macro tag shorter, then I would recommend to punt on that. In an ideal world, these macro tags should not be visible to the end-user in the first place; they are way too cryptic. The inline macro tags exist for machines only, and a machine does not care for how long a tag is, and in fact, a machine will always be much happier when it can deal with explicit things, because that inherently means less magic, less special conditions, less code, etc.

2. iid required for tracking?

   The iid might still be required for tracking, but I'm not 100% sure. I'm thinking of the case where one might have multiple references to another resource.

   But perhaps it is irrelevant how many times entity+field A references entity/field B. Perhaps we do not have to track the actual macro parameters at all, and change and reduce the {inline} table to basically be a simple "reference tracking" table.

   In that case, we likely want to change the schema to be a full set describing origin and destination:

   entity_type,        bundle,        entity_id,        revision_id,        field_name,        langcode,
   target_entity_type, target_bundle, target_entity_id, target_revision_id, target_field_name, target_langcode
   

   ...whereas revision, langcode, and field values can be NULL, in case the involved entities do not support revisions or are not multilingual, or in case an inline macro tag references an entire entity (instead of a field).

   This, however, leaves the question of what to do about inline macros that do not reference an entity. Perhaps we just don't care at all (and perhaps that even makes sense).

   Oh, and since we're mostly tracking data of other modules, we most probably should have a 'module' column (or even two) in there, so records can be properly cleaned up in case a module is uninstalled.

Just a quick comment for now:

Larger parts of the code does not adhere to the http://drupal.org/coding-standards which makes it hard to review. Most noteworthy issues are on control structures (if/else/etc) and (Mac?) line-endings. Cleaning that up and ensuring it for all further changes would dramatically help :)

Also, (apparently your second question) there's a lot of commented out code. But this is yet another benefit of feature/topic branches: All code is versioned, and at minimum the main branch still has it. No one will notice the removals until they're final (in the main branch). Instead of commenting out, just remove it. :) That will make it a lot easier for me and everyone else to review :)

Aside from that, these changes already start to make a lot of sense! :)

Your first question is tough. I've to admit I don't have a quick/easy answer. I usually approach such questions from a contextual user perspective, whereas that would be the "typical end-user" (content author/editor/publisher) in this case. But even from that perspective, I don't know what I'd expect... On one hand, I'd of course expect something to be rendered. But on the other hand, I clearly configured the field to not render anything at all. But alas, I may not be the entity/field administrator on the site, so I don't even know how the fields are configured. In turn - if there is no visible (i.e., hidden) default config for the field I'm referencing, then I guess I'd expect that some sane defaults are applied.

In any case, I think the field macro tag should always allow me to supply the formatter + settings for the formatter to explicitly specify the formatting.

So the question boils down to the case in which I'm not specifying a formatter at all. In that case, I'd expect reasonable defaults. However, I'm not sure whether Field API has any concept of a default formatter + default formatter settings in the first place. So. If that concept exists, let's leverage it. If not, let's punt on that and just render nothing.

Thank you! Here are the remaining coding standards/style fixes. :) I didn't commit them directly, as I didn't want to potentially produce a push conflict with your ongoing local changes.

re #22:

1) We definitely need to support previews. :) The current code uses explicit ID references, and for the entity preview case, it uses the special value 0 (zero) to refer to the (new) entity that is currently being added/edited. I think that makes some sense.

2) Yes, the tracking table's primary purpose is to answer the question of "Is this piece inlined anywhere and if so, where?" A primary use-case for this information is indeed a confirmation before deleting an entity; e.g., to ask the user whether he really wants to delete (and thus potentially "break" the expected content in some other entities/fields). And in the long term future, I could also imagine a dedicated site report page that performs a site-wide lookup and validation of inline macros and tells you whether any became stale.

Note also wysiwyg_fields which I think grapples with similar problem.

re: #23 / #29:

Good point. My current stance/consideration would be this:

1. By default, Inline API assumes that "remote resources" from somewhere else are embedded; i.e., fields from another entity, or an entire other entity.

   I.e., these do not affect the rendering/output of the remote field/entity/whatever at all:

   [field|type=some_other_entity|id=123456789|name=field_image]
   [entity|type=some_other_entity|id=123456789|view_mode=teaser]
   

2. All of the following only applies to referenced fields/resources that are on the entity currently being edited/added.
3. When referencing a field/resource of the entity that is currently being edited/added, then the granularity of parameters/settings on the inline macro tag decides on whether the "original" field (that is being referenced) will be rendered, too.
4. If the macro specifies a custom field formatter (or formatter settings), then the original field will be left untouched and (also) rendered as usual. (which most likely means the original field has been set to hidden and will not be rendered)

   I.e., this does not affect the regular/configured output of the referenced field, because it uses a custom formatter (and possibly even custom formatter settings):

   [field|type=this_entity_type|id=0|name=field_image|formatter=image_slideshow]
   

5. If the macro references the field only and does not specify a custom formatter, then we can only assume that the original field is not hidden and thus would be duplicated in the output. Which means that the original field is configured to output something. In that case, the original field should not be rendered.

   I.e., this affects the regular/configured output of the referenced field, because the field gets essentially inlined/embedded into the content already:

   [field|type=this_entity_type|id=0|name=field_image]
   

   The technical way to handle this would probably be to set a flag on the $entity or possibly when the referenced field within the $entity, to prevent it being rendered when it would normally be rendered.

6. However, there's no reason why this couldn't be controlled on a per-macro basis either. Content authors should be able to override Inline's default assumptions by adding a parameter that controls the field view behavior.

   E.g., something along the lines of this:

   [field|type=this_entity_type|id=0|name=field_image|render_original=0]
   

7. Lastly, there's one additional dimension we're still missing in this discussion: entity view modes (e.g., teaser, full, rss, etc). The field display can be configured differently per view mode.

   Usually, many/most fields are set to hidden for the teaser view mode. So my above assumption that we could make this decision based on whether a formatter and/or settings have been specified might not work out, because when viewing a node as teaser and referencing the image field on it that is set to hidden for the teaser view mode, then the default formatter would actually output nothing...

   In turn - unless we can come up with a different and really intelligent/smart solution - this likely means that we always have to specify the field formatter (and possibly even all required formatter settings) in all macros that reference a field. Whether to render the original field (on the same entity) or not can only be controlled by the additional render_original parameter, which would use a sane default (most probably 0; i.e., muting the original field).

Note: hook_page_alter() is way out of scope for Inline API. If we need to defer the macro expansion to a later point in time, then the last possible time would be hook_entity_view_alter(). For now, the goal should be to always stay within the entity/field context.

Sounds great! (Didn't have a chance to look at the code yet.)

The built-in 'image' formatter of Image module has settings for the image style to use as well as basic link options already. We're primarily interested in the former.

That said, we could leverage the existing, basic link options of the image formatter to form_alter/inject a new, custom setting that allows to specify a custom URL and stuff. However, that's very custom and advanced already, so I'd prefer to leave that for later.

Back to your primary concern - and this is where this entire concept starts to shine :) - check Lightbox2 module:
http://drupalcode.org/project/lightbox2.git/blob/refs/heads/7.x-1.x:/lig...

Apparently, it seems that module badly needs some help, since its entire code-base looks horrible with tons of commented out code... not even sure whether it works... But anyway, if you want a lightbox, use the lightbox formatter:

[field|type=node|id=X|name=field_image|formatter=lightbox2__lightbox__thumbnail__medium]

(Lightbox2 developers do not seem to be aware yet that formatter settings are possible ;))

A better example would be Colorbox:
http://drupalcode.org/project/colorbox.git/blob/refs/heads/7.x-1.x:/colo...

Its formatter settings needlessly duplicate "colorbox_" all over the place and generally aren't very intuitively named, but regardless of that, you can specify all the fancy dancy options :)

[field|type=node|id=X|name=field_image|formatter=colorbox|
colorbox_node_style=thumbnail|colorbox_image_style=medium|colorbox_caption=custom|colorbox_caption_custom=My fancy dancy images!]

(wrapped for clarity)

Note: I'm committing some changes and clean-ups.

Alright. Lots of clean-ups. First stab at solid tests. They're very basic and definitely need to be rewritten at some later point, but for now they should keep us in good shape while we're adding new assertions.

TDD (test-driven development) has proven itself, not only for explicitly thinking about and clarifying hard-coding expectations right from the start, but also to avoid repetitive manual testing of the identical functionality.

Especially for modules like Inline with its parametrized macros, the amount of possible test scenarios and test cases very quickly becomes so massively large that it's close to impossible to test the full stack manually. Even with the very basic code we have right now, it wasn't possible to cover all scenarios/cases yet.

That said, the current tests are failing - due to some weird handling of the text format for the summary of a node body field in teaser view mode. Essentially, despite having a text format assigned that allows URLs, the summary appears in plain-text. I'm not sure what the problem is and can't really believe that this is a bug in core as that sounds a bit hilarious. I suspect it's our own code that hi-jacks the field rendering.

In any case, we should try to get that fixed, so tests are passing (again). My own general rule of thumb is that I always run the tests to make sure they're still passing, before committing a new change.

I'd recommend us to do that :)

Regarding parameters for formatter settings:

The current inline macro syntax does not really support nested sub-keys. IIRC, I once implemented code that allows the #multiple flag for a parameter to work, but as the name implies, that only means multiple values, not nested keys.

That said, it is possible that PHP $_GET HTTP query parameter alike structure would work, since I think I once refined the macro parser regex to make it not error out on brackets within brackets; e.g., this might work:

[foo|bar[baz]=beer]

In general, that question actually hits the macro syntax topic and problem space though. I will say that it is entirely possible that we're going to change the syntax to a completely different format. Previous discussions on that topic in the past mainly played with the idea of replacing it entirely with JSON, based on the idea and main benefit that JSON supports at least some data types natively and can also be parsed in the front-end; e.g.:

{{"macro":"foo", "bar":{"baz":"beer"} }}

However, it must also be said that JSON has its own problems as serialization language.

And now that I said the above, a pure URI standards based syntax would even be possible, too; e.g.:

[inline/foo?bar[baz]=beer]

i.e., [path?query=string] ;) Equally simple to parse. :)

But all of that being said, I'd prefer to defer this topic entirely to later, if possible.

For now, I'd just simply put (merge) the parameters for the formatter's settings on the top-level parameters. Yes, I'm aware that this means potential name clashes, but as mentioned, the serialization language/syntax is a very big topic on its own, which I'd like to discuss with others first, so as to move into the right direction. I think we can punt on that topic for now and focus on the main architecture and entity/field integration instead to make that fully work. Once there's an agreed-on direction, the actual switch to a different macro syntax/format is a very small step compared to that (alas, in both of the above cases, we'd simply replace ~100+ lines of code with a single line ;)).

I think we're making very good progress. :)

For everyone else following at home: @Javier and I are collaborating over IM/Skype to eliminate the comment/reply lag. The latest code lives in the 7.x-2.x-field branch. Comments are highly welcome! :)

The revamped module code requires the Class Loader module, which is a 1:1 backport of the PSR-0 class loader in D8. ["D8" is the keyword here ;)]

The code looks extremely appealing already and tests confirm that the basic functionality works. I just committed another round of clean-ups.

The next steps we should focus on:

1. Add tests for FieldMacro's render_original parameter.
2. Add tests for passing custom formatter settings to a field formatter in FieldMacro.
3. Consider to replace FieldMacro's custom field rendering code in ::view() with field_view_field().

4. A) Untangle ::getParameters() from a UI/form definition, or B) turn ::getParameters() into ::getForm() and ::validate() into a #element_validate Form API callback.

   I'm not yet sure which direction is better and more appropriate. Technically, the pure macro processing does not need the overhead of the extra definitions for parameter labels, descriptions, etc.

   OTOH, when splitting parameters and the form/UI definition, then there's a high chance we'll end up with a considerable amount of "duplicate" validation code. The bare macro processing and validation basically follows the rules of Form API anyway -- it processes user input for a set of predefined elements. We will need form constructors and form validation at some point either way, so users are able to construct and embed a macro through the UI (within a Wysiwyg context, ideally without actually seeing the raw macro string at all).

5. In case of A) above, replace the current mixed/bool macro validation return values with exceptions.
6. Coordinate with Edit module friends on "nested editables," i.e., how embedded content needs to be wrapped and marked up to make it appear as an own editable in the editor.
7. Replace current inline macro serialization language/syntax with something else.
8. Discovery and UI. Retrieve a list of available resources that can be referenced, or provide means to select a particular resource (primarily targeting entities and view_mode, applying to both EntityMacro and FieldMacro). Expose widgets to formatter and optionally formatter settings (potentially re-using Field UI module code).

Very nice progress indeed! Thanks, Javier, for pushing this forward! :)

FWIW, this code has been merged into the 7.x-2.x mainline. :)

+++ b/lib/Drupal/inline/FieldMacro.phpundefined
@@ -179,17 +179,19 @@
+    ¶

екфшдштп-цршеуызфсу

So... in another chat about Edit/Wysiwyg-in-core today, @Wim Leers described the "ideal macro system architecture." He wasn't really aware of the actual Inline API 2.x code.

What he wrote down happens to be exactly the architecture of Inline API. ;)

So I went ahead, polished his description, enhanced it with some first documentation about essential architectural design decisions, and committed that to the README. (This can and should be improved later; some of it might rather belong into inline.api.php even.)

:)

An interesting consequence is that the http://drupal.org/project/token_filter module should now just become an API implementation of the Inline module…

Q:
- Is Inline core-worthy?
- What about existing "macro filters" that are implemented as filters?
- Because this is not part of the filter system, it automatically becomes impossible to apply filters to the rendered/expanded macros of the Inline module. So, using e.g. http://drupal.org/project/caption_filter becomes impossible. Captioning images is (arguably) a much-needed feature, for Inline module to be as attractive as possible it also needs to support that. How do you propose that would work?

That's not what I meant. I'll give a stupid example:

Input:

Look at my awesome cat!

[node:field_image]

Filtered (filters: filter_autop, an image caption filter that transforms the title tag into a caption):

<p>Look at my awesome cat!</p>
<p>[node:field_image]</p>

Macros applied in hook_field_attach_view_alter():

<p>Look at my awesome cat!</p>
<p><img src="cat.jpg" title="awesome cat!" /></p>

But I wanted:

<p>Look at my awesome cat!</p>
<p><div class="captioned-image"><img src="cat.jpg" title="awesome cat!" /><div class="captioned-image-caption">awesome cat!</div></div></p>

#53: It's impossible to solve. If you use macros, you can't apply filters to the result of macros. IMO the best you could do is offer the ability to *extend* macros, i.e. add attributes, so you can add any kind of functionality :)

Merged the 7.x-2.x-parser branch into 7.x-2.x :)

Will have a look at the new tests in the -field branch shortly.

Next step: #1787066: Port to D8