Text formatting in Flarum

Toby

JoshyPHP Perfect. Thanks so much. That API sounds useful – let me know if it makes it in!

JoshyPHP

It's really just a question of when. I'll add it as soon as I settle on a method name. (I'm open to suggestions btw 😃) I want to provide enough support for reading and post-processing the XML that users of the library never have to do it themselves.

Toby

What about something like scanAttributeValues or scanAttributes?

JoshyPHP

I settled on getAttributeValues().

You can use it like this: Utils::getAttributeValues($xml, 'MENTION', 'id') (API)

Franz You won't have to implement a plugin. Using my previous example as a base, you could capture what looks like mentions with a preg_match_all() before parsing, prefetch user IDs and fill the mentionator cache in advance.

JoshyPHP

@Toby Forgot to add: if you spec out how mentions should work, I don't mind writing the initial implementation.

Toby

JoshyPHP Thanks! I'm gonna give it a shot based on your examples, but if I'm struggling I'll take you up on that offer. 🙂

Would it be possible to get fenced code blocks in the Litedown plugin? We use them occasionally on this forum, and I don't want those posts to break when we upgrade!

JoshyPHP

I intend to look into fenced code blocks sometime this week-end or early next week.

Toby

Finished the implementation, yay! I kept it simple for now, storing the username in the XML instead of retrieving it during rendering (just like your example). We'll put the live username rendering on the backlog.

Unfortunately the mentions don't render for the live preview, because they don't get an "id" attribute assigned and are thus invalid tags. Is there any way around this, @JoshyPHP? Some way to render all mentions, regardless of if they're mentioning a user that exists or not, and without an href, just for the live preview? No biggie if it can't be done, just thought I would ask.

Franz

Toby Finished the implementation, yay! I kept it simple for now, storing the username in the XML instead of retrieving it during rendering (just like your example). We'll put the live username rendering on the backlog.

Should be done before final, though, right? Otherwise we'd have to write a conversion script for older posts...

JoshyPHP

Toby You can set required = false on the attribute and it'll be optional.

$configurator->tags['MENTION']->attributes['id']->required = false;

For the template, you can use a conditional that renders the mention as two different elements:

$configurator->tags['MENTION']->template =
	'
		
			
		
		
			
		
	';

Or you can render it as a a element and use a conditional to create the href attribute or not:

$configurator->tags['MENTION']->template =
	'
		
			
				
				
				#profile
			
		
		
	';

I'll look into the img/alt attribute, that's got to be a bug. Edit: it was.

Toby

Another thing: in Litedown, can we enable images with an empty alt attribute? e.g. ![](http://example.com/image.png)

Berlyn

Toby This. My godddddd, this.

Toby

Franz Actually, my implementation does store the user/post IDs in the XML – it just doesn't use it to retrieve an up-to-date username during rendering. So no conversion script will be necessary. Nevertheless, I think we should get this done before final though, yes.

Toby

JoshyPHP Awesome – still not working in JS though. If I remove the $tag->filterChain->prepend() call, it works. Any ideas?

JoshyPHP

If you're using a custom tag filter, you'll need to set up a JavaScript function for it. Otherwise, the default JavaScript filter only returns false.

A tag filter returns true or false to indicate whether a tag is valid. If you want the tag to be always valid in JavaScript, make it return always true:

$tag->filterChain->prepend('myfilter')->setJS('function() { return true; }');

Toby

Man, I am super impressed by this library. Thank you once again for reaching out to us. 🙂

JoshyPHP

Thanks, I'm excited to be here. 🙂

Fair warning: you might be the first non-me person to actually use the JavaScript part of the library so you will probably run into bugs or situations I didn't foresee. ????

PS: I've just added a tiny bit of documentation about JavaScript filters to show that they take the same arguments as their PHP counterpart.

JoshyPHP

I've just added support for fenced code blocks. I don't like how big and unwieldy the Litedown parser has become though, and I'm considering a different algorithm to handle block-level markup. I don't know when that will happen but it won't change the API.

Talking about API, I intend to start using a proper version number with a more accessible changelog in the foreseeable future. I just haven't taken the time to do so. 😅

JoshyPHP

@Toby I noticed you were using twemoji's library. Have you considered the Emoji plugin instead? It wouldn't work outside of posts but it would also be faster and smaller.

I peeked at the JavaScript but I can't tell whether it was minified with Closure Compiler. You can use Google's HTTP service to minify the library's JavaScript with this:

$minifier = $configurator->javascript->setMinifier('ClosureCompilerService');
// Return the unminified source if any error occurs rather than throw an exception
$minifier->keepGoing = true;

Also, if you want to save a few KB and squeeze out a tiny bit of performance you can declare which JavaScript methods to export with this:

$configurator->javascript->exportMethods = ['preview'];

Toby

JoshyPHP I saw that plugin, but I had a hunch it would be better to do emoji processing on the client-side so as to preserve the unicode characters in the API, and thus allow different clients (e.g. a mobile app) to use their native emoji styles. I don't feel strongly about this though... maybe it would make more sense to finalize all processing on the server-side.

The JavaScript is indeed being minifed with Closure Compiler. Thanks for the keepGoing and exportMethods snippets, will implement them!

sijad

Toby I'm sorry but I can't understand this, if you're going do processing in server-side, what gonna change with live preview?

« Previous Page Next Page »