Naming Boards/blogs/sites etc.

Nao

  • Dadman with a boy
  • Posts: 16,061

DoctorMalboro

  • I like rounded borders.
  • Posts: 316

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #32, on April 13th, 2011, 04:08 PM »
Quote from Nao/Gilles on February 23rd, 2011, 03:39 PM
For instance, set a blog post to be a headline or introduction, show a list of the 5 most popular posts or 5 most recent, or a random selection of them, either in blog index format or just the link or something, and most importantly, actual text contents that should be used to 'link' the blocks between them.
In pages like this, if you actually allow some text from the message (say 140 characters?), in the "5 most recent' block, you will want a different set of parse_tags (perhaps to prevent images, or AEVA embedding in the truncated text). But you will still want the full set of parse_tags in the blog post or introduction.

I am running up against this problem every time I want to do a little customization on a portal page block. I like to keep using already-working code like ssi_recentPosts, when possible, but if I use $modsettings['disable_tags'], then what gets disabled stays disabled for the rest of the page. I cannot re-enable them when the block has finished its work.

Have you made any changes to parse_bbc to make it possible to disable, and then re-enable tags?
I'm an SMF doc writer.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Naming Boards/blogs/sites etc.
« Reply #33, on April 13th, 2011, 04:26 PM »
You know you can do that in SMF already, right?

Last parameter to parse_bbc is an array of tags that should be considered for that parse only.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #34, on April 13th, 2011, 05:07 PM »
Yeah, but if I want to call existing code (like ssi_recentPosts), I can't get to the parse_bbc call.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Naming Boards/blogs/sites etc.
« Reply #35, on April 13th, 2011, 05:09 PM »
You'd have the same situation in Wedge, and for the same reason. You can't do it without editing the calling code.

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #36, on April 13th, 2011, 05:21 PM »
Solving parse_bbc problems is a bear.
So -- add some parameters in SSI.php to either do what I want it to do or tell it I'll parse my own bbc.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Naming Boards/blogs/sites etc.
« Reply #37, on April 13th, 2011, 05:48 PM »
Either way you still have the fundamentally same problem to solve ;)

It's something I've put a little thought into, but not a lot because it's really something that really wouldn't normally be needed to be changed.

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #38, on April 13th, 2011, 05:53 PM »
If you ever start to want a very content-rich portal page, with several blocks doing different things, you might see parse_bbc differently.

Or you might not get hung up on the same things that us less-experienced coders break our teeth on.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Naming Boards/blogs/sites etc.
« Reply #39, on April 13th, 2011, 05:58 PM »
Well, if you're going down the road of building your own blocks, you're invariably not using SSI's inbuilt functions anyway so you have direct access to the parse_bbc call... so I guess I'm still not seeing the need right now...

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #40, on April 13th, 2011, 06:26 PM »
I'd rather string together existing code than write a bunch of new code, just to do a conceptually simple customization of a SimplePortal block that now uses ssi_recentPosts because that did what the designers wanted it to do.

Thanks for letting me know where you stand vis-a-vis parse_bbc. I hates it -- parse_bbc.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Naming Boards/blogs/sites etc.
« Reply #41, on April 13th, 2011, 06:27 PM »
Unfortunately what is 'conceptually simple' usually isn't in practicality.

IOW, parse_bbc can already do exactly what you want, out of the box, in SMF 2 and has done for a long time. What you're asking for isn't a change to parse_bbc, but a change of how the SSI functions work, which is a totally different concept.

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #42, on April 13th, 2011, 06:36 PM »
I understand what you are saying. I just think differently than you do.
Probably because you have more and better coding experience.

Nao

  • Dadman with a boy
  • Posts: 16,061
Re: Naming Boards/blogs/sites etc.
« Reply #43, on April 13th, 2011, 06:50 PM »
When it comes to giving the ability to build custom pages, I'm trying to think of something that's not done in the WP3 fashion (i.e. letting admins create "MyCustomThing.custom-page-suffix.php"), mainly because of the MVC conflicts, but it's hard really. Why am I talking about that anyway?
parse_bbc() is, it's well known, the most cpu-intensive function in SMF/Wedge. There's not much we can do about it (apart from micro-optimizing, which isn't easy at all here). I tend to avoid SSI functions because they usually don't do things in the most optimal way for me -- namely, if they parse tags for a field I'm never going to show anyway, it isn't cool. But there isn't any solution ready for use right now. Maybe portal authors could share their thoughts about this...
But all in all, it's not something I feel I'm ready to tackle right now. My priority is on integrating the Media area anyway.

AngelinaBelle

  • Still thinking...
  • Posts: 92
Re: Naming Boards/blogs/sites etc.
« Reply #44, on April 13th, 2011, 07:19 PM »
bbc versioning.

I am given to understand, from some of [Unknown]'s posts, that a significant part of the complexity/resource-hogginess of parse_bbc is to support "backwards compatibility". I can't quite follow how parse_bbc picks the correct version of a given tag. And I don't know what all other stuff is in there for "backwards compatibility"

Declare all "old" posts to belong to "old parse_bbc" and let "old parse_bbc" parse them.
Force new posts to conform to "new bbc" usage, and use a "new parse_bbc" to parse them.
As the old posts recede into history, "old parse_bbc" will be called less and less often.

And "new parse_bbc" will be called more and more often, for a modest performance improvement.
Portal and AJAX chatbox authors have already found that drastically reducing the size of parse_tags can yield very large performance improvements.