Wedge

Well, yes, that's what I meant :P But you see what I'm getting at - some people will want notifications on *everything* and some just on what interests them.Sounds legit :bravo:

Is that notification on 'new topics', 'new posts in topics you're watching' and 'new posts in topics you're watching but only for the first unread post'?

As for boards, is that 'new topics', 'new topics and new posts in topics you're watching', 'new topics and all new posts'?

There are people who want this stuff >_<

(I'm not sure whether it *should* be, I'm just trying to get a feel for what it currently is and what the plans are for it rather than whether it should do these things.)

That works for me.

Also, when looking through the code the other day, I realised the subtle change that occurs... it actually replaces the old notifications area for board/topic notifications by replacing area=notification in the profile. I take it that was intentional?

Hrm, yes it was done on auto pilot to a degree. It's also complicated because of what's going on :/ It may even be broken, I don't know. But the changes to plugin-info.rng should indicate what is intended.

:edit: One deals with the permission groups, one deals with the individual permissions and the group it is supposed to go into. They should not both be the same. I will fix it in my next rev.Fairly sure I gave the notification action a title some days ago.Can a skin replace part of index.template.php?I tested it a long time ago, haven't bothered to test it again since I wasn't sure I wanted to keep any of it; it distinctly occurred to me that I could start from fresh and fix some of the logic issues in it by better design. For example multi-user assignment was a big request but it's not just a schema change.And I see no reason off hand why this should even work. preparsecode has always converted line breaks out - always.I'm not being funny but did you even look at the UI in the admin panel for this?

The reason my file had no line breaks and br tags in it is because I ran it through preparsecode. That's what preparsecode does, amongst other things: strips the line breaks and converts them to br tags. I then specifically call un_preparsecode on it when I prepare it for the rich text editor so that people can use full formatting it without having to get their hands dirty like they had to in the old days - hell, most people didn't even know the agreement supported bbc parsing.

So I checked parse_bbc and lo, there is a linebreak to br conversion, yet I cannot think of a single time outside of this one area where this ever EVER comes into play.

The news area... stores all news items, one per line, with preparsecode having chewed through and converted all the line breaks to br tags.

Posts... they're all on one line, not that it seriously matters either way.

Agreements... they're the odd ball. I deliberately tried to harmonise it - working under the assumption that it had to be that way as it was my understanding that parse_bbc didn't do linebreaks.

But now everywhere that uses parse_bbc gets its content with preparsecode attached, agreements never used to get that IIRC. Result: everywhere that parse_bbc gets content, it's doing it without line breaks, therefore no need for parse_bbc to convert line breaks, therefore agreements shouldn't have line breaks anyway.And, as ever, I wasn't intending them to have to edit it as such. The grand plan involves having language editing tools for translators on this site. Which would naturally have a variation of the editor as in the admin panel... which means they wouldn't see the raw code (because they don't really need to)You are not a regular user. You're a user who is more than willing to get your hands dirty with code. Almost every single other admin out there won't dare touch a PHP file unless they're having their hands held.

The idea of having a template like this is a noble one, but it's also sadly naive of our userbase - it's giving them infinitely more credit than most of them would actually be due.

This is why I've been talking about content management and adding a CMS into the mix for the simple reason that most admins can only manage something if given a nice UI to play with, it's why so many of them jump to Simple Portal and co, so that they can have nice front pages and so on.So instead of giving them the barest bones tools for the job, we need to give them more powerful tools.

(7 files, 6KB)

Revision: 2031
Author: arantor
Date: 28 March 2013 03:52:37
Message:
! Missed English UK translation. It's entirely possible there will be more. (Reports.english-uk.php)
! Group styling is now handled with CSS classes, dynamically pulled into index.css. It's all very magical. If you're very good, I might even extend this to include bold and italics and stuff. But only if you're very well behaved. (ManageMembergroups.php, Profile-Modify.php, Subs-Cache.php, Subs-Membergroups.php, Subs-Template.php, index.css)
----
Modified : /trunk/Sources/ManageMembergroups.php
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Membergroups.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Themes/default/languages/Reports.english-uk.php
Modified : /trunk/Themes/default/skins/index.css

Oh, no disagreement. I'm just saying that compared to changing fonts for user preference, changing size is an order of magnitude simpler for users.If you need to scale the text up to see it better, you probably need to do the same with images. Browsers never used to scale up everything, they only used to scale up the text, but manufacturers realised that in the end they should do it for all content (IIRC Opera was the first to do that, it took a long time for everyone else to adhere to it)

Sure it was... it's debugging information in trying to figure out where the popup should be displayed.