Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
4546
The Pub / Re: Getting ready for an alpha release: CSS fixes
« on August 31st, 2012, 05:29 PM »
Re: 1, I tested under all 5 main browsers, and only Firefox has big issues with box-shadows everywhere... Others work okay. With the fastest being Opera and... IE9, oddly!
Still, dunno if I'm going to do that for windowbg/postbg. It's probably best to keep my inset box shadows to places that don't repeat indefinitely on a page.
Still, dunno if I'm going to do that for windowbg/postbg. It's probably best to keep my inset box shadows to places that don't repeat indefinitely on a page.
4547
The Pub / Re: Logo Madness
« on August 31st, 2012, 02:40 PM »
Isn't for me.
Some pages will be screwed if they have MultiformeIngegno's posts on them, though -- I pointed out elsewhere that there was a problem with the hardcoded size of blurb elements that could result in breaking the HTML.
Some pages will be screwed if they have MultiformeIngegno's posts on them, though -- I pointed out elsewhere that there was a problem with the hardcoded size of blurb elements that could result in breaking the HTML.
4548
The Pub / Re: Logo Madness
« on August 31st, 2012, 02:19 PM »
You don't have to be torn...
1/ Right now, the official logo is the current one (the one in my signature and yours, etc), the other one is just a test.
2/ I'm not going to choose a final logo before the gold release -- and even then, I can always use a new one later. After all, maybe someone will come up with a better one ;)
3/ I only split the topic into this one because it's what we're talking about. Right now we're discussing new logos, we're not trying to determine if the new one is better. (I only added it to the poll for fun, but as you can see I didn't change my vote and I'm not expecting anyone to...)
1/ Right now, the official logo is the current one (the one in my signature and yours, etc), the other one is just a test.
2/ I'm not going to choose a final logo before the gold release -- and even then, I can always use a new one later. After all, maybe someone will come up with a better one ;)
3/ I only split the topic into this one because it's what we're talking about. Right now we're discussing new logos, we're not trying to determine if the new one is better. (I only added it to the poll for fun, but as you can see I didn't change my vote and I'm not expecting anyone to...)
4549
Other software / Re: SMF and Aeva
« on August 31st, 2012, 11:15 AM »
Nope... I'm not providing direct support for Aeva or Aeva Media or whatever.
There's an Aeva topic on sm.org which none of us are monitoring, but that's the best you'll be getting I guess. If someone discovers a bug I should fix in the Wedge implementation, I suppose they'll be poking me about it.
There's an Aeva topic on sm.org which none of us are monitoring, but that's the best you'll be getting I guess. If someone discovers a bug I should fix in the Wedge implementation, I suppose they'll be poking me about it.
4550
The Pub / Re: Logo Madness
« on August 31st, 2012, 11:15 AM »
This is the same discussion that's been going on for a few days now... I just moved it to the proper place. What's the problem?
4551
The Pub / Getting ready for an alpha release: CSS fixes
« on August 31st, 2012, 11:13 AM »
Been busy IRL blah blah blah, worked on a few things that I wanted to fix in my CSS. Not happy with the things I've had to give up for that... So I want your opinion, because all of this has been accumulating over the last couple of days, and last time I checked, I really wanted to commit everything I have before I'm ready for an alpha.
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
1/
Gradients in headers (Wine and children): for a long time, what I used was a very small PNG image, which allowed it to work in IE6+. Recently, I decided to replace gradient images with proper gradients, as IE6 doesn't deserve any non-essential goodies anyway. So I did that.
Then I realized that an issue with linear-gradient, is that to get the same effect as an image, you have to specify color stops in pixels, and then set an explicit background-size... It's a bit complicated, but I did it. (Unfortunately, it also meant that the resulting CSS was probably on par with the earlier one in terms of size :P)
Okay, so this morning, I was thinking... "What the hell?! I could simply be using an inset box-shadow to act as the inner gradient! And I get to set my pixel dimensions!"
And it works fantastic. Really. It's just a single line of code. It works in IE9+, and it's cleaner.
However... There's a catch.
The performance is excruciatingly slow when there are lots of these, e.g. alternating backgrounds in the error log or display page. Really. Under Opera 12.5, it runs fine, just a bit less responsive, but when you show a confirm box, you can see how long it takes to show up... Under Firefox 16, it's like night and day. Super fast with a gradient, HORRIBLY slow with a box-shadow.
That's really, really annoying because the results are much better in box-shadow mode!
So... What do you reckon I should do? Is there a way to fix performance? I'm talking about a test done on a Core i7 computer... :-/
2/
Another thing that always bothered me... Wedge using JavaScript to reposition the sidebar, instead of media queries. This was originally because I would 'switch' positions between two different elements, so that I could set a specific target for the sidebar inside the DOM, instead of using CSS tricks to reposition it. As time went by, I decided to save bandwidth in all HTML pages by applying a 'responsive' ID to the DOM's top instead, and I hacked into the CSS in a relatively clean way that I was satisfied with. Okay, so far so good...
Now, this morning I was looking at my code, and the first thing that came to mind was, "WTF?! I use #responsive to set specific media queries... Why not just use @media $responsive?". And this is exactly what I did...
So, $responsive is set to a max-width of 1000px for now, it's working okay. The main benefit here is that because it's done on the CSS level, there's absolutely zero FOUC effect when reloading a page. (There used to be a very, very short one when doing a F5 refresh.)
Plus, I think themers will be comfortable with that... As long as they know about responsive design, of course.
Now for the drawbacks...
- @media doesn't have a set precedence factor, so it doesn't change priorities in the code, unlike #responsive. This means that if you set a #responsive #sidebar to 'display: block' in index.css (or even in an hypothetical extra.css file in Weaving), and then set #sidebar to 'display: table' in a sub-skin's extra.css file, the resulting responsive page will have #sidebar set to display:block because #responsive has higher priority. But if you start replacing all of these with @media $responsive, the resulting responsive page has #sidebar set to display:table because it was filled in after the original media query. The (clean!) solution I'm using, is to take the original media query, copy it at the end of my extra.css file, and add a reset suffix to it. Yes, "@media $responsive reset" is all that's needed. This way, the original media query is removed, and the new one is set at the one, and it includes the original media query's rewrites. Yes, it isn't as bulletproof as direct inheritance because if Weaving is heavily modified you'll have to modify your sub-skin as well. But it's probably something that could also happen with #responsive, albeit with different issues.
- Perhaps an even worse one... Unfortunately, @media being a special construct, you can have a selector like ".myclass, #myid, @media all .anotherclass", ah ah. Well, Wedge doesn't even bother checking... It actually does build such a selector if you add an 'extends' keywords to .anotherclass in the media query. Which pretty much makes the css declaration fail. So, yes, it does mean that whenever you start declaring a media query, *you can't use any extends in it.* Bummer!
So, I'm seriously considering going back to the 'original', as flawed as it is.
3/
And finally... The menu arrows.
Currently, they're using a lightweight (150-byte) image with horizontal and vertical positions, as well as a hover version.
I decided that I wanted to associate the arrows with the text next to them -- so that you can set the text to any color and they'll follow the color. So I replaced the arrows with CSS right-floated 'content' set to '\a0\25bc' (IIRC), in a pseudo-class of course. It seems to work really fine. This also allowed me to remove a couple of CSS hacks I had for the arrows. Unfortunately, this technique also has its limitations... Apart from the fact that pseudo classes don't work in IE6 (fuck you IE), there's the fact that Firefox shows arrows using a largely different size compared to Opera (?!), and float issues in the different places where it's all used, e.g. menu arrows aren't floated the same way when they're in the top-level menu or inside the menu itself. Same with linktrees...
This one is more of a technical issue to me, as philosophically I think I'm really good with using CSS content rather than images.
Anyone got any experience with that...?
4552
The Pub / Re: Logo Madness
« on August 31st, 2012, 10:18 AM »
(Updated the French page logo again... Fixed the small bug in the middle of the W shape, and freed the W from masking, thus covering the Wedge text as well. An interesting result. I should really move this to the Logo madness topic...)
Okay, split the topic...
Oh, interesting layout bug caused by Lorenzo's blurb... Hmm.
It's actually due to his text reaching the internal limit of 255 bytes. Could be fixed either by better cropping or increasing the blurb size. What do you think..?
Posted: August 31st, 2012, 10:12 AM
Okay, split the topic...
Oh, interesting layout bug caused by Lorenzo's blurb... Hmm.
It's actually due to his text reaching the internal limit of 255 bytes. Could be fixed either by better cropping or increasing the blurb size. What do you think..?
4553
Features / Re: New revs
« on August 29th, 2012, 04:18 PM »
rev 1678
(3 files, 2kb)
! SSI was broken since a commit made a year ago... Interesting. Well, not that much broken, you just need to change your starter code to just this: require_once('SSI.php'); ssi_run();[1], where ssi_run() is the new (more telling) name of ssi_shutdown(). So, this is effectively easier, but you also need to wrap your actual page code inside a template_main() function. Also removed $ssi_layers as using the wetem object is more flexible. (SSI.php)
! Fixed a missing default 'checked' when creating a new poll. (Post.template.php)
- Minor class cleanup. (Wuthering/extra.ie[-9].css)
(3 files, 2kb)
! SSI was broken since a commit made a year ago... Interesting. Well, not that much broken, you just need to change your starter code to just this: require_once('SSI.php'); ssi_run();[1], where ssi_run() is the new (more telling) name of ssi_shutdown(). So, this is effectively easier, but you also need to wrap your actual page code inside a template_main() function. Also removed $ssi_layers as using the wetem object is more flexible. (SSI.php)
! Fixed a missing default 'checked' when creating a new poll. (Post.template.php)
- Minor class cleanup. (Wuthering/extra.ie[-9].css)
| 1. | For instance, the license page for Wedge has this...<?php |
4555
The Pub / Re : Re: More thoughts on SMF 2.1
« on August 29th, 2012, 02:55 PM »
You have to switch to French to switch the logo. This was an oversight on my part.
4556
The Pub / Re: Skin showdown
« on August 29th, 2012, 01:36 PM »Check your look and layout preferences, you might have turned it off sometime. It does still do it for me AFAIK.Quote Oh, and once again, your post didn't bring up a warning on my side when I posted my message!
And yet -- once, between these two dates, I did get a notification. It's like it's doing it on a whim...!
Hmmm, nothing in the error log. Is it absolutely reproducible? If so, turn on the debugging info and take a look at what happens.Quote And what do you think of the crash bug?
Or more precisely, it was yesterday... Today, it seems to be showing to me.
Page created in 0.16 seconds with 28 queries.
(DR: 0.03 seconds with 3 queries.)
4557
The Pub / Re: Skin showdown
« on August 28th, 2012, 08:02 PM »Out of curiosity..which ideas would that be? I know you are protective of Wedge, but if you feel I *take" things from it, I'd like to be informed about that - so that I at least can *not* do that anymore lol. On the other side..if its some design bit you feel is whats been taken, it may not have been even conscious. I have actually been trying various stuff over the years, most of which didn't catch on, but nevertheless was interesting to explore.
Perhaps Pete remembered the mention I made about your last ViennaBBS theme, with its use of Segoe UI everywhere, as I commented that my local install was a Segoe UI and I was planning to commit it, and then you came and made it look like I'd taken the idea from you ;)
Of course, there are not exactly so many 'usable' webfonts around... My choices are limited to Arial/Helvetica (the most commonly used font online, I believe), Tahoma (with a fallback for bold and italics), Verdana (not so fun these days), Segoe UI (with an Arial fallback), Calibri (with a fallback on the x-height compatible Source Sans Pro -- one of my favorite solutions actually), Georgia (not a good idea to use it across the entire UI...!), or embedding a lightweight one-size-fits-all webfont like Droid Sans, Open Sans or PT Sans (not so light though this one). But it's a bad idea to embed a font by default, it should be seen only on specific forums, so it's a no-go for me.
Actually, when I made Curve it was far from boring lol. I was very excited
Also -- round corners. But it was long before CSS3 came into play, so it wasn't exactly a fun implementation...!
You must not have had fun making it IE6 compatible! Or maybe other people did all the work on that..?
You see more VB clones than SMF2 clones, but still SMF 2.0 is popular.
So it could either be fixed (in my mind) by using a different theme on sm.org than the default, or providing a much simpler skin for SMF2 and setting it to the default, while still providing Curve as an aside. But it's not a realistic solution...
Thing is, the more complex/convoluted a default theme, the more shocking it is when everyone starts running it.
It's one of the reasons I wanted to simplify Wine (and came up with Weaving), but it's even worse than that -- I'm actually wary (weary?) of seeing Weaving used on other sites...!
Heck, if anything, I should provide a huge box at install time, with the text "Please change the default colors! What do you want? Yellow? Green? Blue? Violet?"...
Blue is a calm color, it gives off a sense of stability and strength that no other color can match.
And...adding a sidebar isn't really that innovative, despite what you might think.
Forcing it on the user, though, was rather innovative I'd say. And still providing a way to put it away -- by reducing the window width -- is even better.
I've never been fully happy with the contents of the sidebar, though. I'd like it to remain more consistent across pages.
Portal mods have been indulging in them for years. While its certainly fresh to use them to attaching links and info related to your current whereabouts in the forum, its not new as such. I did that with the Simplicity theme for SMF 1.1, over 6 years ago. It was interesting then, but Simplicity theme was maybe too much at the time.
Posted: August 28th, 2012, 08:01 PM
It's funny, I thought I'd already made this point?
Posted: August 28th, 2012, 08:02 PM
Oh, and once again, your post didn't bring up a warning on my side when I posted my message!
And what do you think of the crash bug?
4558
The Pub / Re: Skin showdown
« on August 28th, 2012, 07:48 PM »
Oh, bugger... I'm having problems with page 2 of this topic. It just doesn't output anything.
I tried to reduce the number of posts shown. If I show 13 posts, it works. If I show 14, blank page.
It doesn't seem to be related to the post content. Probably a server timeout I'd have said, but it usually sends the blank page immediately, not after a certain delay... :-/Quote from Oracle on August 26th, 2012, 06:41 PM As I said, you can look into Vanilla if you want a different layout... Or BBPress, mostly for its homepage. (Which always makes me think of Bloc's Simplicity, too...)
But it doesn't mean it's any better.
Wedge's layout is the same as your usual forum, except that it tries to simplify it.
The opposite being vBulletin, which is so full of crap, it became funny at some point. (Clearly software that wasn't made by designers...)Quote from Oracle on August 26th, 2012, 06:41 PM The Facebook story is special in its own way... Heck, that story was even worth an Academy Award :P
The same happened with Twitter: the website attempts to lure in the 'decision makers' and influential users (in the case of Facebook, it was Harvard grads then Ivy League grads then college grads etc... For Twitter, it was web designers first, then movie/music stars, then their fans.)
Basically, people don't come to Facebook or Twitter because they 'like it better', they come because someone they like is on it (possibly because they thought it was better, most likely because they didn't know better), then they bring in their family, etc... The more people were in, the easier it was to get more people to join.
MySpace is a good example of a website that stole the lightning from other sites (like Friendster), mainly because of its name (reminded people of piracy), and focus on music artists (see, Facebook made sure to replicate MySpace's music features to lure them in). Then MySpace lost its market shares because it simply sucked. But there's a huge difference between bad management/bad designers (which is the reason MySpace fell) and Facebook actually being great... No, it was just 'better' because, at least I'm talking as a web designer, it was important to impose a visual layout that couldn't be modified by users -- it gave its identity to Facebook, while MySpace didn't have an identity, only badly made web pages.
So... To sum up: people don't jump ship because they embrace change -- they jump ship because they find a better solution that is usable without a steep learning curve.Quote I work on the logo on my spare time, i.e. it's not as important as Wedge itself, but sometimes I need to relax so I'll just play a quick Spider Solitaire or a Scrabble on my iPhone or look into the logo and try to make changes to it.
It's just plain fun for me.
Working on redoing the UI from scratch? Not so much... All forum software share a common root for a very good reason: if you were to redo it from scratch, you'd iteratively come up with exactly the same results, months later. Because there's only so many ways you can present a list of messages with a userbox next to it...
I tried to reduce the number of posts shown. If I show 13 posts, it works. If I show 14, blank page.
It doesn't seem to be related to the post content. Probably a server timeout I'd have said, but it usually sends the blank page immediately, not after a certain delay... :-/
- I’m acutely aware of what your trying to achieve with balance. As for my suggestion Im not fussed one way or the other, however I still see it’s only cosmetic and not that big a deal... certainly not change for change sake. Most if not all forums UIs do look outdated and as though they were modelled a decade ago. I still feel that’s reason enough to take on a new look particularly in Wedges case..” To give Wedge a bit of an Edge”Quote Because we have to balance a goal that a lot of people seem to have forgotten.
But it doesn't mean it's any better.
Wedge's layout is the same as your usual forum, except that it tries to simplify it.
The opposite being vBulletin, which is so full of crap, it became funny at some point. (Clearly software that wasn't made by designers...)
- Disagree. How do you explain the mass exodus from My Space to Facebook &Twitter for that matter. All their members ride the wave of popularity not because they’re stuck in the past but because they embrace change,
The same happened with Twitter: the website attempts to lure in the 'decision makers' and influential users (in the case of Facebook, it was Harvard grads then Ivy League grads then college grads etc... For Twitter, it was web designers first, then movie/music stars, then their fans.)
Basically, people don't come to Facebook or Twitter because they 'like it better', they come because someone they like is on it (possibly because they thought it was better, most likely because they didn't know better), then they bring in their family, etc... The more people were in, the easier it was to get more people to join.
MySpace is a good example of a website that stole the lightning from other sites (like Friendster), mainly because of its name (reminded people of piracy), and focus on music artists (see, Facebook made sure to replicate MySpace's music features to lure them in). Then MySpace lost its market shares because it simply sucked. But there's a huge difference between bad management/bad designers (which is the reason MySpace fell) and Facebook actually being great... No, it was just 'better' because, at least I'm talking as a web designer, it was important to impose a visual layout that couldn't be modified by users -- it gave its identity to Facebook, while MySpace didn't have an identity, only badly made web pages.
So... To sum up: people don't jump ship because they embrace change -- they jump ship because they find a better solution that is usable without a steep learning curve.
- Here’s a thought...Why so much focus on Logotype development and not as much on UI...they lend themselves to defining Wedges identity. Their importance in terms of defining Wedges marketability is of equal significance as is the performance of the product?
It's just plain fun for me.
Working on redoing the UI from scratch? Not so much... All forum software share a common root for a very good reason: if you were to redo it from scratch, you'd iteratively come up with exactly the same results, months later. Because there's only so many ways you can present a list of messages with a userbox next to it...
4559
The Pub / Re: Skin showdown
« on August 28th, 2012, 04:49 PM »
IE9 sucks.
Unlike what the giant HD ad said at the theater right before the DKR movie. I was expecting someone to have a good laugh in the room but everyone was watching candidly, ugh.
So... Because I can't reproduce on my system, I'm not going to bother, if you don't mind.
Unlike what the giant HD ad said at the theater right before the DKR movie. I was expecting someone to have a good laugh in the room but everyone was watching candidly, ugh.
So... Because I can't reproduce on my system, I'm not going to bother, if you don't mind.
4560
The Pub / Re: Getting ready for an alpha release...
« on August 28th, 2012, 04:46 PM »Let's just put that into context. sm.org has been around almost 10 years, and in that time hasn't even pushed an id of 200. As in it's exhausted 0.3% of capacity.
Noisen is a pretty 'small' website (a regular community of about a dozen users), and currently has 120 albums and 61 boards -- considering there are only a small handful of people who actually create (and use) blogs and forums over there. I didn't exactly make it 'obvious' that you can create blogs with a big bold button for that, and it's in French only.
So I can estimate that an English-speaking community of decent size could easily surpass the 64K limit in a few months time. You just need a few people to keep creating and then deleting their own albums or blogs because 'they don't know how to manipulate this stuff' :P
The most insane SMF board I have seen in the wild had 700 boards, the most insane I've ever made had 2000 boards. And believe me when I say that performance is screwed so very badly once you get into those realms.
Still, if you have lots of boards and albums, the first thing you want to do is buy more computing power... More RAM, more disk space, etc. You can't have everything for free. If your site is slow, then maybe your hosting isn't suitable for you. See what I mean...?
So, I'm keeping a low figure and suggesting to switch both 'id_board' and 'id_group' from smallint(5) unsigned to mediumint(8) unsigned. (Well, signed for id_group.)
Or is it still too much...?
We can obviously prevent people from creating more than, say, 100K boards, it's just that I don't want to be physically limited at 32K or 64K to begin with...
It's all about what is practical, and where it is likely to grow. I accept that boards are in the future more likely to grow than before, due to the intentions of using boards for albums and so on. But even at this point in time I cannot realistically expect sites to go over that. Yes, there are going to be sites that do, but I don't want to penalise everyone for the sake of the minority.
(But members > 64K is a minority, too...)
The PHP side of the performance aspect is near enough irrelevant. I'm talking about the SQL execution of that query. IN() clauses are inefficient.Quote I'm not sure a subselect would be any slower than a very long query, which Wedge always has to parse anyway...
Topic privacy is actually fine because of the limited number of them, because you're not throwing potentially thousands of values into an IN() clause.
This is the only way that we can realistically allow for multiple privacy settings on a single element, e.g. "allow my friends and my co-workers on my blog, but not my family." Well, other than having a comma-separated field of groups, of course... (?!)
It does have other consequences, too, not just rewriting all the queries which use query_see_board and all its friends, but on top of that you also have to consider the ball-ache it's going to create for modders on top. Yay.
For the small numbers of values previously involved, it's pretty much a push. But when you're getting into the theoretically thousands of rows that you're expecting to deal with, it's much, much clearer.
And faster?