Sorry for posting on the run, just a heads-up for the moment: we had a quite eventful upgrade of the site a few hours ago - and we're still fixing one thing or another. The time taken with the site upgrade this time didn't go unpunished! Some of the most unusual breaks were due to either very silly bugs (argh, testing and reviews), or to caches.
Please report everything you still find (on github or here - I hope!), we'll be back on them silly bugs to squash them.
On another note, I've removed a few themes from the site. Apart from the default, I've left Minimalistic only at this time. Sorry if it's inconvenient, but they didn't seem very used anyway (older themes or basic color variations).
Luckily Elk is back :) Was probably a painful upgrade, couldn't help that much due to RL (10 years married today :D ).. We should definitely spend more time on testing & reviewing..
Nah, not painful, but it surely had surprises. For example email-related features, like sending notifications, weren't tested locally (may not be too easy to test manually either) and we cleaned up their code once errors appeared on the site.
One other example for us to note and address: post modify was broken because during reworking of the codebase, the wrong low-level function was used. This is an interesting aspect because the available functions themselves were confusing: there were three functions, we had messageInfo(), getMessageInfo() and getExistingMessage(), all retrieving post information, more or less! Now that was a bit of a surprise, and yet again not really surprising: because sometimes, we had indeed refactored the code in localized places, and put in that place a working .subs function for that need. Then, next time the same. And sometimes, when we wanted to expand its use, we have taken the first function which behaves close enough (again, normal). This approach is very good to change step by step, whenever it's actually needed and with what is the real need. (as opposed to something over-designed, which you ain't gonna need).
But then, this approach has to be combined with the next: we have to be flexible enough to quickly see and address consistency with what existed already. To further refactor them as necessary to serve system-wide needs. We can take a step back, look at what we have, and use the knowledge gained in the process to tweak them and make them reusable in an understandable way. The current way wasn't understandable. (hah!)
I think messages, topics, and boards, the core 'entities' of the system, are more likely than any, to have a larger set of functions around them. I added some fixes for those three at the moment, but this remains an open issue: all the data needed about posts is different and there are a lot of info needed. We can consolidate them better methinks. If we don't see yet how, perhaps after more uses we can revisit them.
Oh, and there's no 'new' icon to show when a thread has new posts...
I suspect I made an over-zealous commit at a point, that broke something about this stupidly. But, the current code on the site works for me... Where isn't there a 'new' icon? On message index it shows for me... In board index it's shown too. Will re-test and look again into it.
It's now showing but before I mentioned it, no thread had a 'new' icon in the message index at all, even if they had unread items.
No, you're right, that's what it did. It updated log_mark_read on simple view of message index. I intended to come back on read/unread, and I forgot, missing this, and it got in the dev version on site. (same for display, probably, in specific cases)
If this bit doesn't make me a serious contender for Ema's title, I don't know what does...
It's not fixed in the repo yet, I'll be on it asap though.
Hmm, looks like you have a bit of css missing after that sync. I know this effect. I'll find it. It's fine on my local, so it should be easy to find. :)
ETA: ooooo, now sumpin else funny. :D
I didn't realise you'd be trying to run the merged stuff with the old SMF theme live. That's going to cause problems.
the blue theme seems broken at all, but the new default (variant=white) is broken, too... All menu buttons are white (and therefore hidden), except the active one ;)
That's coz half the css is missing here. I can tell it is. :D It's totally stable on my local, running the same code I handed over the other day. So, something has gone wrong between then and now.
ETA: It looks like you're trying to run half the new code, and half the old 2.1 alpha theme.
ETA2: Looks like there might be markup problems too.
Fixed a few missing stuffs! It
should work now... Except it doesn't. This is the current git version. (today's)
_white works for you now?
Weird. Their background is green, it applies index.css and not white...
Yayyyyyyyyyyyyyyyyy! It's looking mostly right now. ;D
Will hunt around a bit and see if I can spot anything.
As far as I can tell, it looks right for how far I've got (which wasn't all that far in the scheme of things).
I'll sync my local up with this build before I go further.
ETA: Oh and there's nothing in _white.css yet. It's still a placeholder (as per discussion yesterday).
This green/grey combo is just lovely! I re-enabled variant selection, and white is default. But they seem completely messed up among each other. Testing the others.
Yeah I thought it was a nice combo. :) I find it very pleasant to work with.
Oh I see what you mean about the other variants. Yes I expect they would be a mess. There have been markup changes as well as CSS changes, and they wouldn't know how to deal with it. TBH I can think of so much to do that I just totally ignored the other variants and went for it.
It's probably best to disable variant selection until we're almost out of alpha, quite frankly, unless someone is into updating them all the time.
No, definitely not. We need variants, at least the simple version and the fancy version. (you say you also want a dark version apart from them).
The default theme cannot be harder to customize that smf 2.0. And the git version is again with fancy effects in index.css. The theme must be easy to work with. Fancy is all nice and dandy for customizations*, which won't happen if we keep making the default index.css far out of reach.
I understand that the latest plan is to have an index.css with common/layout/simple/whatever stuffs, _green (I assume) for the Elkish look and feel (this look and feel), and _white for the rest of a variant simple to customize. With some boundary separation between index.css and _white. OK:
Commit color or fancy green changes in _green (and where suitable in _white), and you're done. *Not in index.css, if they're not part of the base.
Yes, it wont be harder to customise. We had this discussion yesterday though. This code was written several days ago.
Variants are fine. I'm all for them. But, while I'm pulling so much apart and rebuilding it so it will be easier to customise, and so it'll look good by default, it's a lot more hassle to split it up. That's why I just did it the way I did. My plan was to get the light variant sorted, then split it into index.css (pure framework only) and variant.css (everything else). Then copy the variant css and turn that copy into a dark variant stylesheet (which will be really easy, once everything else is sorted). Then use a second copy of the light variant styelsheet to make the stripped down "Elk boilerplate" variant. That is by far the easiest way to get from A to B, IMO.
If you want me to turn index.css into pure framework, I'll do that, but that means I have to take over one of the variant files for the default. It will also slow down progress, IMO.
ETA: The point is, I haven't even got things ordered correctly in index.css (they're still all over the place, like in 2.0.x code that we inherited), and there's no finalisation on what will be in it to get ordered anyway. This is an alpha.
Ok, look at it this way: I don't think it makes sense to slow down default theme progress in an alpha for the sake of what are, effectively, custom themes. Custom themes are rarely made before beta at the earliest. Usually, nobody expects to do custom theming for an alpha, or if they are crazy enough to do it they know full well that they will be chasing a moving target and it will be a real PITA.
Uninterestingly, I found that the new site works much better in mobile mode, but I just saw the desktop version, and went 'meh'.
Doing a default theme sure is hard... I've got two extra variants for Wedge that I haven't committed for fear of public backlash, ah ah... But one of them, is the most stripped down version I could ever do, and I'm adamant I'll get it to be the root skin, one day.
Note: by 'root skin', I don't mean 'default skin'. Wedge is built in a way that the default skin can very well be a sub-skin, of course. My plan is to keep the current skin as the default one, as most people are well used to it, and I like it, too.
Anyway, just saying: don't fear removing stuff. It's the current trend, anyway... Also, Bloc is a master at this.
Oh? The site suddenly changed to me, either a new FTP update, or my cache was outdated, but anyway, it looks much better now, so way to go...
:D That's the latest default theme straight from my local. Glad you like it. The old one was sort of still the SMF 2.1 alpha theme, which I was never completely happy with.