Adding cat as a top level var means adding a pretty URL rule for it. I'm not fond of the idea... But one pro is that it allows us to link to the URL even if boardindex is the default. Hmm.
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
It's a tricky one because there's pros and cons both ways.
In other news, would it be worth writing a post detailing exactly what the add-on manager does and all its overall mechanics? (Most of it, an add-on author shouldn't need to worry about anyway, but just in case, do you think it'd be useful?)
In other news, would it be worth writing a post detailing exactly what the add-on manager does and all its overall mechanics? (Most of it, an add-on author shouldn't need to worry about anyway, but just in case, do you think it'd be useful?)
In other news, I found a bug in the new blocks code. I'll dig into it shortly (if I get time, I have other stuff I want to finish first).
Specifically, if you activate the popup in any place (be it my crude use of it in the add-on manager for readmes, but also for normal help popups) you get the RSS block appended to it...
Specifically, if you activate the popup in any place (be it my crude use of it in the add-on manager for readmes, but also for normal help popups) you get the RSS block appended to it...
Also, I'm thinking that the menu notice style could do with tweaking.
.menu strong declares padding: 2px 4px, but I think it might look better (does to me, at least) with padding: 2px 6px.
.menu strong declares padding: 2px 4px, but I think it might look better (does to me, at least) with padding: 2px 6px.
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
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Re: cat, I suppose nobody has an opinion on this... Not even us :( Argh.
Re: add-on manager, most likely at the end of the process?
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions. Which made me realize my process is really flawed in that respect... So I changed it and now, all blocks will be refused if their target layer doesn't exist. If a block is vital, then the modder should add a context fallback to it. I'm also adding code to prevent mods from removing said context layer...
Re: I did a lot of tweaking for the menu padding before, and, err... What can I say -- 6px is a bit much for me. 5px is fine however. It's a good compromise :lol:
Re: add-on manager, most likely at the end of the process?
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions. Which made me realize my process is really flawed in that respect... So I changed it and now, all blocks will be refused if their target layer doesn't exist. If a block is vital, then the modder should add a context fallback to it. I'm also adding code to prevent mods from removing said context layer...
Re: I did a lot of tweaking for the menu padding before, and, err... What can I say -- 6px is a bit much for me. 5px is fine however. It's a good compromise :lol:
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Re: cat, I suppose nobody has an opinion on this... Not even us
Re: add-on manager, most likely at the end of the process?
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions.
Re: I did a lot of tweaking for the menu padding before, and, err... What can I say -- 6px is a bit much for me.
Nao
- Dadman with a boy
-
-
- Posts: 16,082
I've decided that I'll use ?cat= for consistency, as you suggested.
Also, I won't make a PURL rule for it -- unless you definitely want to, but right now I'm thinking, the PURL rule is only for consistency, and it really doesn't matter that much -- ?cat is only going to be used in the linktree and a couple other links, and it's very short anyway... It's not like it hurts my eyes to see that.
Having problems with the padding BTW. I noticed that with a notification there, a menu entry will be 1 pixel taller, meaning that if the entire menu wraps (smaller window), second-line items are shown horizontally after the item that has the notification. Yikes.
So I turned them into inline-blocks and it works, but then I remembered that inline-blocks take whitespace into account, ah ah... Well, there are hacks to prevent that anyway.
Re: layers, well, do you think I should set $where to a different default depending on the target layer...? $target = context, $where = replace by default. $target != context, $where = add by default. It would allow us to remove the $where param from pretty much all loadBlock calls, but it's really not exactly 'obvious'.
Oh, and I think I have a couple of questions/concerns in the New Revs topic that you didn't comment on. If you don't mind.
Oh crap, I have so many things left to reply/comment, myself... :(
Also, I won't make a PURL rule for it -- unless you definitely want to, but right now I'm thinking, the PURL rule is only for consistency, and it really doesn't matter that much -- ?cat is only going to be used in the linktree and a couple other links, and it's very short anyway... It's not like it hurts my eyes to see that.
Having problems with the padding BTW. I noticed that with a notification there, a menu entry will be 1 pixel taller, meaning that if the entire menu wraps (smaller window), second-line items are shown horizontally after the item that has the notification. Yikes.
So I turned them into inline-blocks and it works, but then I remembered that inline-blocks take whitespace into account, ah ah... Well, there are hacks to prevent that anyway.
Re: layers, well, do you think I should set $where to a different default depending on the target layer...? $target = context, $where = replace by default. $target != context, $where = add by default. It would allow us to remove the $where param from pretty much all loadBlock calls, but it's really not exactly 'obvious'.
Oh, and I think I have a couple of questions/concerns in the New Revs topic that you didn't comment on. If you don't mind.
Oh crap, I have so many things left to reply/comment, myself... :(
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
So I turned them into inline-blocks and it works, but then I remembered that inline-blocks take whitespace into account, ah ah... Well, there are hacks to prevent that anyway.
Re: layers, well, do you think I should set $where to a different default depending on the target layer...? $target = context, $where = replace by default. $target != context, $where = add by default. It would allow us to remove the $where param from pretty much all loadBlock calls, but it's really not exactly 'obvious'.
Oh, and I think I have a couple of questions/concerns in the New Revs topic that you didn't comment on. If you don't mind.
@ Need to write a multi-language error for the context layer error... Would you care to write it, Pete? I lack inspiration to do something that can be understood by normal users and not overly dramatic at the same time
Assuming that it's only ever add-ons that will cause that... show this to users.
"Template Skeleton Error
Wedge maintains what's called a template skeleton, to set out the page structure. Unfortunately, it appears that an add-on you have installed has damaged this skeleton, and the page cannot continue. The administrator has been made aware."[1]
Alternatively for administrators:
"Template Skeleton Error
Wedge maintains what's called a template skeleton, to set out the page structure. Unfortunately, it appears that an add-on you have installed has damaged this skeleton, and the page cannot continue. You should contact the author of the add-on you installed and were trying to use at the time this error occurred."
It's vague but unless we can tie it down to a given add-on, that's really about the best we can do, unless you want to log the backtrace of calls made to loadBlock to see the file that the place the call came from (which will give you a path which will, by extension, identify any add-on that isn't using file edits)
| 1. | Because it should be logged, assuming you didn't pass false as the second parameter to fatal_lang_error, haven't checked. Ideally it should be 'template' here. |
Nao
- Dadman with a boy
-
-
- Posts: 16,082
- Probably, but then it doesn't look as good. Went for inline-block with a negative left margin. It's a fair trade. It would be best to set the parent to font-size:0, line-height: normal but then I'd have to specify the font-size on the menu itself, instead of using the inherited value.
- Maybe I should start by renaming the main layer... Right now it's 'context' because its contents changes according to what page we're in, but technically the sidebar is the same.... What should I use? 'default'? Keep 'context'? Ah, if only I could name it just 'main' like it was... But that would mean I'd have to rename all blocks to 'index' or something. (template_index instead of template_main)
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer. (They may be able to do it through a replace in loadLayer... Would have to check though...) They can only do it with direct manipulation of $context['layers'] or $context['skeleton_array'].
Okay I have this error message, tried to keep it short and usable by both. Tell me if it needs changing:
Wedge won't show you the contents of this page, as its layout was detected to be corrupted, possibly by a skin, a theme or an add-on.<br><br>This has been reported to the administrator.
(And yes, it's logged, as you can see in the SVN ;) I need to put these into language strings though.)
- Maybe I should start by renaming the main layer... Right now it's 'context' because its contents changes according to what page we're in, but technically the sidebar is the same.... What should I use? 'default'? Keep 'context'? Ah, if only I could name it just 'main' like it was... But that would mean I'd have to rename all blocks to 'index' or something. (template_index instead of template_main)
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer. (They may be able to do it through a replace in loadLayer... Would have to check though...) They can only do it with direct manipulation of $context['layers'] or $context['skeleton_array'].
Okay I have this error message, tried to keep it short and usable by both. Tell me if it needs changing:
Wedge won't show you the contents of this page, as its layout was detected to be corrupted, possibly by a skin, a theme or an add-on.<br><br>This has been reported to the administrator.
(And yes, it's logged, as you can see in the SVN ;) I need to put these into language strings though.)
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
- Maybe I should start by renaming the main layer... Right now it's 'context' because its contents changes according to what page we're in, but technically the sidebar is the same.... What should I use? 'default'? Keep 'context'?
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer.
Okay I have this error message, tried to keep it short and usable by both.
Posted: September 20th, 2011, 09:41 AM
Re languages: in theory if the language that a board (or user, for that matter) doesn't exist, it should still be falling back to the forum default.
live627
-
-
- Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
- Posts: 1,670
- Removed compactTopicPagesEnable setting
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Re r1024: Um, $addon_dir shouldn't ever be empty because it should be set earlier in the file (lines 37-8)... what exactly was the error you were getting?
Nao
- Dadman with a boy
-
-
- Posts: 16,082
@John> ?Quote from Arantor on September 20th, 2011, 11:56 AM I think 'default' will be just fine. I haven't felt a desire to change it, which is a good sign :PQuote The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...Quote Although I'm totally pro-objectifying (?) stuff, including mine, I wouldn't know where to start (i.e. I can maintain an object but convert something to an object is something I can't do with confidence), I'm also not sure whether it's actually worth the hassle... I mean, if a mod removes 'default', their author will notice soon enough...Quote I'd tend to say that admins are in the same crap as users here -- it's really the themer we should be talking to...Quote No, that's not what I was saying... If a board has a default language, different than the forum's, *and* the admin disabled the ability to change languages for users, i.e. $modSettings['userLanguages'] or whatever is false, then getLanguages() is not called... And my test code isn't, either.Quote from Arantor on September 23rd, 2011, 12:40 AM I haven't written it down, but XDebug basically crashed saying "delimiter is empty", IIRC.
Although... Come to think of it, $addonsdir is defined in Settings.php, right? Then yeah, my mistake-- I haven't updated my Settings.php files to add them. I'm not in a hurry to do it... Would have to do it for my local install, as well as the demo and the import demo... :^^;:
Feel free to revert that one in your next commit, btw. Or whatever.
'default' works, as incidentally does 'context'. I'd avoid main though, for precisely the reason you give.
OK, what part are you not sure about, exactly? It seems to me the current behaviour is pretty logical.Quote I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
Oh, yeah, oops. You know, there is a solution to that: turn it into an object, make the list a private variable of that object so only the object's methods can modify it. You'd have to move a bunch of stuff from Subs-Template into a class but it would effectively nail the problem.
It's fine for users but not a lot of help for an administrator. Much better, then, is if we can provide a separate error for administrators with a little more detail in it.
Re languages: in theory if the language that a board (or user, for that matter) doesn't exist, it should still be falling back to the forum default.
Re r1024: Um, $addon_dir shouldn't ever be empty because it should be set earlier in the file (lines 37-8)... what exactly was the error you were getting?
Although... Come to think of it, $addonsdir is defined in Settings.php, right? Then yeah, my mistake-- I haven't updated my Settings.php files to add them. I'm not in a hurry to do it... Would have to do it for my local install, as well as the demo and the import demo... :^^;:
Feel free to revert that one in your next commit, btw. Or whatever.
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Although I'm totally pro-objectifying (?) stuff, including mine, I wouldn't know where to start (i.e. I can maintain an object but convert something to an object is something I can't do with confidence), I'm also not sure whether it's actually worth the hassle... I mean, if a mod removes 'default', their author will notice soon enough...
I'd tend to say that admins are in the same crap as users here -- it's really the themer we should be talking to...
No, that's not what I was saying... If a board has a default language, different than the forum's, *and* the admin disabled the ability to change languages for users, i.e. $modSettings['userLanguages'] or whatever is false, then getLanguages() is not called... And my test code isn't, either.
I haven't written it down, but XDebug basically crashed saying "delimiter is empty", IIRC.
Also, in add-on related news, WedgeDesk is now capable of being installed (and running) cleanly from the add-on manager. The only thing it can't handle right now is attachments, and that's only because it's expecting to use the old attachment handling code which I haven't removed yet.
On that note, actually... I was thinking about how to handle attachment access for things like WedgeDesk that have their own authentication needs and that have different needs to the norm. Galleries, by definition, are accessed at gallery level, but we need to change that to being determined at board level for attachment gallery items. I'm not sure how we'd do *that*, but the solution for handling attachments generally when it's an external source seems fairly clear: have a hook that attempts to make the query that Dlattach.php normally would (or MGalleryItem.php, whatever query would normally be run to identify a file and validate the user can access it), and the hooked functions should return the necessary information, or false - that way, systems can deal with it as necessary.
Dragooon
- I can code! Really!
-
-
- polygon.com has to be one of the best sites I've seen recently.
- Posts: 1,841
Dragooon's theme disables itQuote - Removed compactTopicPagesEnable setting
 | The way it's meant to be |