If you load an Image Assist node using web services, you get it in the 'load' state, which seems to mean Image Assist has replace the 'teaser' element with the Image Assist BBCode-style string to be processed (unless this is changed already in 2.x?) and with the mark-up already in the HTML.

I don't know if there is any way around this behaviour, but it makes the job of processing nodes passed over a web service that have been acted on with Image Assist quite tricky - you have to re-populate the 'teaser' manually and strip the unwanted mark-up (it's a full URL, beginning http://, so you can't use it remotely because you can't guarantee 'access content' is enabled on the service site, and anyway the idea is to make a copy of the node, not link to elements of the old one on a different instance of Drupal).

It would be better if at 'load' the node body was unaffected, with maybe just something like [img_assist_id=122] for each placed image, in the appropriate place, and the Image Assist image data is stored in a separate array at $node->img_assist. Hope you follow my logic. =)

Comments

sun’s picture

Title: Image Assist and web services » Image Assist macro and web services
Project: Image Assist » Inline
Version: 6.x-1.x-dev » 5.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

Well, this would actually have to be implemented in Inline API, the next generation macro processor of Image Assist. Hence, moving over to Inline project.

However, there is also one caveat - Image Assist works not only for nodes. And I do not understand yet, what you want to do with that separate data.

greg.harvey’s picture

Ah, sounds cool. My thoughts on moving the data are:

* It looks messy to the "average" user to have that great long string of stuff in the body - the content publishing team where I work now are easily confused. It's fine inline, but it would be even better from a usability perspective if it wasn't - the whole point is this module is for users who are not 'advanced', otherwise they'd just use HTML, so the simpler the sudo-mark-up, the better, IMHO. If you disagree, disregard. It's your prerogative. ;-)

* Over-writing the 'teaser' (current behaviour) is a problem, for reasons already described, so adding attached images to their own array would be preferable (perhaps a separate feature request on Image Assist?)

sun’s picture

Hm. I still do not understand why you are seeing unaltered Image Assist macro tags in your nodes at all. Is it possible that you are syndicating nodes with a custom (or yet unknown contrib) module, which does not invoke the necessary nodeapi steps?

greg.harvey’s picture

Oh, I see! You're correct. I'm using the Services module to syndicate nodes over XML-RPC:
http://drupal.org/project/services

One of the bundled web services is node.load, which returns the 'load' state of the node as an array to the remote client (another Drupal site). I also created an Image service myself - see this blog post:
http://www.drupaler.co.uk/blog/soa-and-drupal-services-module/58

So I already have a module which fetches nodes from a remote server. Some of those nodes will be of type 'image' and another service method call fetches their attached image files as well. As the distribution server (the one hosting the services themselves) has Image Assist installed, and *some* remote instances may have too, I need to handle the Image Assist mark-up and macro tags too. Hence what I am trying to do on the client side is something like this:

if (module_exists('img_assist')) {
  ... some logic to make sure the image referred to by the macro tag exists locally
} else {
  ... some replace logic to strip out the macro tags
}

I don't want the mark-up, because I don't know if the image even exists yet, so it would be much nicer if the mark-up could be generated on 'view', not 'load'. That way node.load would return a nice, clean node body with no generated HTML and just the macro tags, which I can deal with.

For now my requirements are unusual perhaps, but I think SOA is going to become increasingly important. There is discussion around adding web services to core for D7. =)

sun’s picture

I see. However, Image Assist (and Inline API) does not run on op load - it is a input filter instead. So node_load() should always return the original, unaltered node. And you need to invoke Drupal's filter system to have all macro tags replaced in a node with actual markup.

If Inline API was already in core (which is the long-term goal) and Image Assist would leverage it, then it would probably strip all macro tags automatically, even if Image Assist was not installed.

greg.harvey’s picture

Sounds like the future is bright. =)

I'm slightly confused as to how I got both mark-up *and* macro tags when I node_load() a node with Image Assist images in it? I've uninstalled the module again for now, so I can't double check, but I was getting something like this:

  [body] => [image assist macro tag]

<span><img src="http://www.distribution-site.tld/sites/distribution-site.tld/files/images/foo.jpg" ... /></span> (corresponding mark-up)

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

  [teaser] => [image assist macro tag]

Whereas I expected something more like:

  [body] => [image assist macro tag]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis nisl ut aliquip ex ea commodo consequat. Duis autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et accumsan et iusto odio dignissim qui blandit praesent luptatum zzril delenit augue duis dolore te feugait nulla facilisi.

  [teaser] => Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi enim ad minim veniam, quis nostrud...

  [img_assist] => array(
         [0] => [image assist macro tag]
  )
sun’s picture

The actual result of node_load should be:

  [body] => [image assist macro tag]
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat...

whereas the result of node_view should be:

  [body] => <span><img src="http://www.distribution-site.tld/sites/distribution-site.tld/files/images/foo.jpg" ... /></span>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat...

If this is not the case for you, I have to guess that either the source content is malformed, or Services is doing something strange to the node. In any case, providing the markup of macro tags in a separate object property does not make sense currently. I would need a (very) valid use-case to implement this (and keeping in mind that there are also blocks, comments, and textareas in user account settings, which are able to use Image Assist).

greg.harvey’s picture

Hmmm, ok - I'll investigate further, but it's actually Views which is loading the node. Convoluted, but I call the Services module's views.getView method, which executes a view that returns the nodes. I know it's using 'load' op being invoked by Views in this case because I have to use the 'load' op if I want to make things available to the service in one of my modules. I'll investigate and come back if I find anything significant.

Thanks!

sun’s picture

Note: It's possible that views_get_view() just loads the source data, but performs no rendering.

sun’s picture

Any updates? I'm asking, because this issue actually contains no tasks for Inline nor Image Assist (besides the fact that Image Assist should use Inline API soon, so IA's tags are stripped from the content if IA is not installed).

greg.harvey’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Hi - sorry, I had to drop this due to other development pressures. It will probably take me a while to re-visit, so I'll close this issue and raise if necessary in the future.