Fork me on GitHub
Subscribe 6

Ticket #308 (open enhancement)

Add the new parser to FluxBB

  • Created: 2011-02-22 13:01:18
  • Reported by: Reines
  • Assigned to: None
  • Milestone: 2.0-alpha3
  • Component: parser
  • Priority: normal

Add ridgerunners new parser to FluxBB

Should be modular and allowing plugging in of different parser classes. This will allow for bbcode/textile/etc.


Reines 2011-02-22 13:24:11

  • Description changed. (Diff)

Mpok 2011-02-23 07:43:34

If u consider to add this BEFORE 2.0, please either do a mod of it, or add it in a SEPARATE subversion of 1.4.
Meant : 1.4.5 is 'normal' update, 1.4.6 is the 'parser udate' ONLY, 1.4.7 is the next 'normal' update, etc…
Don't mix the things. So we could use the new parser OR NOT (on 1.4.x).
On 2.0, the new parser will become the 'original' one.

Franz 2011-02-23 10:27:28

Yes, the current plans are to ship it as a modification for now.

Reines 2011-02-25 00:47:26

  • Milestone changed from 2.0-beta1 to 2.0-alpha3.

Franz 2011-11-15 12:56:14

Quite a few changes will be necessary, as the current code is not object-oriented.

Franz 2013-07-08 08:55:39

This project might be an alternative:

XAOS-Eric 2014-01-21 02:03:43

Actually, shouldn't be to hard to implement our own bbcode system.

Edit: here is an example of how it could be done.

Comment edited 1 times (Diff)

JoshyPHP 2014-01-22 01:47:34

@XAOS-Eric have you seen my topic?

Realistically, PECL extensions are only an option for people who control their PHP install (e.g. VPS) and install their own extensions. And even then, whenever the extension is updated (e.g. to fix a bug) the user needs to recompile/reinstall it and restart the server, which means bugs cannot be fixed by the developers without the user's intervention.

For that reason, a PHP library is much preferrable. The fact that mine is super kewl is just a bonus. smile

Comment edited 1 times (Diff)

Franz 2014-01-22 08:10:55

Oh, it's kewl? In that case, there's not even a question that we can use it. Why did you say so earlier? wink

XAOS-Eric 2014-01-22 13:50:01

@Franz I've been told there are two Laravel bundled that can help.
@JoshyPHP, awesome, I'll look into implementing your library into FluxBB 2. … codeparser

Franz 2014-01-22 16:16:45

From a simple glance at the code, the golonka/bbcodeparser package is far too simple, and won't even do simple error checking on the BBCode.

I'll take a look at Decoda and Joshy's library.

@Joshy: I'm sure you have analyzed the competition. What can you say about Decoda?

XAOS-Eric 2014-01-22 16:57:29

@Franz, looking at the features of Decoda, it has all the tags we would like to support, and allows for custom ones. I'll contact Miles, and find out if we can integrate it with FluxBB.

Edit: Already got a reply, he said yes smile.  @Franz, forwarded you the reply.

Comment edited 1 times (Diff)

JoshyPHP 2014-01-22 20:01:37

@Franz: yes I'm aware of other librairies. I have a Google alert so I get notified of every BBCode library that gets mentionned anywhere. There are lots of them and almost all of them I don't consider usable. (e.g. they don't validate anything) Decoda is not one of them. From what I can tell, it's a decent BBCode engine, as far as BBCodes are concerned.

However, there's a fundamental difference in terms of software design between s9e\TextFormatter and other librairies such as Decoda. I describe the bulk of it in this lenghty post. The short of it is I have designed my library with forum softwares and inexperienced admins in mind. And also I meant to support multiple markup from the get go.

@XAOS-Eric: I think one of the most important step is to discuss and define among FluxBB developers (sorry I don't know who exactly plans to work on FluxBB 2) what you want for FluxBB 2 in terms of functionality. Not just BBCodes and/or Markdown, but also whether you want to support custom BBCodes, whether you want forum admins to be able to change their templates (talking about BBCodes/Markdown), etc... I have a standing PR for the same thing in phpBB and what I learned there is that it's easy for people's assumptions to get out of sync. It would be much better to make sure everyone's on the same page by discussing what everyone wants, regardless of the actual implementation.

As for the actual implementation, I'm willing to write and contribute to FluxBB any code that is specific to my library. I think it's a more efficient use of both our efforts if I do anything that is entirely specific to s9e\TextFormatter and you do everything else. That can take the form of a generic stub, or an actual class if you want to provide an interface to FluxBB.