ECML: question of life and death

[hypeJunction]

There seems to be opposition to keeping ECML alive, as noted in #3360 I have grown to like ECML as it allows to safely embed content that would have otherwise been stripped off by htmlawed. Obviously there are pitfalls, but I would like to see this functionality stay alive, or otherwise I would be interested in hearing ideas about how to implement a similar functionality. One of the options is oembed, but that only covers URLs. The beauty of ECML is that it allows rendering content based, e.g. on entity guid.

[elgg guid="123" full=1]

[ewinslow]

I think it's possible to create an equivalent URL, yea? Are there any cases where you can do something with ecml that you can't do with an equivalent URL?

On Thu, Oct 23, 2014, 11:33 AM Ismayil Khayredinov [email protected] wrote:

There seems to be opposition to keeping ECML alive, as noted in #3360 https://github.com/Elgg/Elgg/issues/3360 I have grown to like ECML as it allows to safely embed content that would have otherwise been stripped off by htmlawed. Obviously there are pitfalls, but I would like to see this functionality stay alive, or otherwise I would be interested in hearing ideas about how to implement a similar functionality. One of the options is oembed, but that only covers URLs. The beauty of ECML is that it allows rendering content based, e.g. on entity guid.

[elgg guid="123" full=1]

— Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7375.

[ewinslow]

Rather, where it isn't possible to have an equivalent URL

On Thu, Oct 23, 2014, 11:53 AM Evan Winslow [email protected] wrote:

I think it's possible to create an equivalent URL, yea? Are there any cases where you can do something with ecml that you can't do with an equivalent URL?

On Thu, Oct 23, 2014, 11:33 AM Ismayil Khayredinov < [email protected]> wrote:

There seems to be opposition to keeping ECML alive, as noted in #3360 https://github.com/Elgg/Elgg/issues/3360 I have grown to like ECML as it allows to safely embed content that would have otherwise been stripped off by htmlawed. Obviously there are pitfalls, but I would like to see this functionality stay alive, or otherwise I would be interested in hearing ideas about how to implement a similar functionality. One of the options is oembed, but that only covers URLs. The beauty of ECML is that it allows rendering content based, e.g. on entity guid.

[elgg guid="123" full=1]

— Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7375.

[propertunist]

something like ecml is needed to increase the usefullness of elgg as an information system. i would prefer if there was no syntax needed for end users, such that the embedding of any form of object could be achieved via a simple ui element. a more complete form of the embed plugin would effectively deliver what i am pointing to. the solution needs to be capable of rendering any subtype of object. or did i miss the purpose of this ticket?

[ewinslow]

@propertunist I would like to officially drop ECML. We are trying to weigh whether to do that. One big motivation for dropping it is there already exists open standards that cover the intended use-cases.

[hypeJunction]

@ewinslow I think I haven't thought about it this way. You are right, any item can be represented by a qualifying URL. The main concern I would have is that an oembed solution would require an engine boot each time you want to replace or extract info from URL.

[ewinslow]

OK so we need to make sure the implementation is performance sensitive. I think that's doable. More motivation to make loading core as cheap as possible.

Can we close this out, or would you like to explore the performance issue before closing?

[hypeJunction]

Give me some time to play with the idea. I want to see if I can do what ecml does server side with URLs On Oct 24, 2014 6:38 PM, "Evan Winslow" [email protected] wrote:

OK so we need to make sure the implementation is performance sensitive. I think that's doable. More motivation to make loading core as cheap as possible.

Can we close this out, or would you like to explore the performance issue before closing?

— Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7375#issuecomment-60413684.

[ewinslow]

SGTM

On Fri, Oct 24, 2014, 9:48 AM Ismayil Khayredinov [email protected] wrote:

Give me some time to play with the idea. I want to see if I can do what ecml does server side with URLs On Oct 24, 2014 6:38 PM, "Evan Winslow" [email protected] wrote:

OK so we need to make sure the implementation is performance sensitive. I think that's doable. More motivation to make loading core as cheap as possible.

Can we close this out, or would you like to explore the performance issue before closing?

— Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7375#issuecomment-60413684.

— Reply to this email directly or view it on GitHub https://github.com/Elgg/Elgg/issues/7375#issuecomment-60415088.

[hypeJunction]

I have since played with the idea of URLs and ECML can happily die. As long as the current repo is around to help migrate existing tags.

[beck24]

ok, it's been answered then! ECML will die

[hypeJunction]

I am reopening this. Let's get ECML into core, but with a slightly modified approach. Instead of using hooks, we map ecml tags to views, which control which attributes are too be used/ignored.

[player src="https://www.youtube.com/watch?v=G_Qt7fyaGKk" width="500"]

// views/default/ecml/player.php
$src = elgg_extract('src', $vars);
$width = elgg_extract('width', $vars);

$params = []; // prepare params
echo elgg_format_element('iframe', $params);

[jdalsem]

Like!!

[mrclay]

Pardon my ignorance, where does ECML get parsed/replaced? E.g. looking at the output/longtext view, it seems like parse_urls could interfere with ECML markup, and autop could interfere with ECML output (maybe unavoidable).

[hypeJunction]

I think you specify views whose output is then scanned for ecml and expanded

[mrclay]

So in practice just like "output/longtext". If your ECML attribute has a URL surrounded by spaces, parse_urls will mangle it, and elgg_autop will always add unneeded <p>s around the ECML substitution. Imperfect but acceptable.

[hypeJunction]

Yeah, there is some work to be done

[hypeJunction]

In reference to @mrclay 's concern, I was asked to fix a related bug. Posting temp solution for future reference

elgg_register_plugin_hook_handler('view_vars', 'output/longtext', 'mf_embed_custom_url_parse', 999);

/**
 * Implement custom URL parsing to avoid rewriting ECML tags
 *
 * @param string $hook "view_vars"
 * @param string $type ECML view
 * @param array  $vars View vars
 * @return array
 */
function mf_embed_custom_url_parse($hook, $type, $vars) {

	$parse_urls = elgg_extract('parse_urls', $vars, true);
	if (!$parse_urls) {
		return;
	}

	$value = elgg_extract('value', $vars);
	if (!$value) {
		return;
	}

	// parse urls excluding ecml tags
	$callback = 'mf_embed_url_parse';
	$regex = '/<a[^>]*?>.*?<\/a>|<.*?>|\[.*?]|(^|\s|\!|\.|\?|>|\G)+(h?[t|f]??tps*:\/\/[^\s\r\n\t<>"\'\)\(]+)/i';

	$value = preg_replace_callback($regex, $callback, $value);

	$vars['parse_urls'] = false;
	$vars['value'] = html_entity_decode($value, ENT_QUOTES, 'UTF-8');
	return $vars;
}

/**
 * Callback function for url preg_replace_callback
 *
 * @param array $matches An array of matches
 * @return string
 */
function mf_embed_url_parse($matches) {
	if (empty($matches[2])) {
		return $matches[0];
	}

	$text = $matches[2];
	return $matches[1] . elgg_format_element('a', array(
				'href' => $matches[2],
				'rel' => 'nofollow',
					), $text);
}

[mrclay]

Life? Death? Something will happen with ECML someday, but removing from milestone.

[hypeJunction]

I am planning to fork ecml and deal with it on my own terms