Wedge

Public area => The Pub => Features => Topic started by: Nao on July 27th, 2011, 12:20 PM

Title: New revs - Public comments
Post by: Nao on July 27th, 2011, 12:20 PM
Feel free to discuss anything interesting you see about the changelog updates!
Title: Re: New revs - Public comments
Post by: Arantor on July 28th, 2011, 09:17 AM
Quote
* encodeURIComponent() has been supported as far back as IE 5.5, so there's no reason to use SMF's way of emulating it
Do they behave differently? Specifically, the php_* functions in JS are not necessarily exact analogues of existing or later-defined JS structures, they are implemented specifically to replicate how PHP does things especially where character sets are concerned (since .toLowerCase() can behave rather differently to strtolower(), as a typical example)
Quote
* php_strtr uses charAt when it could use [] instead. It's a bit faster, which is good in long loops. (script.js)
Interesting, didn't realise JS supported that structure, will remember that for later.
Quote
I'm letting them be for now because they're testing for %u in the URL, which only happens in escape()'d strings
Is that all they're actually doing? That's one of the slightly maddening things about the codebase - stuff like that has been in there for years and it is a little tricky at times prising out the specific reason for it.
Title: Re: New revs - Public comments
Post by: Nao on July 28th, 2011, 06:39 PM
Quote from Arantor on July 28th, 2011, 09:17 AM
Quote
* encodeURIComponent() has been supported as far back as IE 5.5, so there's no reason to use SMF's way of emulating it
Do they behave differently? Specifically, the php_* functions in JS are not necessarily exact analogues of existing or later-defined JS structures, they are implemented specifically to replicate how PHP does things especially where character sets are concerned (since .toLowerCase() can behave rather differently to strtolower(), as a typical example)
Come to think of it, I never bothered to look up the differences between toLowerCase and php_strtolower. I suppose the latter is UTF-aware or something.
Do you remember any reason for using php_strtolower?

As for php_urlencode, yes, encodeURIComponent gives results similar to PHP's urlencode(). I tried a silly combination of random chars and both gave me the same results, so I assume I could use it freely. (Which is why I committed my change without further research. If it's buggy, we'll fix. But I don't know how it will.)
From what you probably saw in my commit, SMF's implementation of the whole thing was kinda bastardized. They used different methods for encoding strings, and added useless crap here and there.
Quote
* php_strtr uses charAt when it could use [] instead. It's a bit faster, which is good in long loops. (script.js)
Interesting, didn't realise JS supported that structure, will remember that for later.[/quote]Yeah, again as pointed out in the changelog-- it's only implemented in IE8+ and all other browsers. IE6/IE7 are a small share, but big enough to give up on that one. It's not like it's a big performance hog, since it's only used when encrypting passwords (sha1.js).
Quote
Quote
I'm letting them be for now because they're testing for %u in the URL, which only happens in escape()'d strings
Is that all they're actually doing?
Absolutely...
Quote
That's one of the slightly maddening things about the codebase - stuff like that has been in there for years and it is a little tricky at times prising out the specific reason for it.
Yeah, that's the problem when many developers work on the same project over the years. Each developer has their own quirks.
Title: Re: New revs - Public comments
Post by: Arantor on July 29th, 2011, 01:27 AM
The reason for using strtolower done like that is for accuracy. JavaScript's one is way more aware of things like UTF-8 than PHP's has been for a long time, and I suspect with PHP 5.4 this will have to be revisited anyway.

But ultimately the two have to be done exactly the same for password hashing to actually work, so JS has to then proceed to use the exact same case adjuster even if the browser could do a "better" job of it.

I suspect the different methods were used because browsers of the day couldn't be relied upon to be consistent. Heck, there's whole bushels of pre IE6 code even in 2.0 (like the popup crap for quoting posts)
Posted: July 28th, 2011, 07:10 PM
Quote
! If a timezone has no slash in it (such as 'UTC'), the timezone retrieval code will generate a warning. (ManageSettings.php)
I had actually fixed that locally, though I've not committed what I have because I'm not happy with it yet, concerning how users select timezones. Still not sure about that, maybe I should just commit what I have (which is to use a timezone column in the user's table and fallback to the offset for the time being)
Title: Re: New revs - Public comments
Post by: live627 on July 30th, 2011, 02:44 AM
Quote
I meant '30 lines instead of 40'. Changelog error, sorry.
You can go back and change it. The pre-revprop-change hook is present[1].
 1. Not all repos have that, though.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 10:05 AM
Quote from Arantor on July 29th, 2011, 01:27 AM
The reason for using strtolower done like that is for accuracy. JavaScript's one is way more aware of things like UTF-8 than PHP's has been for a long time, and I suspect with PHP 5.4 this will have to be revisited anyway.

But ultimately the two have to be done exactly the same for password hashing to actually work, so JS has to then proceed to use the exact same case adjuster even if the browser could do a "better" job of it.
Yes, I suppose so.
Which is why it's only used in sha1.js... :)
Quote
I had actually fixed that locally, though I've not committed what I have because I'm not happy with it yet, concerning how users select timezones. Still not sure about that, maybe I should just commit what I have (which is to use a timezone column in the user's table and fallback to the offset for the time being)
Is my fix okay for you? Feel free to rewrite it... I only fixed the error, really.

Another question.
Your number convert function -- isn't he comma_format stuff going to kill performance if used on a larger scale...?
Do you plan to convert more strings into using that? Or should I do it? :P
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 10:12 AM
Quote
Is my fix okay for you? Feel free to rewrite it... I only fixed the error, really.
I haven't looked (been way too busy with stuff) but I suspect it's similar to the one I have on my local copy, which also has the ability to load the timezone from the members table as well.
Quote
Your number convert function -- isn't he comma_format stuff going to kill performance if used on a larger scale...?
Not really, no, because it's not actually used all that often in the scheme of things.

The biggest culprit is the board index but that ran comma_format anyway, so it's one function wrapper and an if+isset overhead on top per value per board on the board/message index (1 per redirect board, 2 per normal board), it'll be another 2 call+if+isset on the message index for the counts of views/replies, plus another for the view count inside a topic. The actual add-on load is really not worth being too concerned about, IMO.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 10:22 AM
Quote from Arantor on August 1st, 2011, 10:12 AM
Quote
Is my fix okay for you? Feel free to rewrite it... I only fixed the error, really.
I haven't looked (been way too busy with stuff) but I suspect it's similar to the one I have on my local copy, which also has the ability to load the timezone from the members table as well.
Again, I didn't touch the timezone code. I only fixed the loop that retrieves them, to ensure it won't generate a warning on the list (,) code (since UTC doesn't have a comma and thus throws out an error when splitting it.)
Quote
Quote
Your number convert function -- isn't he comma_format stuff going to kill performance if used on a larger scale...?
Not really, no, because it's not actually used all that often in the scheme of things.
I suppose we could have used it more, though ;)
Posted: August 1st, 2011, 10:21 AM

So, who's going to convert the rest of the plural thingies?
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 11:06 AM
Quote
Again, I didn't touch the timezone code. I only fixed the loop that retrieves them, to ensure it won't generate a warning on the list (,) code (since UTC doesn't have a comma and thus throws out an error when splitting it.)
Yeah, that's what I meant; I've fixed the loop myself separately, but I'll fix it when I commit what I do have.
Quote
I suppose we could have used it more, though
Yes, it can be used more, because it's not heavy in itself, it's only heavy if comma_format wasn't being used already, but the places that occurs are not common.
Quote
So, who's going to convert the rest of the plural thingies?
That one's on my todo list.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 02:28 PM
Quote from Arantor on August 1st, 2011, 11:06 AM
Yeah, that's what I meant; I've fixed the loop myself separately, but I'll fix it when I commit what I do have.
Okay. Don't forget to merge before, to avoid conflicts.
Quote
Yes, it can be used more, because it's not heavy in itself, it's only heavy if comma_format wasn't being used already, but the places that occurs are not common.
It's really not heavy in the end. I did some benchmarking and it's barely twice slower than calling strpos(), for instance. Well, after all it's just some hardware string manipulation if I may say. And usually on short strings... Still, I optimized it a bit more in rev 900.
Quote
Quote
So, who's going to convert the rest of the plural thingies?
That one's on my todo list.
I've dealt with the existing _n plurals in rev 900, too. And added one that was in the index language file. Should be a good start ;)

Note to self: merge aeva_utf2entities() into westr::cut().
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 02:32 PM
Quote
I've dealt with the existing _n plurals in rev 900, too. And added one that was in the index language file. Should be a good start
Looks good to me :) The other stuff that does need doing really is the rest of the message index and the display - these are the user visible stuff, the rest of the things that need doing aren't really user visible but admin stuff primarily.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 04:17 PM
Yeah, that's what I'm thinking too. The admin area doesn't need as much attention as the front end, at least when it comes to these details.

Small remark on rev 901. ManageSettings.php got screwed up during your merge operation. You cancelled my changes in the timezone retrieval loop, but didn't cancel the line just before it that did an array_flip(). As a result, it's broken. I've restored my copy (which uses isset() instead of in_array() and should thus be faster), I'll commit it again when I have something else to commit (other than minor details in the ManageMedia template.)
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 04:28 PM
Bah, I missed the array_flip, thinking you were just doing the isset check on it at the end and that it wouldn't work as expected then...
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 04:31 PM
Quote from Arantor on August 1st, 2011, 04:28 PM
Bah, I missed the array_flip, thinking you were just doing the isset check on it at the end and that it wouldn't work as expected then...
So it was intentional? Why would you replace an isset with an in_array, generally speaking..?
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 04:34 PM
No... the original code had an in_array to select only the regions of interest, and IIRC there was an isset for something else at the end before actually adding it to the loop but off hand I can't remember what.

Right now am dealing with the fact that the imperative scheduled system is completely broken (and in fact I'm dubious about how it ever worked when I tested it originally because it shouldn't have done), will commit that when I've fixed it and finished the feature that actually uses it.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 04:54 PM
Quote from Arantor on August 1st, 2011, 04:34 PM
No... the original code had an in_array to select only the regions of interest, and IIRC there was an isset for something else at the end before actually adding it to the loop but off hand I can't remember what.
Nope, at least nothing you committed. Rev 897 is where I made the change, and it's just basically the addition of array_flip and isset, and the removal of in_array and continue. (continue is okay but if there's only going to be one line after it, might as well skip it... :^^;:)
Quote
Right now am dealing with the fact that the imperative scheduled system is completely broken (and in fact I'm dubious about how it ever worked when I tested it originally because it shouldn't have done),
I never tested it, myself. (I mostly test my own additions, as for the rest I'm hoping our beta testers do some work, I have my hands full :P)
Quote
will commit that when I've fixed it and finished the feature that actually uses it.
'kay!
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 05:03 PM
I never tested it that thoroughly either seeing as I had nothing to plug into it but I'm adding the guts of my redirection topics mod so that you can set moved notices to disappear automatically after a few days.

I haven't yet decided about making moved notices auto redirect, since that could get nasty if not done properly. (There is no actual reliable way to know if a topic is a moved notice. Yes it has an icon and a given subject but the icon is not checked during the post routine...)
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 05:36 PM
We could store an id_previous_board for each topic.
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 05:39 PM
We're already storing one of those for deleted posts. I guess we could make the inference that if it's got a previous board id and isn't in the recycle bin, it's a moved topic.

That makes sense until you realise you can move topics in and out of the recycle bin freely if you have the relevant permissions.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 08:13 PM
Arent we gonna remove the recycle bin at one point anyway?
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 10:04 PM
Yes, when we figure out how we're going to handle deleted-but-not-really-deleted posts.
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 10:16 PM
Quote
* I thought it would be amusing if the redirection topic strings actually used number_context()... (index.language.php, MoveTopic.template.php)
I was in two minds about that. I basically stole the code from my own mod there for that part, didn't see too much point reinventing the wheel.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 10:34 PM
Quote from Arantor on August 1st, 2011, 10:16 PM
I was in two minds about that. I basically stole the code from my own mod there for that part, didn't see too much point reinventing the wheel.
The only point is to have only two strings for the day list, as opposed to a dozen :)

Re: recycle bin, I thought we'd agreed (although it was long ago...) that we ccould simply do it like here: a Hide (Unapprove) button that would set posts to status!=1 or something... Then if you hide a post, you get the ability to either restore it (Publish), or restore it and set its posting date to the current time (Publish to date). Which is practical on a blog when you want to publish in intervals. (Only works if nothing was posted after the message.)
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 10:38 PM
Quote
The only point is to have only two strings for the day list, as opposed to a dozen
*facepalm* Yes, good plan.
Quote
Re: recycle bin, I thought we'd agreed (although it was long ago...) that we ccould simply do it like here: a Hide (Unapprove) button that would set posts to status!=1 or something...
That wasn't the plan from what I remember; we didn't really get into any conclusion as to what we wanted to do,   just getting rid of the existing bin setup for something cleaner.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 11:11 PM
Quote from Arantor on August 1st, 2011, 10:38 PM
Quote
The only point is to have only two strings for the day list, as opposed to a dozen
*facepalm* Yes, good plan.
Lol, don't worry, I stopped counting long ago the number of times I had some obvious action to take and I did it the complicated way. I guess we all sometimes need some perspective from the thing we're right into. ;)
Quote
That wasn't the plan from what I remember;
Oh, hamburgers!
Quote
we didn't really get into any conclusion as to what we wanted to do,   just getting rid of the existing bin setup for something cleaner.
Yeah, I remember that what bothered me the most was the inability to get a id != 2 for the recycle bin. Since it was enabled by default at install time, it's always a hardcoded number. That's my first reason for using the moderation system for post deletion. Other reasons: (1) UI is more natural to user if they can restore from the original topic, (2) no more bullshit with multiple deleted posts in a single topic resulting in multiple topics in the recycle bin, etc... It's all handled logically if we use post statuses to delete them.
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 11:13 PM
Quote
It's all handled logically if we use post statuses to delete them.
On a technical level we can solve it like that, but we need to handle the UI a little differently; to me, the concept of using unapproval to actually 'delete' doesn't seem to sit quite right with me.
Title: Re: New revs - Public comments
Post by: Nao on August 1st, 2011, 11:42 PM
We obviously rename that 'delete'.
Title: Re: New revs - Public comments
Post by: Arantor on August 1st, 2011, 11:49 PM
I think we should keep unapproved separate from deleted, not only for semantic reasons, but also because access to recycling is a different permission to access to (own/any) moderated posts.

Not only would you filter them differently, you'd probably have different UI for the different types of posts; if you delete something, you're indicating that you want it out of the way, as opposed to something not yet made live.

I'd also note that I don't particularly like the idea of unapproved posts/topics being used for future-dated/blog type posts, I'd rather keep them out of the loop (keeps the main table leaner which always helps in performance terms)
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 12:00 AM
Pseudo-deleted doesn't have to have the same internal status id as not-yet-approved.

I don't really see how it could hurt performance as long as we have a serious index on the status field...?
Title: Re: New revs - Public comments
Post by: Arantor on August 2nd, 2011, 12:08 AM
Quote
I don't really see how it could hurt performance as long as we have a serious index on the status field...?
This is where it gets complicated. As I discovered when testing with large datasets, I discovered that having everything in a single master table actually does hurt performance because you just can't make use of the indexes the ideal way - by segmenting by board, you get to instantly drop a decent percentage out of the index.

500m topics in a single board when that's all I had, really hurt compared to 1.5m topics split by three boards.

The more that can be kept out of the main table, or at least efficiently indexed the better. If we have two columns filtering the status, the index probably won't be that efficient - it would probably be better if we were to index on a single column with all four (approved/not approved/deleted/not deleted) states in a single column, it would probably index better, but benchmarking will tell us for sure.
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 01:13 AM
That's why I said the status field didn't have to just have two values -- unapproved and approved.
0: unapproved, unmoderated
1: approved
2: deleted (recycled)
3: postponed for later?
Posted: August 2nd, 2011, 12:33 AM

Hmm, I've noticed a strange behavior on the demo site that isn't on my local site.
When doing floating point manipulations in the wecss class, any floating point number is stored internally as "1,23" instead of "1.23". It always retains that comma.

I have to go, but maybe someone can tell me what's happening? I suspect it's somewhere in the setlocale stuff, but I don't know how to fix for now. The problem is that I'm relying on the periods as they're compatible with the CSS syntax, unlike the commas.
Title: Re: New revs - Public comments
Post by: Arantor on August 2nd, 2011, 01:21 AM
It's almost certainly the setLocale call that's been made which uses LC_ALL from what I remember, which means numbers will be formatted to the locale specified if possible.

Not sure how to fix that other than temporarily resetting the locale to the English default when entering the parser and resetting it back to the normal language on exit.
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 07:04 AM
Oh.

But this means there will be bugs in plenty other areas to come.
Are you sure that's necessary?
Title: Re: New revs - Public comments
Post by: Drunken Clam on August 2nd, 2011, 07:10 AM
I love this thread - even if most of it sounds like 'Swahili' to me!

Great minds at work, thinking aloud. You two rock!  :cool:
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 07:25 AM
There are dozens of topics like this one in private :P
I find myself a bit antisocial these days, especially on this topic. Meh. (Sorry Pete. bit ashamed.)
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 08:45 AM
Quote from Arantor on August 2nd, 2011, 01:21 AM
It's almost certainly the setLocale call that's been made which uses LC_ALL from what I remember, which means numbers will be formatted to the locale specified if possible.
Yes, that's what I thought. If I change it to LC_TIME, it starts working again.
Quote
Not sure how to fix that other than temporarily resetting the locale to the English default when entering the parser and resetting it back to the normal language on exit.
It's a possibility, but is there any reason for using LC_ALL really?

This changed was applied in rev 750. You added a centralized setlocale(LC_ALL) call (which includes LC_NUMERIC for the decimal separator), and removed the setlocale(LC_TIME) calls in Load.php and Subs-Media.php. So this basically breaks the 'normal' SMF behavior for localization.
I'm the first surprised because this didn't happen to me at all on the demo site. It only started happening on my second demo site, which I installed yesterday to test the importer. It's on the same server...!

So, I guess there are two possible solutions:

- setlocale(LC_TIME) in Load.php, instead of setlocale(LC_ALL). Or setlocale(LC_ALL & ~LC_NUMERIC) if that's even possible (I'm not sure LC_* is a bitwise thing.) I'd rather we use this one because at least it's going to be prooftested through SMF.

- $ex_locale = setlocale(LC_ALL, 0); setlocale(LC_ALL, 'en_US.utf8'); do our stuff; setlocale(LC_ALL, $ex_locale). That's what you suggest but I'm not sure it'll work flawlessly. It may break on some server types, etc... And it doesn't ensure it'll work in non-Subs-Cache pages.
Title: Re: New revs - Public comments
Post by: Arantor on August 2nd, 2011, 09:13 AM
Quote
It's a possibility, but is there any reason for using LC_ALL really?
Yes: some versions of the locales database don't set everything properly when using just LC_TIME, going off the comments in the setLocale manual page. http://www.php.net/manual/en/function.setlocale.php#77795 mentions it for example.

Windows aside, which is buggy anyway and I wouldn't expect serious users to be running PHP on Windows as a consequence, setLocale is threaded, meaning that there are no outbound consequences for doing the switch as suggested; once it enters the CSS parser, it's going to remain there until it's done.

I'm happy to try it as suggested, especially since now I read up on it again, I don't see how we can make use of LC_COLLATE or LC_CTYPE because that has implications for users migrating from other systems (since those affect how strtolower is done and how string comparisons may be made, though equivalence checks shouldn't be affected) though some things like LC_MONETARY might be useful in places.

It's, unfortunately, a case of swings and roundabouts :/
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 10:33 AM
Quote from Arantor on August 2nd, 2011, 09:13 AM
Yes: some versions of the locales database don't set everything properly when using just LC_TIME, going off the comments in the setLocale manual page. http://www.php.net/manual/en/function.setlocale.php#77795 mentions it for example.
Hmm... Only says "some versions of Windows". Never heard of that, really.
Quote
Windows aside, which is buggy anyway and I wouldn't expect serious users to be running PHP on Windows as a consequence, setLocale is threaded, meaning that there are no outbound consequences for doing the switch as suggested; once it enters the CSS parser, it's going to remain there until it's done.

I'm happy to try it as suggested,
Which solution then?

(I'm really pro-LC_TIME here. I don't see why we should deviate from the SMF implementation, apart from the fact that we're only executing setlocale once per page call now.)
Quote
especially since now I read up on it again, I don't see how we can make use of LC_COLLATE or LC_CTYPE because that has implications for users migrating from other systems (since those affect how strtolower is done and how string comparisons may be made, though equivalence checks shouldn't be affected) though some things like LC_MONETARY might be useful in places.
I don't think it's of much importance. Well, my opinion.
Title: Re: New revs - Public comments
Post by: Arantor on August 2nd, 2011, 10:38 AM
Quote
Hmm... Only says "some versions of Windows". Never heard of that, really.
It's more the locales database than the OS version, to be precise.
Quote
(I'm really pro-LC_TIME here. I don't see why we should deviate from the SMF implementation, apart from the fact that we're only executing setlocale once per page call now.)
At the time I thought it would make it easier to internationalise through using LC_ALL since I couldn't see a good reason not to but you've found an excellent reason not to.

Considering also that the number format is not managed through the locale anyway, the only reason remaining that actually matters is the possible incompatibility - but even then... it hasn't bothered SMF that I could find, so run with LC_TIME.
Title: Re: New revs - Public comments
Post by: Nao on August 2nd, 2011, 01:12 PM
Quote from Arantor on August 2nd, 2011, 10:38 AM
At the time I thought it would make it easier to internationalise through using LC_ALL since I couldn't see a good reason not
And it made sense indeed.
Quote
to but you've found an excellent reason not to.
Really by chance.
Still, we're in a situation that reminds us that, sometimes, the amount of servers and configurations makes it hard to make software work everywhere without tweaking. Somehow it reminds me of my 'terrific' days of debugging Direct3D code to make it work on both ATI and NVIDIA cards... Ahhhh.
Quote
Considering also that the number format is not managed through the locale anyway, the only reason remaining that actually matters is the possible incompatibility - but even then... it hasn't bothered SMF that I could find, so run with LC_TIME.
I understand that LC_CTYPE could be a problem with case manipulation. We'll have to keep that in mind... And yes, it never seemed to matter in the SMF world.
Posted: August 2nd, 2011, 01:06 PM

Okay, with rev 904 I added the template hooks. They probably won't work out of the box though, but I figured if I didn't add them, we'd forget about them eventually. We can always remove them later. The point here is: how do we make it as easy as possible for modders and themers to add these template hooks? Should we have 'proper' functions in a separate file, should we load a file actually...?

Here's how I'm considering the approach:
- mod adds an add_hook('some_source_hook', my_function, my_file)
- in my_file, mod adds a template_something_subtemplate_before function that executes before template_something_subtemplate
- after executing some_source_hook, Wedge proceeds to load Something.template.php and execute the subtemplate, and then call the _before hook that's precisely in the my_file file.

Does it make sense, or should it be made easier?
Title: Re: New revs - Public comments
Post by: Arantor on August 2nd, 2011, 01:22 PM
Quote
Still, we're in a situation that reminds us that, sometimes, the amount of servers and configurations makes it hard to make software work everywhere without tweaking.
Only last night I encountered a change in behaviour between my local PC and the server that my code was deployed onto; it was a schoolboy error on my part for forgetting it (call_user_func_array expects the callee to be specifying its parameters explicitly as references, rather than values, especially given that the caller was using references) - on my 5.2 setup it worked as expected, on a 5.3 box it broke quite interestingly.
Quote
I understand that LC_CTYPE could be a problem with case manipulation. We'll have to keep that in mind... And yes, it never seemed to matter in the SMF world.
The reason it doesn't matter in the SMF world is because so much of what goes on is DIY coding rather than letting PHP's own functions do the job. Number formatting, timezone offsets, time generally, etc.
Quote
Here's how I'm considering the approach:
Interesting. Having actually done something lately[1] that would be applicable under this discussion, let me step through what I did and why - then we'll see if it was the right decision for the case in point.

So, I needed something that would operate during the SD ticket load phase and then proceed to add a template in. Since I'm slightly lazy and had no desire to force yet another file to be loaded when the template was a very simple one, I just put the source and template in the same file.

I actually figure most mod authors would do the same if they could get away with it. Most mods don't bother trying to support all different themes, concerning themselves with template edits, or for bigger/independent stuff, a separate template file.

Embedding the template itself into the mod would prevent creating a separate file just for separation's sake because the point of MVC isn't about putting files randomly in different places to separate the code, it's a pattern: that you keep presentation and logic separate as far as possible, and even if you're mixing them in the same file, you're still logically separating them into separate functions; it would only be an issue semantically if you had just the template with the logic in it.

So, getting back to the point: I'd suggest we don't have it load files in template hooks. Any new template will require code to back it up anyway, which means you're going to be loading a file to engage the logic-powering hook anyway, and that new file can load a template if it wants, or it can embed the template if it wants. Then if the mod wants/needs theme specific changes for some random reason, it can be left to the mod author to make it happen if they so desire.
 1. A custom SD plugin, as it happened.
Title: Re: New revs - Public comments
Post by: Arantor on August 7th, 2011, 01:48 PM
r913 is something I had been planning to do a bit back but what always stopped me is the type conversion because I wasn't sure what the upper bounds of anything were supposed to be.

It may be version specific but int(4) should do something different to tinyint(4) - in theory, an int(4) should consume at least twice the space of a tinyint(4) and potentially quadruple it; int defines a 4 byte integer, tinyint a 1 byte integer, but even if MySQL is a bit smarter, and assumes the number as a size of digits, you still have to allocate two bytes (i.e. a smallint) because a potentially-4 digit number is invariably going to consume more than one byte. (The reason tinyint defaults to 4 is because of the leading sign, e.g. -127)

I don't believe MySQL uses that value for type hinting though, because of the above fact that it could be unreliable, meaning that I think it's always going to allocate 4 byte integers for everything even if it's only a one byte column, so it might be worth glancing through the code sometime to see if we do actually need 4 byte ints everywhere, since I'm not sure.

In other news, at some point we need to make sure that the list of tables that we end up with is in the listed of reserved tables in the DB class(es).
Title: Re: New revs - Public comments
Post by: Arantor on August 17th, 2011, 04:42 PM
Quote
@ Pete> I'm not sure it's semantically all right to use a theme menu string in a member menu... ^^;
Huh? Which one did I do that for then?
Title: Re: New revs - Public comments
Post by: Arantor on August 18th, 2011, 03:30 PM
Quote from Nao/Gilles on August 18th, 2011, 03:21 PM
Wow, we committed in the same minute! Did you get a conflict? :P
Nope, because I updated before committing and got your changes first, but mine happened to be nowhere near yours.

Incidentally, at some point recently we broke the installer somehow, it never gets onto step 2 :/
Posted: August 18th, 2011, 03:25 PM

More specifically, if there's any kind of error that would force it to fall out of DatabaseSettings(), it's just going back to the start rather than actually showing an error :/
Title: Re: New revs - Public comments
Post by: Arantor on August 18th, 2011, 03:41 PM
OK, so this is really, really weird.

Whatever happens, it's forcing a 302 redirect back round to the installer >_<
Title: Re: New revs - Public comments
Post by: Nao on August 18th, 2011, 03:44 PM
All right all right, I'll just get back to work and reply these... :P
Quote from Arantor on August 2nd, 2011, 01:22 PM
Only last night I encountered a change in behaviour between my local PC and the server that my code was deployed onto; it was a schoolboy error on my part for forgetting it (call_user_func_array expects the callee to be specifying its parameters explicitly as references, rather than values, especially given that the caller was using references) - on my 5.2 setup it worked as expected, on a 5.3 box it broke quite interestingly.
It had more bugs than that... I remember fixing a few things when I installed v5.3.
Quote
The reason it doesn't matter in the SMF world is because so much of what goes on is DIY coding rather than letting PHP's own functions do the job. Number formatting, timezone offsets, time generally, etc.
Indeed. It's a bit slower probably, though...
Quote
So, I needed something that would operate during the SD ticket load phase and then proceed to add a template in. Since I'm slightly lazy and had no desire to force yet another file to be loaded when the template was a very simple one, I just put the source and template in the same file.
Yeah, I'd tend to say that's something that's bound to happen, and it's not going to kill anyone.
If you want to encourage users to become modders, then you have to be ready to accept a few quirks like them not following the MVC model. Heck, if it works, and it's nicely written, the MVC stuff isn't a big issue... It starts to become an issue when the program is large. Like Wedge.
Quote
So, getting back to the point: I'd suggest we don't have it load files in template hooks. Any new template will require code to back it up anyway, which means you're going to be loading a file to engage the logic-powering hook anyway, and that new file can load a template if it wants, or it can embed the template if it wants. Then if the mod wants/needs theme specific changes for some random reason, it can be left to the mod author to make it happen if they so desire.
Does that mean you want to remove the template hooks, or simply not change anything and just discourage people from loading files in template hooks? I'm not sure I'm following you...
Quote from Ara Potter on August 7th, 2011, 01:48 PM
It may be version specific but int(4) should do something different to tinyint(4) - in theory, an int(4) should consume at least twice the space of a tinyint(4) and potentially quadruple it; (snip).
Err... I may have forgotten. What were you trying to say? :P
Quote
I don't believe MySQL uses that value for type hinting though, because of the above fact that it could be unreliable, meaning that I think it's always going to allocate 4 byte integers for everything even if it's only a one byte column, so it might be worth glancing through the code sometime to see if we do actually need 4 byte ints everywhere, since I'm not sure.
Oh that would be such a fuuuun job to do.... :whistle:

I'm the one who got stuck with all of the smf/sm renames, so nahh :P
Quote
In other news, at some point we need to make sure that the list of tables that we end up with is in the listed of reserved tables in the DB class(es).
Yes we do... I can already say the media tables aren't in it ;)
Class-DBPackages.php::32
Quote from Ara Potter on August 18th, 2011, 03:30 PM
Nope, because I updated before committing and got your changes first, but mine happened to be nowhere near yours.
By conflict I meant the program stopped because your version wasn't up to date. (It prints out red text and simply says to update it, but per se there's no actual conflict within the file.)
That's one of my specialties these days because you can spend a long time without committing so it's been a long time since I've updated my svn before committing to it ;)
Quote
Incidentally, at some point recently we broke the installer somehow, it never gets onto step 2 :/
Ouch... Much be AeMe. I didn't test the installer after I did all of the changes. But OTOH it should be working, I used the rest of the file as a template...
Quote
More specifically, if there's any kind of error that would force it to fall out of DatabaseSettings(), it's just going back to the start rather than actually showing an error :/
That... Isn't good.

Did you try reverting? That's usually what I do... I revert until it doesn't crash anymore.
Title: Re: New revs - Public comments
Post by: Arantor on August 18th, 2011, 03:54 PM
Quote
It had more bugs than that... I remember fixing a few things when I installed v5.3.
That was the main thing I encountered; 5.3 is less forgiving than 5.2.
Quote
Indeed. It's a bit slower probably, though...
It definitely is slower. But it remains to be seen whether it's better or not, because I know there are problems with locale libraries out there.
Quote
Yeah, I'd tend to say that's something that's bound to happen, and it's not going to kill anyone.
If you want to encourage users to become modders, then you have to be ready to accept a few quirks like them not following the MVC model
Exactly. The one thing I will say is I very specifically still kept logic and presentation apart, just I didn't bother making them separate files. The result structure is still maintained, so I don't see a problem with it, provided that I don't do the same thing on larger stuff.
Quote
Does that mean you want to remove the template hooks, or simply not change anything and just discourage people from loading files in template hooks? I'm not sure I'm following you...
Leave the hooks in - you still have to have points to call from. But I'd really rather not encourage people to be loading files there if possible.

For smaller stuff, like the aforementioned, you'll load presentation and logic and execute them. But for anything of any real substance, you'll load the logic separately and pull in a template if you need it, meaning that there's no real harm in leaving the facility for templates to load files but it's a habit that should be discouraged.
Quote
Err... I may have forgotten. What were you trying to say?
Simply that SMF's DB library got it wrong at times and that types aren't always what they seem, such that it might be worth sometime figuring out what the maximum value per column is, to save some space on big forums.
Quote
Oh that would be such a fuuuun job to do....
At least with the renames, you have a finite list to contend with, and it's (reasonably) confined to a find/replace witch hunt. DB fields on the other hand, aren't necessarily so.
Quote
Yes we do... I can already say the media tables aren't in it
I don't think all the ones I've added are there either.
Quote
By conflict I meant the program stopped because your version wasn't up to date. (It prints out red text and simply says to update it, but per se there's no actual conflict within the file.)
No, because I updated it before committing so I didn't get a conflict anyway.
Quote
Ouch... Much be AeMe. I didn't test the installer after I did all of the changes. But OTOH it should be working, I used the rest of the file as a template...
Nope, the changes are prior to any of the changes in install.sql, and even manually reverting the changes in install.php, it still fails.

There is a secondary issue that I'm aware of on my configuration (for reasons I won't get into, I'm running 5.1 with a 5.0 connector library) but it shouldn't be failing how it is, it should be failing with an appropriate error.

Come to think of it, I didn't test with the 5.1 version number but have no idea why that should have caused it to fail the way it does.
Title: Re: New revs - Public comments
Post by: Arantor on August 19th, 2011, 02:21 PM
Oh, and I figured out what the problem with the installer was.

The stock Settings.php file contains a test to see if install.php exists, and if it does, redirect there. Once the DB settings have been validated, that test is removed from Settings.php.

At least in theory, the test used to check for the if statement, plus there being braces either side of the redirection itself, but since it was a one line if branch, the braces got trimmed in r941 and failed to remove the redirect.

Now, I have to see about upgrading my install or hacking the installer test (since while we require 5.1, there's nothing about the connector that will be broken by what I'm doing, but I might as well fix it rather than leave it quasi-broken as it is now)
Title: Re: New revs - Public comments
Post by: Nao on August 19th, 2011, 06:21 PM
Oh my, sorry -- it was my fault then... I didn't think these brackets were linked to anything else. To me, they were just disgracious... :^^;:

I'll take care of that later.
Title: Re: New revs - Public comments
Post by: Arantor on August 19th, 2011, 07:17 PM
Nah, I fixed it by loosening the check in the installer so it doesn't demand the brackets.
Title: Re: New revs - Public comments
Post by: Nao on August 19th, 2011, 07:34 PM
Me too. Next who commits then!
Title: Re: New revs - Public comments
Post by: Arantor on August 19th, 2011, 07:41 PM
I already committed the fix hours ago :P

This is what prompted me to muck about with my setup because the installer worked as expected, and failed to allow me to finish installation.
Title: Re: New revs - Public comments
Post by: Nao on August 19th, 2011, 10:35 PM
Please document your commits.... :whistle:
Title: Re: New revs - Public comments
Post by: Arantor on August 19th, 2011, 10:37 PM
Bah, I forgot to post the change log again :/
Title: Re: New revs - Public comments
Post by: Nao on August 19th, 2011, 11:15 PM
I looked at your commit... Is it normal that you reverted my change to the MySQL version test...?
I only made that to avoid calling a useless eval()...
Title: Re: New revs - Public comments
Post by: Arantor on August 19th, 2011, 11:17 PM
Quote
I looked at your commit... Is it normal that you reverted my change to the MySQL version test...?
I know I did that at one point to see if it made a difference to how it was being evaluated, but no, that wasn't intentional, the only actual change should be to the function that updates Settings.php to strip the redirection.
Title: Re: New revs - Public comments
Post by: Nao on August 20th, 2011, 09:53 AM
So, I reverted your revert. ;)

Oh, I fucking hate IE... I'm looking at the post editor under IE7 and IE8. It's so incredibly broken, especially in Wysiwyg... There are glitches everywhere, it's comical. I wouldn't even know where to start.

And I fucking don't want to fix them!
Title: Re: New revs - Public comments
Post by: Arantor on August 20th, 2011, 11:31 AM
Quote
Oh, I fucking hate IE... I'm looking at the post editor under IE7 and IE8. It's so incredibly broken, especially in Wysiwyg... There are glitches everywhere, it's comical. I wouldn't even know where to start.
This is really why we need to take a long look at how we approach WYSIWYG, and HTML in general. It seems to me that replacing the current editor with something like CKEditor would be a good idea but that we then need to decide whether we're keeping bbcode or not. (It is possible to hybrid them, as xenForo does)
Title: Re: New revs - Public comments
Post by: Nao on August 20th, 2011, 12:17 PM
I don't know, but I don't think we'll have CKEditor at all in v1.0... It'll probably take too long to implement. Or we'll have to postpone 1.0 until mid-2012... And I don't think people will like that. (If we're only doing Wedge for ourselves, okay, but I think we're past that aren't we...? :^^;:)
Title: Re: New revs - Public comments
Post by: Arantor on August 20th, 2011, 12:25 PM
I was able to get a limited version working in SMF in under an hour. The biggest part is marrying up the stuff in wedit, like the bbc converter, and having Wedge control what buttons there are rather than CKEditor doing it itself.

That sort of assumes we stick with bbc and have it perform the same kind of mutant bbc/HTML mashup that the current editor does because complex bbc can't be represented in simple HTML and vice versa, like the quote and gallery bbcode items.
Title: Re: New revs - Public comments
Post by: Nao on August 20th, 2011, 10:13 PM
Well... I guess we can try.

Oh, I think I'm walking into your territory now. In the spirit of my latest commit. I'm planning to split the change theme page into its own menu entry. Are you okay with that?
Title: Re: New revs - Public comments
Post by: Arantor on August 20th, 2011, 10:28 PM
I think that makes sense, so go for it :)
Title: Re: New revs - Public comments
Post by: Nao on August 20th, 2011, 10:30 PM
Good. Because I could always add a shortcut to that somewhere but i prefer a menu link to begin with. :)
Title: Re: New revs - Public comments
Post by: Arantor on August 20th, 2011, 10:39 PM
I do have one idea I haven't shared yet that I think you'll like but I'll demo it when I've got it working how I'd like.
Title: Re: New revs - Public comments
Post by: Nao on August 20th, 2011, 11:32 PM
If it's about an Ajax-driven theme changer in the footer, I already have the idea but too lazy to implement it :P
Title: Re: New revs - Public comments
Post by: Arantor on August 20th, 2011, 11:35 PM
Nope, not that. I'm not using AJAX either in what I'm thinking about, though I suppose it could be added since it's in an area that does have JS available, but I don't really see it as being needed.

The real question for me is whether I make it for all relevant users or a per-user thingamabob, but that has other consequences to be fixed since it would then be related to a vulnerability we discussed recently.
Title: Re: New revs - Public comments
Post by: Nao on August 21st, 2011, 12:41 AM
I don't know what you're talking about... :^^;:

Oh, that theme picker is a real bitch when it wants... First of all, SMF bug: it sets the $current_action to 'admin' if 'sa=pick' isn't set in the URL... Even though it uses sa=pick when setting global and default themes within the admin area -- I changed that to checking for 'u=' in the URL. If it's set and u is > 0, it means we're editing a profile.

Also, if the user chooses the default theme, it also uses the default skin, right...? id_theme is set to 0, and skin is set to... Well, it's set to 'skins'. Which is totally wrong if you set the default theme to use a different skin than what it uses by default... Argh.
I'll have to check every single use of 'skin' to make sure it doesn't screw that up... >_<
Posted: August 21st, 2011, 12:39 AM

Oh, and something I haven't time to look into... If you use ;area=permissions in the admin area (e.g. the main menu's Admin > Permissions shortcut), you get an index page as expected, but neither the contextual buttons not the page description are correctly output. If I had ;sa=index manually at the end, it works. Only, $_REQUEST['sa'] at this point is always 'index', even when not set... Where does the error come from? Maybe it's checking into $_GET instead? Can you have a look, Pete?
Title: Re: New revs - Public comments
Post by: Arantor on August 21st, 2011, 12:43 AM
Quote
I don't know what you're talking about...
That's the point, it's a surprise :D Though it was something you said that made me think of it... You'll see soon enough!
Quote
Oh, that theme picker is a real bitch when it wants...
Yes, yes it is.
Quote
Where does the error come from? Maybe it's checking into $_GET instead? Can you have a look, Pete?
That applies to every single page in the admin panel. It's done for a while and I think it's a bug of ours (i.e. I can't reproduce it in SMF). I suspect the change to tab_data is responsible from a bit back, but I'll take a look shortly.
Posted: August 21st, 2011, 12:43 AM

Or I will perhaps in a bit longer since my WampServer configuration isn't working properly. Might be conflicting with my original Apache setup >_<
Title: Re: New revs - Public comments
Post by: Arantor on August 21st, 2011, 01:06 AM
OK, so WampServer is set and running.

Interesting fact of the day, I have to run Wedge with persistent connections, otherwise it takes a second to connect before going any further. Since SMF does it, it really has to be a problem somewhere in the bowels of the configuration (especially as WampServer appears to be using the originally configured MySQL server, not the one it installed with :/)

But, interestingly, I may have found a random bug where it actually got unset for some reason and I have no idea why that is.
Title: Re: New revs - Public comments
Post by: live627 on August 21st, 2011, 02:49 AM
Well it probably is on your side, maybe a conflict or something, because the mysql connection has never lagged for me on WampServer 2.1.
Title: Re: New revs - Public comments
Post by: Arantor on August 21st, 2011, 02:55 AM
Quote
Well it probably is on your side, maybe a conflict or something, because the mysql connection has never lagged for me on WampServer 2.1.
Oh, I finally found out what it was. It's the fact that it lags looking up 'localhost' in DNS, since using 127.0.0.1 works just fine.

Meanwhile I appear to have permanently broken phpMyAdmin's ability to connect. This is awesome, especially because I have no fucking idea how it happened.

For reasons too long to get into, all my local stuff is run with a root user with a password. root@localhost, root@127.0.0.1 and root@% are all defined and valid users in the mysql table. SMF and Wedge connect just happily with any of the above settings.

But phpMyAdmin won't. At all.

If I give it root@localhost, no password, it fails - understandably. But if I tell it root@localhost, with the right password, it tells me it can't connect root@127.0.0.1 (using password: YES). Which, considering they have the same password, is interesting. (Yes: it's actively converting the domain name into an IP)

And root@127.0.0.1 doesn't work either, even though it has the same password as the other root accounts (just varying the hostname)
Title: Re: New revs - Public comments
Post by: Nao on August 21st, 2011, 09:10 AM
Why don't you try and clean up the mysql/php configuration files from your system and your registry...?
Title: Re: New revs - Public comments
Post by: Nao on August 21st, 2011, 09:37 AM
I've found the thing that doesn't work correctly in the menu code.

Admin.php:645 calls createMenu().
Admin.php:704 calls the admin function from the long admin array.

$_REQUEST['sa'] is reset to the default in the list only from within the later admin function, so at this point, createMenu was already created, and $menu_context['current_subsection'] was set in that function. There is one final opportunity to fix current_subsection but it's still in Admin.php and before line 704 (and this is something you added but I doubt it has any influence here.)

I suppose one simple fix would be to check for $_REQUEST['sa'] beforehand, and if empty (and the area is known), get the first working item from the 'subsections' sub-array. And work from that... We'd just need to ensure they're in harmony with the corresponding default from each individual function. I guess. Or we could even specify the fallback subsection as a new array entry in each area...
Title: Re: New revs - Public comments
Post by: Arantor on August 22nd, 2011, 01:35 PM
Quote
And work from that... We'd just need to ensure they're in harmony with the corresponding default from each individual function.
The way it has always operated (and I think this is quite valid) is that if a given menu item has subitems, the first valid subitem is the one displayed as a default - and I don't see any reason to change that behaviour, personally. (IOW, going to SMF's own behaviour, which we seem to have broken at some point :/)

Interestingly this behaviour is also present in the profile area where you hit an item with subitems, without the default tab being highlighted...
Posted: August 22nd, 2011, 01:25 PM

OK, fixed it, it was broken in r886 with related changes to the menu code removing unnecessary stuff around figuring out the first/last items.
Posted: August 22nd, 2011, 01:33 PM

Committed in r961.
Title: Re: New revs - Public comments
Post by: Nao on August 30th, 2011, 01:05 AM
Thanks for the fixes (install time skin var & credits title), I totally missed these.

I'm not 100% sure about the removal of admin confirmation though... Not that I don't get your point -- but I can see people complaining the option is no longer there, and having to tell them to use phpMyAdmin to change it... I dunno. I suppose it's worth doing it -- and if too many people complain, we can always re-introduce the admin setting...

Even less sure about the removal of the help icon saying why the password has to be entered again. Are you... sure it's related to the above...? I wouldn't say it is. :^^;:
Title: Re: New revs - Public comments
Post by: Arantor on August 30th, 2011, 01:09 AM
Quote
Even less sure about the removal of the help icon saying why the password has to be entered again. Are you... sure it's related to the above...? I wouldn't say it is.
Bah, I was a bit too enthusiastic with the delete button. The extra string has the setting name in it, which is where I enthusiastically removed it.
Quote
I'm not 100% sure about the removal of admin confirmation though... Not that I don't get your point -- but I can see people complaining the option is no longer there, and having to tell them to use phpMyAdmin to change it...
I really don't see it as a problem: it is not the sort of setting that actively needs to be present, and I'd argue the number of people that actively need to use it is pretty small, small enough that it can be removed to prevent the idiocy of the rest.

See also where it was discussed - http://wedge.org/pub/feats/6846/more-stuff-for-the-removal-of/
Title: Re: New revs - Public comments
Post by: live627 on September 3rd, 2011, 11:58 PM
Code: [Select]
foreach (explode(',', strtolower($modSettings['disabledBBC'])) as $tag)

Wouldn't that do the explode for every disabled BB code?[1]?
 1. I think that's how Javascript does it.
Title: Re: New revs - Public comments
Post by: Arantor on September 4th, 2011, 12:22 AM
I thought that foreach evaluated it only the first time to build the array. I smell a benchmark in the wings.
Title: Re: New revs - Public comments
Post by: live627 on September 4th, 2011, 12:51 AM
I did some research on this and it turns out that, indeed, PHP explodes it once and keeps it in memory.
Title: Re: New revs - Public comments
Post by: Nao on September 4th, 2011, 01:02 AM
I wouldn't have made that change otherwise ;) SMF was using a temp var for nothing.

It must not be confused with for() where the second argument is always reevaluated.
Title: Re: New revs - Public comments
Post by: live627 on September 4th, 2011, 02:26 AM
Code: [Select]
// Parse the smileys within the parts where it can be done safely.
if ($smileys === true)
{
$message_parts = explode("\n", $message);
for ($i = 0, $n = count($message_parts); $i < $n; $i += 2)
parsesmileys($message_parts[$i]);

$message = implode('', $message_parts);
}

This is at the end of parse_bbc(). Is there a specific reason for parsing smileys on every line? Why not parse the whole message, which makes more sense?
Title: Re: New revs - Public comments
Post by: Arantor on September 4th, 2011, 03:14 AM
I assume it's to do with the code tags and similar where smileys shouldn't be parsed. Notice that it expressly doesn't do every line but every other line in the file.
Title: Re: New revs - Public comments
Post by: Nao on September 4th, 2011, 08:45 AM
I myself have learned not to meddle too much with parse_bbc() doings... Usually they're there for a reason, too bad they're not documented ;)
I tried to comment the actions I'm performing in the new version of Aeva-Embed.php -- it's probably a good thing since I had a hard time diving back into the original code, even though I spent so much time on it :P
Title: Re: New revs - Public comments
Post by: live627 on September 4th, 2011, 09:00 AM
Quote from Nao on September 4th, 2011, 08:45 AM
I tried to comment the actions I'm performing in the new version of Aeva-Embed.php -- it's probably a good thing since I had a hard time diving back into the original code, even though I spent so much time on it :P
Six-month[1] code can look like  someone else wrote it.
 1. It's just a random number, the first one I thought of.
Title: Re: New revs - Public comments
Post by: Nao on September 4th, 2011, 09:26 AM
It also reminds me that I don't need to prove the world anything... My code was already perfectly, excruciatingly godly years ago, it's not like I'm improving and I need to show it... :whistle:
Title: Re: New revs - Public comments
Post by: Arantor on September 5th, 2011, 09:12 PM
Quote
PS: Pete... I know you're not as used to committing as I am (), but could you please think of posting your changelogs...?
Um, if you're referring to r980, that was yours... My last commit was r972, which I posted... All the changes I'm making are local until I'm done with it...
Title: Re: New revs - Public comments
Post by: Nao on September 5th, 2011, 09:19 PM
Oh. Sorry then. I'm not on my pc so I can't check whatever I screwed up. Plus I have another big commit coming up... Oh what a week.
Title: Re: New revs - Public comments
Post by: Arantor on September 5th, 2011, 09:21 PM
No worries :) It's a big week for me too with the new plugin manager code...
Title: Re: New revs - Public comments
Post by: Nao on September 5th, 2011, 09:32 PM
Keep up the good work :)

I saw where I made a mistake-- I'd simply looked at the previous post with rev 976, and posted the new one as 977... When I'd actually posted a 977 immediately after 976 and merged the two posts for good measure.
Title: Re: New revs - Public comments
Post by: Arantor on September 9th, 2011, 10:18 AM
I haven't touched your latest stuff yet, still on the add-on infrastructure trail.

However, there is one thing I noted about the change to quick reply... I think I'd rather make it shown by default, rather than bigger but still hidden by default. It's a surprisingly common question on SMF, not helped by the fact that the process of changing it is relatively illogical at present, but I'm inclined to think it should be shown, on by default.
Title: Re: New revs - Public comments
Post by: Nao on September 9th, 2011, 10:54 AM
I think it's a debate that could be launched, but really, all I did was to make the field bigger if the thing is collapsed. I figured if I always made it bigger, people might complain that it takes too much room on all pages when it's open opened shown by default. You know, the kind of detail that eventually makes Wedge look better, and people say, "how come I never thought about that before?!"... Don't worry, we didn't either :lol:

Oh, it's a good day starting for me...
http://forum.machinaesupremacy.com/index.php?action=credits
Technically, I have my name in the credits of the official Machinae Supremacy website. And I didn't even know about them until a few weeks ago. 8-)
Title: Re: New revs - Public comments
Post by: Arantor on September 9th, 2011, 10:57 AM
Heh, yeah, I can see the logic. Just that people do ask quite a bit how to enable it because it is generally considered to be conducive to getting people to post.

And I'd never heard of Machinae Supremacy before...
Title: Re: New revs - Public comments
Post by: Nao on September 9th, 2011, 11:30 AM
- Debate, guys! :P

- A "SID metal" band... I'm not a big metal fan (apart from my holy trinity of SUGIZO, Anathema and Symphony X and a vague Angra album, my knowledge is close to zero), but they topped a top 10 video on Youtube about great indie video game soundtracks... I wanted to know if there was anything as good as Aquaria or Braid in that respect. Well, made me discover Machinae Supremacy's soundtrack for Jets'n'guns, and Module's soundtrack for Shatter. Both are soundchippy, and both are fantastic. The Shatter OST was like a drug to me for a month or so -- now I switched to the J&G drug :P
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 04:14 PM
Wow! You committed much earlier than I expected... :P
I'm right in the middle of finishing some extra features, but I'll keep your diff around and try to look into it ASAP.

Just a quick note I forgot to make before.
I accept that everything's named 'add-on' and not 'mod' or 'plugin', but could we consider using lowercase on top-level folders...?
I never liked the ucfirst style of all folders such as Themes, Sources etc. As you can see, the media folder is just 'media', not 'Media'... To me, it would make sense to have all accessible folders (Themes, Addons, Smileys...) in lowercase, and others (i.e. only accessed through PHP) could retain their original case.
I believe it'd be something unrealistic to apply to Themes, though... But it's still worth debating. All URLs in SMF/Wedge are lowercase, except for these top-level folders.
Posted: September 18th, 2011, 04:10 PM

Okay, just loaded the diff patch and saw a strange thing in other/Settings.php... You replaced localhost with 127.0.0.1 (is it wanted?), and $boardurl with 'smf/wedge'... Any reason for the change, and most importantly, for adding a 'smf' string where there wasn't before...?
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 04:42 PM
OK, neither of those changes were supposed to be committed. I have to use 127.0.0.1 instead of localhost to avoid a 1 second lookup on every single page to resolve the domain name in MySQL. Never understood why, just that since using WampServer, that's been the case.

As for smf/wedge, that is my boardurl, and when I was messing around trying to debug the above, I set that and forgot to revert it.

The main reason for ucfirst, as far as I can tell, is simply to indicate importance on folders that shouldn't be writable by defaults (notice that avatars and attachments are, but everything else isn't) but I have no reason to leave it as is, it's cool to change it.

This isn't finished, btw. It's a milestone that I consider practical for committing, as in the first usable version. There's plenty more to do but it is usable for activating add-ons even in its present form, and the bulk of add-ons shouldn't need much more than this anyway.
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 05:06 PM
Quote from Arantor on September 18th, 2011, 04:42 PM
OK, neither of those changes were supposed to be committed. I have to use 127.0.0.1 instead of localhost to avoid a 1 second lookup on every single page to resolve the domain name in MySQL. Never understood why, just that since using WampServer, that's been the case.
As I suspected.
Quote
As for smf/wedge, that is my boardurl, and when I was messing around trying to debug the above, I set that and forgot to revert it.
But why in other/Settings.php and not your own Settings.php file...?
Quote
The main reason for ucfirst, as far as I can tell, is simply to indicate importance on folders that shouldn't be writable by defaults (notice that avatars and attachments are, but everything else isn't) but I have no reason to leave it as is, it's cool to change it.
I'd really like to change it. Anyone else?
The only issue is really with the Themes folder. But then again we could use the opportunity to rename 'default' to something shorter or just delete it...
Quote
This isn't finished, btw. It's a milestone that I consider practical for committing, as in the first usable version. There's plenty more to do but it is usable for activating add-ons even in its present form, and the bulk of add-ons shouldn't need much more than this anyway.
Okay.

Now for something completely stunning...

HO-LY-FUCK.

Really.

This is what happened to me today.
This morning I was looking at my Wedge.org import running Wedge, and was thinking that I really should get started on converting the homepage. But since I don't want to do any changes to the main codebase (so that I can easily update it later), I decided to go ahead and implement custom homepages. Are you following me.....? :whistle:

I was working on changelogging my new commit when you did yours. I mentioned I couldn't look into it because I was finishing up my feature.
Then I committed.
And it failed.
Oh, I have a conflict in index.php?!

Launching index.php...
OMG.
First line of the conflict, yours:

"      // Some add-ons may want to specify default "front page" behavior. If they do, they will return the name of the function they want to call."

Re-OMG.

This is the first time it happens to us. It happened that we had conflicts because we worked on the same 'generic' file at the same time. But it's the first time we both decide to implement the exact same feature on the exact same day and end up getting a conflict.
Heck, I hadn't thought of the homepage stuff for months...!!

Now to analyze this conflict and try to find if we can find a common ground...
Posted: September 18th, 2011, 04:52 PM

Okay, I'm looking into it...

- I like your version because add-ons can specify where to go by themselves. However, what if two add-ons want to redirect the index..? I'd rather have them add layers/blocks to the index, instead. Also, I have to admit I'm not used to your add-on system yet -- meaning that other SMF admins may not want to look into it, i.e. why should they develop an add-on just to add a homepage to their forum...? I was considering instead posting somewhere a documentation about adding a Homepage.template.php file and doing everything there.

- I like my version (:P) because it allows the admin to specify a board as the default entry point. I renamed all boardindex entries to 'action=boards' to make it sound less like an 'homepage' and more like just what it is -- the board list. Your version doesn't allow a board as an entry point because it's called after the loadBoard function.

- Your version allows to specify a function name in addition to a file name. I simply have a single string for now, allowing to choose your action, ultimately I wanted to simply load the related file and run the function with the same name, as is the case in almost every single action in Wedge.

- I don't understand the difference between default_action and fallback_action. My version actually calls a short extra function, index_action(), which first looks for the value of $modSettings['default_index'], and if the file doesn't exist, it redirects to 'Boards' (i.e. 'BoardIndex').

I'd be tempted to say I like my implementation better, if only because it can ultimately be modified easily by the admin from the admin area, choosing a default board or a file from the available list. However yours seems more streamlined than mine. I'd like to know your opinion on this. Do you want me to send you my file?
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 05:26 PM
It is pretty funny, actually, though we had briefly mentioned the idea before.

OK, so what's the difference between the two hooks? It's really for portals more than anything. One path is what to do if no action is specified (check for board and topic, and indeed anything else that might be specified by URL without expressly being action=something, like SP does with pages)

The second path is for actions that are requested but don't exist, so that you always get back to *something*. WedgeDesk expressly uses both hooks, though it runs the same function either way, because of its standalone mode that removes actions.

My version wasn't really designed with the goal of allowing a board to be loaded by default, it was designed so that any add-on that could override the default action can actually do so.

Pushing the board index to its own action is a good idea (though that does mean other things do have to be fixed, I have a list somewhere of URLs that expect index.php to be the board index) and I think it would be nice for admins to be able to set a default action, so ultimately from mu POV, having both would be great, provided that add-ons can if necessary override that behaviour, which is what the hooks allow for.

You mention doing it through blocks but for the specific uses I have (and I can find other more general cases), this isn't enough. WD's case is unusual but follows the pattern of all the portals where it replaces the board index entirely under some circumstances, in particular standalone mode which means to disable the forum entirely and just use WD code - having the board index is not merely inaccurate and superfluous, it's completely undesirable.

I also doubt that most admins will develop add-ons, but that one will exist that they'll use to perform that task, and I'll likely write it...

As far as conflicts go in terms of which add-on gets priority, I'm not expecting that to be a huge problem in most cases, simply because most of the time it actually won't matter. But a priority value might make sense to implement to deal with that, though that also has implications, e.g. authors blilndy setting max priority all the time. That part is still a WIP really.
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 05:39 PM
Thing is. Addons can already override the default action (provided we send $action to them or globalize it), through 'behavior' for instance. They just add their action to the action list and rewrite the action or even manually modify the query string. I'm not sure adding more options would help anyone here.

As for urls the only ones I can think of have #category in them and yes I was planning to fix them in the following commit ;)
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 05:58 PM
Let's say we want to offer page= as an option in the URL, like topic and board. Ae you saying that during the behaviour hook, they should just proceed to make the test and force it to their action if found? Seems a bit ugly to me, though it's the most workable compromise.

The fallback action really should be left though, otherwise if an invalid action is specified, you are doomed to go to the board index. Assuming your default will be applied in both places, I guess that's OK, but it does mean that an add-on actually has to do some work if it actually wants to be the front page, because it has no other way of overriding the admin's choice other than fudging the modSettings value softly, as opposed to setting up a hook. (And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 06:23 PM
Quote from Arantor on September 18th, 2011, 05:58 PM
Let's say we want to offer page= as an option in the URL, like topic and board. Ae you saying that during the behaviour hook, they should just proceed to make the test and force it to their action if found? Seems a bit ugly to me, though it's the most workable compromise.
I don't know, we can still work it out later. Right now I'd just like to commit my stuff because my copy is broken otherwise ;)

BTW I managed to mix both of our implementations together. Your hook is called first, so it gets priority, and then my own code is implemented. However, my default board code is run before any of the two hooks, so it gets the top priority, but on top of that, the behavior hook now gets to manipulate $action so it can override the default board. Hopefully I managed to find the best logical balance here.
Quote
The fallback action really should be left though, otherwise if an invalid action is specified, you are doomed to go to the board index.
Yup. Don't worry, I kept it in.
Quote
Assuming your default will be applied in both places, I guess that's OK, but it does mean that an add-on actually has to do some work if it actually wants to be the front page, because it has no other way of overriding the admin's choice other than fudging the modSettings value softly, as opposed to setting up a hook.
Well, that was how I was envisioning the idea. Add-ons are great and everything, but we shouldn't consider they're not able to modify any setting in Wedge, because they can, plain and simple ;)

BTW, in reloadSettings() there's some long code related to the hook system... I haven't looked into the rest, but is it needed? Didn't Wedge already load the hook list somewhere else..? Or is it related to some design issue we hadn't seen before?
Quote
(And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)
I don't see how, though. At least as a humble mod author. (Oops, I said "mod"! ::))
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 06:28 PM
Quote
but is it needed? Didn't Wedge already load the hook list somewhere else..?
Yes, it is needed. In the case of a rogue add-on, this forces an add-on to be shown to exist on startup. Prevents people just randomly deleting add-on folders and then everything breaking because files couldn't be loaded.

And if an add-on is bad, you can just delete or rename its folder and it'll deactivate it safely.
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 06:41 PM
Re 1006, yes, I think it would be nice to limit category viewing to a single category if desired, e.g. index.php?cat=1 to show just that category, with action=boards showing all of them.
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 07:55 PM
Okay for add-ons... I'd just like to make sure we're not wasting time (CPU cycles) on something that'll never happen.

Well, categories are what I was working on right now...
The URL I chose for now is action=boards;cat=1
I could use action=boards;c=1, though, because some items in Boards.php use 'c' instead.
Anyway that can be renamed easily later...

I'm not sure about index.php?cat=1, though. That would imply, again, extra CPU cycles in the index file.
Title: Re: New revs - Public comments
Post by: Aaron on September 18th, 2011, 09:41 PM
Quote from Arantor on September 18th, 2011, 04:42 PM
OK, neither of those changes were supposed to be committed. I have to use 127.0.0.1 instead of localhost to avoid a 1 second lookup on every single page to resolve the domain name in MySQL. Never understood why, just that since using WampServer, that's been the case.
Disable hostname lookups (or reverse DNS, I forget what the exact setting is called) in MySQL itself. That should solve it.
Title: Re: New revs - Public comments
Post by: Arantor on September 18th, 2011, 09:42 PM
No, it's likely it will be used in the manner I describe. I did, before, get into the realm of physically registering hooks but I found cases where it could go badly wrong if something was set to disable and it actually didn't.

I take your point about categories, I just think it would be more consistent as cat= rather than an action, but that it would have an impact on index, even though it can be downplayed to check if action is unspecified and only after board and topic have been tested for.


@Aaron, I tried to do that but was not having a lot of luck with it.
Title: Re: New revs - Public comments
Post by: Nao on September 18th, 2011, 10:36 PM
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.
Title: Re: New revs - Public comments
Post by: Arantor on September 19th, 2011, 12:03 AM
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?)
Title: Re: New revs - Public comments
Post by: Arantor on September 19th, 2011, 02:01 AM
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...
Title: Re: New revs - Public comments
Post by: Arantor on September 19th, 2011, 10:31 AM
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.
Title: Re: New revs - Public comments
Post by: Nao on September 19th, 2011, 11:05 AM
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:
Title: Re: New revs - Public comments
Post by: Arantor on September 19th, 2011, 11:08 AM
Quote
Re: cat, I suppose nobody has an opinion on this... Not even us
Oh, I have an opinion, it's that ?cat= would be more consistent and that I think it would be better to do that in the long run, though I can see the validity of doing it through the boards action.
Quote
Re: add-on manager, most likely at the end of the process?
I can certainly document how it's supposed to work right now. It may even help ensure that the process is actually properly followed to my intended design.
Quote
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions.
Yeah, it's the sort of thing that has all kinds of interesting edge cases to cope with, but I don't see it as deeply flawed, more that there are so many ways such things can be used (and abused) that it's hard to nail down every possible permutation and not get anything wrong along the way.
Quote
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.
I just found it a bit narrow at 4px, but 5px works for me :)
Title: Re: New revs - Public comments
Post by: Nao on September 19th, 2011, 05:30 PM
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... :(
Title: Re: New revs - Public comments
Post by: Arantor on September 19th, 2011, 05:47 PM
Quote
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.
Yes, I imagined it would have all kinds of fun in it. Would it help to make the text a shade smaller?
Quote
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'.
I don't have a problem with that, provided that it's documented for people like me to make use of later. (Add-on authors are the people who really need to know that, and I count myself firmly in that category)
Quote
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.
I know I have that open in another tab to comment on at least one thing, but it's possible there's more I've just missed :(
Quote
@ 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
I take it I can't just use the new Windows 8 BSOD text? :P

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.
Title: Re: New revs - Public comments
Post by: Nao on September 20th, 2011, 09:33 AM
- 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.)
Title: Re: New revs - Public comments
Post by: Arantor on September 20th, 2011, 11:56 AM
Quote
- 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'?
'default' works, as incidentally does 'context'. I'd avoid main though, for precisely the reason you give.
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!
OK, what part are you not sure about, exactly? It seems to me the current behaviour is pretty logical.
Quote
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer.
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.
Quote
Okay I have this error message, tried to keep it short and usable by both.
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.
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.
Title: Re: New revs - Public comments
Post by: live627 on September 23rd, 2011, 12:18 AM
Quote
- Removed compactTopicPagesEnable setting
Dragooon's theme disables it
Title: Re: New revs - Public comments
Post by: Arantor on September 23rd, 2011, 12:40 AM
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?
Title: Re: New revs - Public comments
Post by: Nao on September 23rd, 2011, 12:46 AM
@John> ?
Quote from Arantor on September 20th, 2011, 11:56 AM
'default' works, as incidentally does 'context'. I'd avoid main though, for precisely the reason you give.
I think 'default' will be just fine. I haven't felt a desire to change it, which is a good sign :P
Quote
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!
OK, what part are you not sure about, exactly? It seems to me the current behaviour is pretty logical.
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Quote
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.
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
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.
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
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.
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
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?
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.
Title: Re: New revs - Public comments
Post by: Arantor on September 23rd, 2011, 12:57 AM
Quote
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Seriously, it's fine. It might sound odd but it actually works fairly well in practice (now that WedgeDesk does it)
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...
Whether it being worth the hassle is a good question. But it would certainly prevent random tampering with the arrays directly, and it becomes more semantic because instead of having generic (but nicely named) functions, you have an object to which all the functions physically belong.
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...
This is one of the issues I have with SMF's error messages. In the event of a database error, it can quite easily say something to the effect of "There has been a database error, please refer to the administrator." Which is fine - until it displays that message, as is, to an administrator when they're logged (and after determination of permissions has occurred)
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.
Hmm, not sure how to proceed on that one.
Quote
I haven't written it down, but XDebug basically crashed saying "delimiter is empty", IIRC.
Yup, it's complaining that $addonsdir doesn't make sense to it. I'll fix it sometime, have other things going on, like add-on related stuff.

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.
Title: Re: New revs - Public comments
Post by: Dragooon on September 23rd, 2011, 05:26 AM
Quote from live627 on September 23rd, 2011, 12:18 AM
Quote
- Removed compactTopicPagesEnable setting
Dragooon's theme disables it
Yeah, I needed it so that the theme doesn't break.
Title: Re: New revs - Public comments
Post by: Nao on September 23rd, 2011, 07:41 AM
The function will be moved to the index template as discusses earlier. ;)
Title: Re: New revs - Public comments
Post by: Dragooon on September 23rd, 2011, 07:57 AM
That's cool then :D
Title: Re: New revs - Public comments
Post by: Nao on September 23rd, 2011, 12:59 PM
Quote from Arantor on September 23rd, 2011, 12:57 AM
Quote
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Seriously, it's fine. It might sound odd but it actually works fairly well in practice (now that WedgeDesk does it)
Uh... I suppose.
But there's much to be said. For instance:

loadBlock('my_block', array('sidebar', 'default'))

Will add my_block to the sidebar. If not found, however, it will be added to (and NOT replacing) the default layer... Looks logical to me. The other way around (array('default', 'sidebar')) doesn't make sense because default is always there.

Okay, done on my local install... (Hopefully will work fine.)

I'd be tempted, though, to split these into more functions, like 'replaceBlock' and 'addBlock'... Dunno which would be best, really (especially given the number of choices I offer. One function for each...?!)
Or perhaps just alias functions. I mean, it's not like they're called a lot anyway...

function replaceBlock($block, $target)
{
   loadBlock($block, $target, 'replace');
}

Also transformed the info center into the layer. 'info_center_begin' and 'info_center_end' bothered me too much... :lol:
Quote
Whether it being worth the hassle is a good question. But it would certainly prevent random tampering with the arrays directly, and it becomes more semantic because instead of having generic (but nicely named) functions, you have an object to which all the functions physically belong.
Yes, I suppose it's a nice way of doing it.
But loadBlock() is short and sweet. I don't know if wetem::loadBlock() would be better. Or wetem::load_block. Or wetem::load() with Wedge guessing by itself what the contents is (heck, I could do it... I'm just not sure it's as readable!)
Or having functions outside the object, and the object only manipulated through these functions like loadBlock()...?
Quote
This is one of the issues I have with SMF's error messages. In the event of a database error, it can quite easily say something to the effect of "There has been a database error, please refer to the administrator." Which is fine - until it displays that message, as is, to an administrator when they're logged (and after determination of permissions has occurred)
Yeah, true dat!
It would make sense to actually display the faulty query etc to them...
Quote
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.
Hmm, not sure how to proceed on that one.
I believe we should store somewhere the number of language files available. If it's > 1 we call getLanguages() either way. We'll only use $modSettings['userLanguage'] when in the index template, just before showing the flags themselves.
Quote
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.
Ah, attachments and avatars...

It's probably my greatest failure of these last few months. Have you noticed how I keep postponing them...?
It's mainly because I'm afraid doing these changes will push me into a 3-month bug hunt that will prevent us from showing Wedge to the public, etc. I keep thinking of situations where the current attachment and avatar systems make more sense than Aeva's, *or* may require users to change the way they see things. I'm already considering ensuring the avatar and attachment albums won't be browsable by users (bit wary of the permission issues -- way too risky). Things like that, from which I'm backing off... (backing away?)

To be honest -- apart from the cool fact that Aeva would allow user to rotate through their favorite avatars (I do have a local folder of my favorite avatars but maintaining it is a hassle), the main reason why I released Aeva Media 2.10 (you know, the failed one :P) *AND* wanted to have v2.10 in Wedge (instead of 1.x), *AND* wanted to replace the avatar system with Aeva, is because.... Wait for it... I love having a drop shadow on my avatar, and want it on every forum I go to, but I just don't want a drop shadow when I'm using a transparent avatar!

Yeah... That's, basically, the only reason I did all of it.

I'm stupid.
Quote
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.
Yeah, and more than that... Topic level. See what I mean. (If we implement topic privacy. Another of my recent failures.)
Quote
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.
I'm not sure I understand.

Oh, and if we have board-level permissions, then I suppose we could (should?!) modify Aeva to use boards and topics instead of albums and items. Not sure about that yet, though... It basically means implementing the floating topic stuff.
Title: Re: New revs - Public comments
Post by: Arantor on September 23rd, 2011, 01:37 PM
I'm cool with the template changes :)
Quote
I'd be tempted, though, to split these into more functions, like 'replaceBlock' and 'addBlock'... Dunno which would be best, really (especially given the number of choices I offer. One function for each...?!)
I'd avoid making too many functions, especially if they're fairly similar or related. Trust your instincts on this one.
Quote
Or having functions outside the object, and the object only manipulated through these functions like loadBlock()...?
No, if you have an object whose job it is to handle the template skeleton, not only is it the holder of the data, but it's also responsible for changing that data. In any case, if it's to be tamper-proof except for through the defined methods, the methods have to be part of the object because you'd make the list itself a private variable - which by definition can only be manipulated inside the object's own methods, and is never made directly available outside of it.
Quote
Yeah, true dat!
It would make sense to actually display the faulty query etc to them...
At least then there would be a useful start to debugging...
Quote
I believe we should store somewhere the number of language files available. If it's > 1 we call getLanguages() either way. We'll only use $modSettings['userLanguage'] when in the index template, just before showing the flags themselves.
You know, we could just ship with both English and French installed by default so it's always > 1 :whistle:
Quote
It's probably my greatest failure of these last few months. Have you noticed how I keep postponing them...?
I had noticed, but I'm not in the slightest surprised. It's a massive undertaking at the best of times, and it has so many knock-on effects that it will inspire fear and dread in anyone.
Quote
I keep thinking of situations where the current attachment and avatar systems make more sense than Aeva's
There aren't that many situations, and frankly I think they're avoidable too.

The main ones that I envisage are where you end up with what amounts to a single album that contains all the attachments, but that access rights to that album are inconsistent with how an album usually functions. That, and separating viewing a thumbnail from viewing the main file (it's a fairly common request because SMF says either you can see it or you can't, no in-between ground)
Quote
*or* may require users to change the way they see things
As you reminded me yesterday, http://yarr.me/cache/8a07b66f80a1982895b8acf157fe1002.jpg

I have no problem with changing how users see things, provided that where we go to is a logical, meaningful place. To me, sifting out the code so that we have one path for accessing attachments/avatars/gallery items seems like a logical place to go - and we get the benefits of integrating Zoomedia cleanly :)
Quote
I love having a drop shadow on my avatar, and want it on every forum I go to, but I just don't want a drop shadow when I'm using a transparent avatar!
Nothing wrong with having ambition. Maybe that is a little unbalanced in terms of work vs reward (though far less so than building a wall just to put a hook on it for a coat), but I think it's a meaningful one because right now we have two distinct paths to serving files and so on, even though the operations are virtually identical, and we should fix that.

Really: what's the difference between what MGalleryItem does and what Dlattach does? They still look up where a file is, whether the user can see it or not, and ultimately serve the file.
Quote
Yeah, and more than that... Topic level. See what I mean. (If we implement topic privacy. Another of my recent failures.)
Again, I don't really see it as a failure, no more so than my not having reimplemented permissions yet. It's just another thing to do that has massive system-wide consequences and can easily turn into a tour-de-force of bug hunting.
Quote
I'm not sure I understand.
OK, best thing to do is take a look at the code in the modified Download() function in Display.php on this site (or, failing that, a fresh 2.0 final install with SD 2.0 installed).

Firstly, it checks for 'avatar' in the URL, and if so, it queries for the avatar's details (filename etc.). If not, SD's injected code looks for 'ticket' in the URL, and if so, it tries to query for the details *there*. Failing that, it just looks for the normal route (attach id + topic id)

Note that it doesn't *fetch* the information at this point, merely queries for it, and then passes the query result to the fetch code, so regardless of the query actually run, it knows that no rows means the attachment can't be found or seen (either way, it neither knows nor cares which), otherwise it serves the file it has.

SD added its own handler in there, and I can envisage something similar in the attachment code, whatever form it's in, to have a hook, and see if anything attached to the hook will validate the requested file, and if so, prepare to serve it.
Quote
Oh, and if we have board-level permissions, then I suppose we could (should?!) modify Aeva to use boards and topics instead of albums and items. Not sure about that yet, though... It basically means implementing the floating topic stuff.
Yup. So many inter-related parts, it's so hard to judge where to start.
Title: Re: New revs - Public comments
Post by: Arantor on September 23rd, 2011, 08:28 PM
Btw, when I first split the info centre up way way back, there weren't arbitrarily nested layers the way that the skeleton now exists - we only had the single array of templates, good that it's been tidied up :)
Title: Re: New revs - Public comments
Post by: Nao on September 24th, 2011, 12:28 AM
I thought so ;)
Glad to know!
Title: Re: New revs - Public comments
Post by: live627 on September 24th, 2011, 01:40 AM
loadAddonLanguage: If the file isn't found, an undefined variable error occurs ($found)
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2011, 01:49 AM
Eeek, I'd better fix that! Thanks for the heads-up!

(I'll fix it in my local copy which has a bunch of related stuff in it and commit it all together.)
Title: Re: New revs - Public comments
Post by: live627 on September 24th, 2011, 02:10 AM
Sure, and while I'm at it, before I run, I have four ENUM columns for my addon. None specify a default, in fact, no /columns have a default. Yet, the query forces a blank default, which throws an error on ENUM. This tripped me up for a while, until I figured out what was going on.

Is there a specific reason for forcing a default? I could circumvent the problem by removing it, which seems to be accepted in MySQL.
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2011, 02:14 AM
Hmm. I don't recall forcing a default in ENUM columns but to be fair I never *actually* tested ENUM columns, so I expected it to be a bit broken.

If no default is specified, one shouldn't be used - however, using defaults is a good practice because it means you don't have to worry about it on insertion if you don't have to change it. (And some columns, like text/mediumtext, must not have a default)

Guess that needs to be fixed, but I wouldn't describe it as battle-hardened. It works for what I've thrown at it thus far... but that's not extensive or exhaustive.
Title: Re: New revs - Public comments
Post by: Nao on September 24th, 2011, 02:26 AM
Welcome to the AeMe 2.10 nightmare :lol:
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2011, 02:27 AM
AeMe 2.10 was specifically the reason why I added ENUM support :P But it wasn't tested thoroughly, it just means that the code which deals with defaults is a shade buggy, not that it's a hellhole of support nightmare :P
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2011, 02:58 PM
I've committed the undefined found variable fix, haven't looked into ENUM yet, but will do in a bit.
Posted: September 24th, 2011, 02:14 PM

And I think I nailed the ENUM issue as well :)
Title: Re: New revs - Public comments
Post by: live627 on September 25th, 2011, 12:04 AM
The ENUM issue seems to be gone now. Thanks.
Title: Re: New revs - Public comments
Post by: Arantor on September 25th, 2011, 12:11 AM
Awesome, thanks for testing :)
Title: Re: New revs - Public comments
Post by: Arantor on September 25th, 2011, 02:28 AM
Re 1031: I don't think it's too many blocks. I think it's really just right because they're the things themers have in the default theme to play with and realign/reposition as they see fit, but I wouldn't go any more thorough than that, at least not in the header (other areas, however, may need changes)

And, in other news, that means I can remove yet another hack from WedgeDesk under certain circumstances, YES.

In other other news, I got to wondering. How much effort would it be, at present, to be able to inject something between the calls to the post template (i.e. displaying ads)? While I'm not bothered myself about being able to use ads, I know that a lot of users *are*, and in between first and second (and between penultimate and last) post is something that does come up.
Title: Re: New revs - Public comments
Post by: Nao on September 27th, 2011, 05:15 PM
Re: too many blocks -- yeah, I suppose index.template.php is really a special case... And a dozen extra blocks aren't going to kill performance -- it's all very fast. Although we might wanna do a get_defined_functions() once and for all, and then test through isset() instead of function_exists()...

Re: injection, as I answered somewhere else, one can easily hook their function into 'display_post_done' and use $counter to determine the position in the list. :)

Re: addon code, I'm looking through it again (still over 3000 lines to go through, WTF...), and noticed the menu entry for addons has a lot of content commented out. I suppose you're aware of that, but you might wanna clean it up... I generally dislike commented out code being committed without a good reason :P
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 05:40 PM
Yeah, I am aware of that code, and as the rest of the add-on system is implemented, that'll be phased out in stages (along with Packages and Subs-Packages)
Title: Re: New revs - Public comments
Post by: Nao on September 27th, 2011, 06:05 PM
Okay, good then.

Looking through Subs-BBC. You added a hook right before the code that caches parsed data. Wouldn't it make more sense to add it after, so that the hook is always called, even if the post is cached? (One would have to call the same hook much earlier when returning the cached data, of course.)
Although I'm not exactly sure of the point of caching parsed data for only six minutes... It's very likely to be called only once or twice in that time...

Also, I'm doing the language files...

fatal_install_error_minmysql and minphp have two sprintf params, %1$d and %2$s, which both correspond to a version number. Wouldn't it make more sense to have %1$s for the first as well...?

fatal_install_error_missinghook has a typo (avaialble). Fixed on my side. I'm saying that but there's bound to be typos in my translation as well, given how fast I'm working on it... :whistle:

fatal_install_remove_missing is using the term 'disabled' instead of 'removed' or 'uninstalled'.

Why did you remove the media_welcome mention from the help files...? (media_admin_settings_welcome_subtext)

Template stuff:

+      // Add-on buttons. They're floated right, so need to be first. Besides which, the floating means they need to be in reverse order :/

Why not use inline-blocks then...?

I think that's all for now... I'm committing my changes thus far. 2800KB left to check......... :( :( :(
Posted: September 27th, 2011, 05:58 PM

Oh, and do you know your Dragooon-contributed code in rev 1032 uses the word 'plugin'? :P :P
Posted: September 27th, 2011, 05:59 PM

rev 1032 has:

+            break; // I'd use break 2 but that's deprecated in PHP 5.4.

Actually they removed break $var, not break (constant number)... :^^;:

(And yes it's not something that was added in 1032.)
Posted: September 27th, 2011, 06:02 PM

The same function with 'break 2' defines a variable that's never used -- $can_use... I'm removing it.
Just saying ;)
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 06:09 PM
The idea was to parse the post then cache it, which seemed more logical to me than force whatever changes there were every time. In the case which prompted that, the hook makes DB queries.

Yes, it should be $s not $d, oops.

Fairly sure I just reused the same language string there, out of laziness. The whole disable/remove part is distinctly less polished.

I changed the mention because it referenced Modifications.english.php which doesn't exist now.

They're addon-item which derives from admin-item which is used in the main menu, and should be defined as inline block. The idea is that they're inline, but the entire container is right aligned, so the container is floated right, but I found the only way to make then work properly was to do it how I did it; if one item has 3 buttons and another only has 2, that item will have a space to the right so enable/disable buttons always line up.[nb]Though in hindsight, it's only ever going to be 1 icon or 2, not 2 or 3, because the combinations are (do-enable + remove, or do-disable + optional settings)

I'm no template designer :P

Re PHP 5.4 stuff, I read it as break x being broken, not break $var but it's easily possible that I misread it.

I must have missed the use of plugin at the time but it was quite late at night :P And $can_use... pass, can't remember, sorry.
Title: Re: New revs - Public comments
Post by: Dragooon on September 27th, 2011, 06:12 PM
There are 7 instances of plugin in ManageAddons.php :p
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 06:19 PM
/mesays a rude word.
Title: Re: New revs - Public comments
Post by: Nao on September 27th, 2011, 06:22 PM
Quote from Arantor on September 27th, 2011, 06:09 PM
The idea was to parse the post then cache it, which seemed more logical to me than force whatever changes there were every time. In the case which prompted that, the hook makes DB queries.
As long as it's not an oversight... :)
Quote
Yes, it should be $s not $d, oops.
Fixed locally. (Wasn't sure whether to fix in rev 1034.)
Quote
Fairly sure I just reused the same language string there, out of laziness. The whole disable/remove part is distinctly less polished.
Fixed locally.
Quote
I changed the mention because it referenced Modifications.english.php which doesn't exist now.
Oh... All right. I forgot about that one... But then, where do we add this string? Lol. I liked it because it allowed me to have multilingual welcome messages in the media area without the chance of them being removed with an upgrade... As of now, it's no longer possible to define a string, except by implementing the 'lang' tag, which isn't the case yet...
Quote
Re PHP 5.4 stuff, I read it as break x being broken, not break $var but it's easily possible that I misread it.
There's a stackoverflow topic about it and it says break x isn't broken. I would be surprised myself that they remove support for it. Might as well remove support for break entirely, then... Break is spaghetti code! Man up and keep going through the loop until the end, computers are here to compute for you!! :lol:
Quote
I must have missed the use of plugin at the time but it was quite late at night :P
I still haven't given up... :niark:
Quote
And $can_use... pass, can't remember, sorry.
It was in your very first commit of the file. I suspect it's something you used before, but then you did it differently and forgot to remove the var, just like I forgot to remove the $context['layer_hints'] definition a few days ago.
Quote from Arantor on September 27th, 2011, 06:19 PM
/mesays a rude word.
It's time to pull the PLUG... :eheh:
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 06:26 PM
Quote
I liked it because it allowed me to have multilingual welcome messages in the media area without the chance of them being removed with an upgrade
I think you're in the minority on that one, unfortunately. I suspect most people don't really care :(

As for $can_use, you're probably right.

And really, if you do want to rename it, just do it! :P As per WP:BOLD, and not even with a [citation needed] in sight :P
Title: Re: New revs - Public comments
Post by: Nao on September 27th, 2011, 06:38 PM
Yeah, I suppose they don't care...
Let's just say it'll be up to that lang tag.

WP:BOLD I can understand through googling, but citation needed? Don't see the relationship with what we're talking about -- even with Wikipedia in mind.
Still, I can't suddenly rename everything when most people voted for 'add-on', including *you*... That makes a clear majority for add-ons. I just hate that hyphen, and even if I remove it, the word looks odd to me :P
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 06:54 PM
The whole cit-needed was simply to indicate that it was Wikipedia not WordPress ;) I guess I'm thinking of meta things right now (it's all Dr Who's fault with the finale this weekend!)

I'm fine with renaming it to addon (instead of add-on, even though my autocorrect hates it)
Title: Re: New revs - Public comments
Post by: Nao on September 27th, 2011, 07:27 PM
We are talking about renaming to plugins not addons :P
Title: Re: New revs - Public comments
Post by: Arantor on September 27th, 2011, 07:31 PM
But you said you hated the hyphen, so remove it :P

At this point I'm beyond worrying about what it's called and concentrating on making it work and work well. Perhaps we should put in a poll for plugin, add-on and Wedget or Wedgelet, and disallow mod because it implies modifying files, which add-ons shouldn't generally be doing.
Title: Re: New revs - Public comments
Post by: Nao on September 28th, 2011, 06:41 PM
I noticed you used this a few times:

filetype($addonsdir . '/' . $folder) == 'dir'

Why not just use is_dir()...? Is it any faster?
Posted: September 28th, 2011, 06:31 PM

Another commented out line of code (multiple, actually):
//libxml_use_internal_errors(true);

Doesn't say whether you're planning to restore them or delete them, so I thought I'd mention them...
Posted: September 28th, 2011, 06:40 PM

Typo...? (Used twice.)
// Users might be insert 5 or 5.3 or 5.3.0.
Title: Re: New revs - Public comments
Post by: Arantor on September 28th, 2011, 07:21 PM
I can't remember why I used filetype instead of is_dir, performance will be comparable though.

The libxml lines will be restored in due course, but while I'm working on it and debugging it, I wanted any libxml/SimpleXML errors to actually be thrown, as opposed to caught separately (which is what will eventually happen)

Nope, not a typo. The idea is that users, including plugin add-on contributing authors, are inherently lazy. If they require PHP 5.4, say, should they use 5.4 or 5.4.0? version_compare expressly considers 5.4 to be different to 5.4.0 so the idea is to normalise them as best possible before calling version_compare, and well, I did the PHP ones first, then copied it for MySQL.
Title: Re: New revs - Public comments
Post by: Nao on September 28th, 2011, 07:58 PM
- Convert to is_dir, then?
- Okay!
- What does the 'be insert' mean, if it's not a typo....? :unsure:
Title: Re: New revs - Public comments
Post by: Arantor on September 28th, 2011, 08:00 PM
Oh, heh, yeah, 'be insert' is a typo.
Title: Re: New revs - Public comments
Post by: Nao on September 28th, 2011, 08:07 PM
So, the original sentence is....?
Title: Re: New revs - Public comments
Post by: Arantor on September 28th, 2011, 08:08 PM
"User might insert 5, or 5.3, or 5.3.0" or something to that effect.
Title: Re: New revs - Public comments
Post by: Nao on September 28th, 2011, 09:38 PM
+   $params = array(&$boardIndexOptions);
+   if ($boardIndexOptions)
+      $params[] = &$categories;
+   else
+      $params[] = &$this_category;
+   call_hook('get_boardindex', $params);

I'm assuming you meant to test for include_categories...?

Wouldn't that be simpler (and more accurate)?

Code: [Select]
call_hook('get_boardindex', array(&$boardIndexOptions, $boardIndexOptions['include_categories'] ? &$categories : &$this_category));
Title: Re: New revs - Public comments
Post by: Arantor on September 28th, 2011, 09:40 PM
Yes, I meant to test for that. No, you can't do what you suggest, I tried it originally and PHP complained bitterly.
Title: Re: New revs - Public comments
Post by: Nao on September 28th, 2011, 09:56 PM
- Does that mean I need to test your 3000 lines thoroughly? :P I'm kind of skipping through the large functions because they seem to be okay and I'm mainly focusing on the smaller things outside these functions, such as this... Please don't tell me I have to spend my week on that... :^^;: I still have 1600 lines left to check...

- Yeah, I remembered in the meantime: the official syntax is "$a =& $b", not "$a = &$b", because that's really "=&" and it basically says that $a is an alias to $b, and $b is an alias to $a just the same, so it's not really the same to PHP...
Posted: September 28th, 2011, 09:50 PM

There are some beautiful pieces of code in your table creation function, btw :)
Title: Re: New revs - Public comments
Post by: Arantor on September 28th, 2011, 09:58 PM
I wouldn't worry about testing the code thoroughly because what will happen is that I'll be testing it by writing add-ons which will show up different weaknesses in the code, e.g. how live reported an issue with ENUM handling in the DB code, and the more hammering it gets with add-ons, the more thoroughly it's all going to be shaken out.

It might not hurt to write unit tests for the add-on manager.

And thanks :) I did try to construct something that would handle what I was going to throw at it, and it reverts one of the irritations I had in later SMF releases that the code was removed instead of fixing it.
Title: Re: New revs - Public comments
Post by: Arantor on October 2nd, 2011, 06:18 PM
Some interesting things in r1049.

Probably the first one which occurs to me is:
Quote
Also note that $admin_areas is now a global, so the admin menu hook doesn't need to specify it as a param.
Why? It wasn't part of $context originally for a reason: security. The only way it could be modified was through the defined hook, because as soon as it's been back from the hook, housekeeping is done then it's sent off to createMenu, whereupon it is discarded.
Quote
if you modify the admin menu, you'll need to manually remove the cache file, or run clean_cache('css', 'admenu') through a hook or something.
I'd rather automate that if possible. While it's not particularly ideal to sit and retest the entire menu structure for changes, if it's been to a hook, the hook is going to have added some items which will likely negate the cache.

What, exactly, is cached here? (I haven't looked yet.) I wasn't that fond in SMF of having things cached after hooks had been run, it seemed to defy the point of having per-run hooks and can lead to messiness after things have been disabled or even enabled. (Perhaps the plugin enable/disable steps should also clean cache generally anyway.)

That said, it seems to be purely CSS cached here, in which case only plugins that do... something... with CSS need to clear it? Let me know exactly what's being cached, or I'll figure it out from the source, whichever happens first, and I can then make a judgement as to whether the plugin manager should do that automatically or whether plugins that make a change there need to deal with it.
Quote
Added three icons to the topic moderation menu. Only visible to members with the correct permissions.
Icons are good. Unless they look massively out of place, they'll probably be fine and might encourage us to iconify the rest, which is generally a good thing.
Quote
Package functions don't need to declare admin.css, since it's already declared by that time. (PackageGet.php, Packages.php)
I wouldn't worry too much about maintaining these files. As things evolve, these two plus Subs-Package are going to be phased out anyway.
Title: Re: New revs - Public comments
Post by: Nao on October 3rd, 2011, 12:19 AM
Quote from Arantor on October 2nd, 2011, 06:18 PM
Quote
Also note that $admin_areas is now a global, so the admin menu hook doesn't need to specify it as a param.
Why? It wasn't part of $context originally for a reason: security. The only way it could be modified was through the defined hook, because as soon as it's been back from the hook, housekeeping is done then it's sent off to createMenu, whereupon it is discarded.
Its lifetime is the same. I globaled it so that it could be used in dynamic_admin_menu_icons or something. As soon as the unique hook is called and the menu is create -- that array goes away, too.
Quote
Quote
if you modify the admin menu, you'll need to manually remove the cache file, or run clean_cache('css', 'admenu') through a hook or something.
I'd rather automate that if possible. While it's not particularly ideal to sit and retest the entire menu structure for changes, if it's been to a hook, the hook is going to have added some items which will likely negate the cache.
It's only an icon cache... I'm caching ALL of the icons in the array, regardless of whether they can be shown to the user. Small enough anyway.

As for the loadBlock stuff, it's going to have to wait until tomorrow. I noticed another bug in the index rebuilder -- if it's called more than once, it erases the skeleton :(
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2011, 12:23 AM
Quote
It's only an icon cache... I'm caching ALL of the icons in the array, regardless of whether they can be shown to the user. Small enough anyway.
Therein lies the problem. A plugin may or may not call an icon, and it may or may not call an icon from its own folder (but reuse an existing one) - but the list of possible icons may be the same call to call.

I still haven't looked at the code, but I really hope it's checking whether it's a URL or not, because otherwise it's likely to be calling for a plugin's icon(s) through an external URL request only to be served locally... (I couldn't see any way of passing just a filename to the menu builder and for it to be able to cope with it, so the menu builder looks to see if it's a URL or not, and if not, serves it from the theme as normal)
Title: Re: New revs - Public comments
Post by: Nao on October 3rd, 2011, 08:01 AM
That's the thing. It checks for urls first. Meaning this is never a real problem.

Holy fuck I'm stuck to bed for now. My legs hurt horribly after a ridiculous attempt to ahem, jog...
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2011, 10:52 AM
Jogging is harsh :/

Anything in particular you'd like me to look over in r1049 since you flagged it as wanting feedback?

Also, I've committed the RelaxNG spec I've been referring to. It should validate current plugin-info.xml files - that should cover everything currently supported in the plugin manager, as well as validating new columns and indexes for existing tables, which is currently not supported.
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2011, 11:09 AM
Although, I'm getting pretty fed up when one tool validates both my RNG schema and a big scary file against it but PHP's XMLReader won't because of 'Extra element database in interleave' when there really isn't - and, just for fun, if I comment out the <tables> construct inside <database>, it works as expected :/
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2011, 12:08 PM
I figured out the problem with the above, mostly it's because libxml2 is more strict than <oXygen/> XML editor is.

For those who've written a plugin thus far, you can crudely test it with:
Code: [Select]
<?php
$schema 
'/path/to/other/plugin-info.rng';
$document '/path/to/plugin-info.xml';
$xml_reader = new XMLReader();
$xml_reader->open($document);
$xml_reader->setRelaxNGSchema($schema);

$valid true;
while (
$xml_reader->read())
if (!$xml_reader->isValid())
$valid false;

var_dump($valid);
?>

Note that you set the schema after you load the document, as opposed to the more traditional approach of stating the schema actually in the file like you would through a DOCTYPE.
Title: Re: New revs - Public comments
Post by: Nao on October 3rd, 2011, 02:52 PM
Quote from Arantor on October 3rd, 2011, 10:52 AM
Jogging is harsh :/
I can breathe and everything, even though I'm a smoker, but the first things to fail me in my body are always the collateral ligaments in my left knee (followed by the right knee a few minutes later.)
I've always had weak knees but my girlfriend won't listen to me... She insisted we run for an hour, even when it was the first time we'd been jogging in years. Yeah sure...

Anyway-- that's life. I'm pretty messed up today. My health has been worsening ever since I started work on Wedge. Wondering how I'm going to cope after we go live...
Quote
Anything in particular you'd like me to look over in r1049 since you flagged it as wanting feedback?
It was mainly about the new icons in the moderation strip. I took classic SMF icons and made them smaller, but I hesitate between keeping them this way, or making them grayscale. Also, would possibly be better to use another icon set... Maybe the very small ones. Diagona or another.
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2011, 03:01 PM
Take care of yourself! I doubt I could manage an hour's jog. Even after two months on Wii Fit... which I've let lapse because even after 2 months I hadn't shifted much in the way of weight. :(
Quote
Anyway-- that's life. I'm pretty messed up today. My health has been worsening ever since I started work on Wedge. Wondering how I'm going to cope after we go live...
Going live isn't going to be a problem, given my typical 100+ posts per day support schedule... especially given that towards the end of my regular time at sm.org I was consistently doing 5k posts a month.

I'm hoping, though, to limit the number of support posts that we get by setting intelligent defaults (like making quick reply on by default) and the admin UI just being easier to cope with.

Meanwhile, I'm just reinstalling it cleanly to be able to judge what it looks like - but I'm getting the impression that using Diagona icons might be an idea.
Posted: October 3rd, 2011, 02:59 PM

Having now actually seen it, I'm inclined to agree with using smaller icons. They just seem a shade too big for the relative size of buttons. Going greyscale won't really help, IMO.
Title: Re: New revs - Public comments
Post by: Nao on October 3rd, 2011, 07:20 PM
Btw I've fixed the skeleton stuff. Took me a day because of a STUPID mistake (I'd removed a & where I shouldn't have.)
RemoveLayer was broken too btw.
Title: Re: New revs - Public comments
Post by: PantsManUK on October 4th, 2011, 10:25 AM
Quote from Nao on October 3rd, 2011, 02:52 PM
can breathe and everything, even though I'm a smoker, but the first things to fail me in my body are always the collateral ligaments in my left knee (followed by the right knee a few minutes later.)
I've always had weak knees but my girlfriend won't listen to me... She insisted we run for an hour, even when it was the first time we'd been jogging in years. Yeah sure...
Wildly OT, but have you considered having an ibuprofen or aspirin tablet (with food or milk) an hour *before* you go out jogging? It'll help with pain during and recovery after... Former Olympian told me that one. Oh, and make her make you run less until you're comfortable running for half an hour (you fool).

(That is all, further correspondence on the subject can be conducted via PM)
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 10:28 AM
Have no idea what I'll do next about this... I guess I'll just refuse to jog at all until I find a solution for my knees. As I said, I could only run for 5 minutes before I was pretty much unable to *walk* at all. Then I simply looked ridiculous for the remaining 55 minutes :P
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 10:32 AM
Get bionic knees!!
Title: Re: New revs - Public comments
Post by: Cassiel on October 4th, 2011, 05:25 PM
Maybe you'll find it easier to bike instead of jog?
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 07:01 PM
A few bugs to take care of in the recycle bin... (I'm still of the opinion that this thing should go anyway :P)

- If you're trying to restore posts, you get the "empty skeleton" error message.

- Even worse -- if you're trying to restore posts *when there are no other boards available* (or possibly even if there are other boards, just not the original post board), the messages just disappear!
Well, they're not deleted, but they're given their original board ID back, and since there's no board at that address, the posts just become invisible. Nasty bug!

(This happened after I clicked 'Delete board' to see if there was some kind of confirmation request... Well, there isn't. Something else to fix!)
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 07:03 PM
Yeah, it should go - subject to a good (better) replacement being added.
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 07:29 PM
In the meantime, could you look into these bugs? IRL time... >_<
I'm curious about the skeleton error... It shouldn't be happening. I'm sure it can be spotted just by looking at the source code.

Another error: go to the admin area, Maintenance, click on Repair. You're redirected to the main page without a confirmation or whatever... (The task still runs though, AFAIK. Although it didn't reassociate my restored posts with my newly re-created board #1... I guess it's the kind of error that doesn't happen to EVERYONE, meh...)
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 07:39 PM
I'm away from keyboard for a few hours (on iPad) but I will when I get back upstairs.
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 10:30 PM
RepairBoards error is due to something you implemented in Admin.php, I'm not exactly sure what it does but it seems to be security-related. Please find a solution...?

Code: [Select]
// The admin front page is not part of the above. But if you can see any of the items in the admin panel, you can see the front page too.
elseif (empty($_GET['area']) || $_GET['area'] != $menu_context['current_area'])

The problem is that area=repairboards but current_area=maintain, as per the 'select' => 'maintain' entry in the menu array. You already added a workaround for AdminSearch (which had 'select' => 'index'), but not for RepairBoards...
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 10:33 PM
Not security related, but logic related; the point is that the front page should exist and be a valid fallback for requested pages (i.e. ones that don't exist/aren't accessible), while the index shouldn't exist as far as the menu is concerned.

Seems to suggest the repair boards logic is broken in some other interesting way. I'll take a look later on.
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 11:11 PM
I don't think the logic is broken... It just needs special treatment at the top level, just like you gave to AdminSearch. Although at this point I think it'd make more sense to do generic handling of all 'select'-type entries.

Also, I *think* there's supposed to be a confirmation request for deleting boards.... I only get one for deleting categories. Can you...confirm? Anyone?

Re: restore posts, I couldn't find the origin of the skeleton error. Argh. If you could look into it as well... I have no time to actually go and try to restore posts for now.

Re: board ID bug, I don't really know how Wedge should react to this... Or do we just drop this and use unapproved posts instead?

Loosely related: when deleting a post, Wedge should update its 'children' posts to use the deleted post's parent ID. Should be easy enough, but we then have to update their own children, too... I'm not sure how to do this with minimal impact on the DB performance.
And-- I guess 'parent' shouldn't be touched when removing through the recycle bin... Or maybe yes. What's certain is that it shouldn't be deleted when a post is 'unapproved'.

Sorry, lots of questions and not many answers from me today... Girlfriend is calling. Don't want to get into trouble :P
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 11:27 PM
Quote
I don't think the logic is broken... It just needs special treatment at the top level, just like you gave to AdminSearch. Although at this point I think it'd make more sense to do generic handling of all 'select'-type entries.
Why does it need special treatment? Doesn't it call a function and issue a normal template?
Quote
Also, I *think* there's supposed to be a confirmation request for deleting boards.... I only get one for deleting categories. Can you...confirm? Anyone?
Fairly sure there's supposed to be... there's a JS error in suggest.js (which is called for the board moderator selector) which causes the rest of the page JS to get upset, which prevents the confirm() being called.
Quote
Re: restore posts, I couldn't find the origin of the skeleton error. Argh. If you could look into it as well... I have no time to actually go and try to restore posts for now
I'll look into it right now I'm back on the PC.
Quote
Loosely related: when deleting a post, Wedge should update its 'children' posts to use the deleted post's parent ID. Should be easy enough, but we then have to update their own children, too... I'm not sure how to do this with minimal impact on the DB performance.
It's tricky - and that's before you get into the realms of split/merging. However, if you have any given tree of x->y->z, and it's y you're deleting, you only have to update all the cases for z where the parent is y. It's a single-direction graph, we're only recording the parent, not the children, nor the latter descendants, so if post y is deleted, UPDATE wedge_messages SET id_parent = x WHERE id_parent = y, and that'll match all the z cases because we're only recording the immediate parent...
Quote
And-- I guess 'parent' shouldn't be touched when removing through the recycle bin... Or maybe yes. What's certain is that it shouldn't be deleted when a post is 'unapproved'.
This is *really* where it gets fun. What might be better is if the actual hierarchy remains untouched in a physical sense but a simple "This post has been removed" placeholder is shown to the user. That would not only solve the whole issue of how to handle it (because you don't move it, you leave it totally in place) and prevent logical disjoint where the post is removed and the flow of conversation seems broken: it's still going to be broken if part of the conversation is missing, but at least you have context for it.
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2011, 11:41 PM
Re: deletion-- oops. I think I actually did it the correct way in the hack I posted back in 2008 or so at sm.org.

Really shouldn't be coding when I'm tired....
Re suggest, I was actually thinking of a separate page to confirm rather than a confirm box. Will have to fix suggest though. Unless you do it before me. Will resume my answer tomorrow.
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2011, 11:47 PM
I cannot reproduce the actual error with restoration myself, however I don't have pretty URLs on.[1]

It seems irrelevant, but the only thing I can tie into it is that when successfully proceeding with the restoration[2] is that at the end it falls to a redirectexit(). No skeleton is set up by the action itself, as no block is loaded - and that would give you the same error, presumably.

Something about pretty URLs causes redirectexit() - no parameters - to fail. In the spirit of interest, while already logged in, head over to action=login and see what happens. If that fails the same way (which I expect it to), there's your culprit. Fixing it though... that's another story.

As far as the restoration going into a phantom board, it certainly should check - the code looks like it's trying to do just that (and with an INNER JOIN to the previous board, it *should* fail at that point). I'd even argue that it should have validated the ownership of the post in the first place - because under the same setup, a post deleted from a board you can't see will end up in the same place, and you can restore it back to that board without having access to it.

Also note that the post's icon is changed too, there's no reason why it actually has to change the icon, displaying inside the recycle board simply needs to fudge the icon in the message and display loaders without having to compromise data.


I can certainly fix up suggest in the meantime since that would imply it's broken elsewhere too.
 1. Frankly, every time I do enable it, something usually breaks, so I never touch it, but maybe I am doing something wrong!
 2. In other news, it seems strange that RestoreTopic is in RemoveTopic.php, but then again we did the same in SimpleDesk...
Title: Re: New revs - Public comments
Post by: Arantor on October 5th, 2011, 12:26 AM
OK, so I see the suggest JS is fixed. I've also fixed a side issue that I noticed from editing boards, in the clean_cache function.

Going back to the repairboards code, I can see that Subs-Menu is supposed to deal with pages that use 'select' to cross area boundaries as far as the menu's concerned. Line 205 has it resetting the current area, so as far as I'm concerned, it's supposed to be dealing with that automatically.

The only reason the top level stuff is handled in Admin.php is because it expressly doesn't appear in the menu, and really, neither of those two items should. repairboards is just special, because it's the only item that now does that in the Admin page.
Posted: October 5th, 2011, 12:17 AM

Meh, just rejigged the code in Subs-Menu to not only update the current_area but also to force it to be detected as such later.
Title: Re: New revs - Public comments
Post by: Nao on October 6th, 2011, 02:58 PM
Suggestion with contiguous pages:

$contiguous_pages = isset($modSettings['contiguous_pages']) ? $mod[..] : 5;

(Can't remember the name of the variable off the top of my head.)
This would allow Wedge to simply re-use the imported SMF's value; although probably not very important...
Similarly, every time we change the name of an SMF variable (from $modSettings and $settings, I mean), we should ensure it's also reflected in the import tool.

Thorsten, do you keep track of these...?
Quote from Nao on October 4th, 2011, 11:11 PM
Re: restore posts, I couldn't find the origin of the skeleton error. Argh. If you could look into it as well... I have no time to actually go and try to restore posts for now.
Headache... Tried to delete another post, and it doesn't show up in the recycle bin. I probably disabled it... But then why did my earlier topic get put into it...? I suspect there's something awry here.
Again, not really worth much of my attention, as I'd really like to get rid of the bin before we go alpha...
Quote
Loosely related: when deleting a post, Wedge should update its 'children' posts to use the deleted post's parent ID. Should be easy enough, but we then have to update their own children, too... I'm not sure how to do this with minimal impact on the DB performance.
I committed my query for this. Heck, it pissed me off so much, I didn't take time to actually test it... (I mean, it doesn't crash, but I haven't tested with phpMyAdmin around.)

Been procrastinating a bit regarding Wedge lately... Got hooked on Misfits (UK show). Misfits is to Heroes what Skins was to 90210 & co. (Well, except I liked the first few episodes of Heroes better than the first season of Misfits. But then again, they should have made Heroes focus on Hiro and last only one season... Instant cult show.)
Posted: October 6th, 2011, 02:57 PM
Quote from Arantor on October 4th, 2011, 11:47 PM
Something about pretty URLs causes redirectexit() - no parameters - to fail. In the spirit of interest, while already logged in, head over to action=login and see what happens. If that fails the same way (which I expect it to), there's your culprit.
Nope..... :(
No error.
Title: Re: New revs - Public comments
Post by: Arantor on October 6th, 2011, 03:05 PM
Quote
Suggestion with contiguous pages:

$contiguous_pages = isset($modSettings['contiguous_pages']) ? $mod[..] : 5;
Works for me.
Quote
Similarly, every time we change the name of an SMF variable (from $modSettings and $settings, I mean), we should ensure it's also reflected in the import tool.
On the one hand I see the wisdom of this, and on the other, I find I'm not actually that bothered by setting it. Stuff that's actually important functionally, yes, but stuff that's aesthetic, like this - I'm just not that bothered, especially since I doubt most of the time people even change half these settings. In this particular case I deliberately didn't even make it a theme setting - because I do not recall ever seeing it modified anywhere. Not everything needs to be configurable from the ACP.
Quote
Headache... Tried to delete another post, and it doesn't show up in the recycle bin. I probably disabled it... But then why did my earlier topic get put into it...? I suspect there's something awry here.
Again, not really worth much of my attention, as I'd really like to get rid of the bin before we go alpha...
Then let's figure out how it should work instead of trying to fix issues that will be obsoleted out.
Quote
Been procrastinating a bit regarding Wedge lately...
You are allowed to have a break, you know :)
Quote
No error.
It was down to how the select handling worked, I've since made a change to Subs-Menu that deals with these cases, though repairboards is the only case of it.
Title: Re: New revs - Public comments
Post by: Nao on October 6th, 2011, 05:39 PM
Quote from Arantor on October 6th, 2011, 03:05 PM
Works for me.
Done...
Also converted the floor((int) x/2) to just x>>1, which does exactly the same thing... Only faster :D
It's funny that SMF's version of the conversion is even more complicated, something like ((int) x - ((int) x % 2)) / 2... Lol.
Quote
On the one hand I see the wisdom of this, and on the other, I find I'm not actually that bothered by setting it.
I think we renamed a few 'important' things in the past... Can't remember which, though. Well, I guess our users will tell us in time ;)
Quote
Then let's figure out how it should work instead of trying to fix issues that will be obsoleted out.
We should probably get started on removing the bin right now...
Quote
You are allowed to have a break, you know :)
I'm not sure about that... My schedule... It's... Oh well, I guess we can screw my schedule...
Quote
It was down to how the select handling worked, I've since made a change to Subs-Menu that deals with these cases, though repairboards is the only case of it.
Are we talking about the same thing...? The empty skeleton error?
Title: Re: New revs - Public comments
Post by: Arantor on October 6th, 2011, 05:50 PM
Quote
We should probably get started on removing the bin right now...
That's cool, provided that we come up with a functional replacement.
Quote
Are we talking about the same thing...? The empty skeleton error?
I didn't get into the error in recycling topics, I didn't see a lot of point, but I did look into the other error that was mentioned at the same time in repairboards.
Title: Re: New revs - Public comments
Post by: Nao on October 6th, 2011, 06:53 PM
Quote from Arantor on October 6th, 2011, 05:50 PM
Quote
We should probably get started on removing the bin right now...
That's cool, provided that we come up with a functional replacement.
The ''approved' bit...? Setting it to '2' for future posting (or whatever), and '3' for 'deleted'...? Isn't it enough?
We could simply rename it to 'status', 'state' or 'online'... (Well, that would be something we need to correctly import from SMF... ;))
Posted: October 6th, 2011, 06:52 PM
Quote from Arantor on October 6th, 2011, 05:50 PM
I didn't get into the error in recycling topics, I didn't see a lot of point, but I did look into the other error that was mentioned at the same time in repairboards.
But I suspect we'll be getting more of this 'empty skeleton' error where we expect it the least... Maybe I should give up on that 'feature'.
Title: Re: New revs - Public comments
Post by: Arantor on October 6th, 2011, 07:46 PM
I'm not so bothered by the physical status part, though that is ultimately the way to do it. What concerns me is how we show the user. How do we display it?

I'd also prefer to separate deleted-by-author from deleted-by-moderator.

As far as empty-skeleton errors, that implies a logic error, and if there isn't a fatal error shown to the user, what would happen? I'd argue that a page with no content is less helpful than a page with an error message.
Title: Re: New revs - Public comments
Post by: Nao on October 7th, 2011, 07:07 PM
I think you could have guessed I was planning to split the Display template into several functions just like I did for the index template... But the good news is that you did it in a very clean way and I couldn't have done it better so it's all good :) (Maybe I would have removed the spellchecker though... I'm not exactly sure how useful it is in these days when most browsers have inline spellchecking.)

(Plus, I'm having such a hard time working on Wedge these days...)
Quote from Arantor on October 6th, 2011, 07:46 PM
I'm not so bothered by the physical status part, though that is ultimately the way to do it. What concerns me is how we show the user. How do we display it?
It's the easy part to me... :^^;:
Quote
I'd also prefer to separate deleted-by-author from deleted-by-moderator.
Sure. The 'approved' field can really have any value at this point... As long as the only valid value for showing a post is '1'...
I've started work on it, BTW. Although I'm currently trying to determine whether I should keep it as 'approved' or use the opportunity to rename it to 'status'.
Quote
As far as empty-skeleton errors, that implies a logic error, and if there isn't a fatal error shown to the user, what would happen? I'd argue that a page with no content is less helpful than a page with an error message.
Possibly. But maybe we should also log the contents of the empty skeleton for admins to look into...
Posted: October 7th, 2011, 04:28 PM
Quote from Arantor on October 7th, 2011, 11:14 AM
@ Nao: Something in my brain told me not to make the title_upper and _lower parts (which are used for the page titles/go up+down areas) into a template layer but I'm not sure *why* my brain told me that. If you wanna change it, please go right ahead.
I have absolutely no idea why this shouldn't be done... I'll be working on it. It's not like it can't be reverted...
Posted: October 7th, 2011, 04:32 PM

Oh, and one thing that could be improved... Testing for some values and, if they're not true, either don't add the corresponding block, and simply removeBlock() it... (Well, the problem with the second solution is that when we start using an object for this, it'll be a tad slower than just unsetting the block in the skeleton array...)

What do you think of this?

Another possible improvement: allow for params to be passed to template functions. Something like, loadBlock('mod_buttons', 'upper'), with 'upper' being passed to the template function so that it knows what to show.
Posted: October 7th, 2011, 04:37 PM

Having trouble with the postlist (i.e. topic posts) layer...
So, if I want to load the layer into default, surrounded by blocks, I have to do it this way...

Code: [Select]
loadBlock(
array(
'report_success',
'display_draft',
'title_upper',
'topic_poll',
'linked_calendar',
)
);
loadLayer('postlist', 'default', 'child');
loadBlock('display_posts', 'postlist');
loadBlock(
array(
'quick_access',
'mod_buttons',
'quick_reply'
),
'',
'add'
);

I'd say it's pretty ugly.
Other solutions:
- add the ability to specify layers directly within the block list, by specifying a sub-array, and possibly other blocks inside the array.
- just forget about it...
- add the layer after the main block code, and add to loadLayer() the ability to inject a layer before or after a *block*, just like loadBlock offers the ability to inject a block before or after a block or a layer. This is my favorite solution (I like the second one equally, though... :^^;:), but it may make the code even more confusing... (?)

Opinions?
Title: Re: New revs - Public comments
Post by: Arantor on October 7th, 2011, 09:03 PM
There is, of course, an ulterior motive for breaking the template up - injecting the calendar into its original place, from a plugin perspective.

I've been debating removing the spell checker. It's not unreliable but it is a bit fiddly to set up, and with it being on the client side (which will likely have the user's word customisations in, and so on) it seems less worth including.

I'd take the opportunity to rename it. Question: what happens with an unapproved post that then gets deleted?

Logging the empty skeleton is only useful if you can log the circumstances that got you there...

Ah, yes, that was my reason: I couldn't figure out a way to load the block/layer list in a single statement. As for loading things/not loading things in the block list, I couldn't figure out whether it would be cheaper to load everything and exit per template if we weren't doing anything, or load the list and remove items if we weren't going to use them, or only add them if we were going to (but in my head, adding an item is probably slightly more expensive than adding a single big list and exiting the function)

I don't think there is a good right way to do it...
Title: Re: New revs - Public comments
Post by: live627 on October 8th, 2011, 09:43 AM
Warning: Invalid argument supplied for foreach() in /wedge/Sources/Subs-Cache.php on line 452

Litespeed, PHP 5.3.6, and XCache
Posted: October 8th, 2011, 08:46 AM

I haven't the faintest on how that cache works, but from the error;'s behavior, it seems that when it creates a new file it spits that out since I only get it on pages I didn't yet visit.

JS is minified with Packer and compressed JS/CSS is disabled, also filename obfuscation is off. This is on a new install.

Also, the installer's CSS style seems broken when I ran it this evening.
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2011, 10:14 AM
Will have a look.

Installer -- I rarely run it. I suppose it's linked to the caching error.
Title: Re: New revs - Public comments
Post by: TE on October 9th, 2011, 08:37 AM
just a small bug report:
Security.php line 419 starts with:
Quote
fatal_lang_error('your_ban'], 'user'...
the closing  bracket needs to be removed:
Quote
fatal_lang_error('your_ban', 'user'...
Edit: found another one:
Admin Area - side bar:
Code: [Select]
Warning: strpos() [function.strpos]: Empty delimiter in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wedge\trunk\Sources\Errors.php on line 98

btw, how to enable or disable "Core Features"? I had disabled the gallery a while ago and now I cant find an option to enable the gallery again.. Maybe I'm blind but the "Core features" don't allow me to enable / disable a feature...
Title: Re: New revs - Public comments
Post by: Nao on October 9th, 2011, 11:28 AM
Quote from TE on October 9th, 2011, 08:37 AM
just a small bug report:
Security.php line 419 starts with:
Thanks, fixed for Security... As for Errors, I can add an extra test, but are you sure you updated your local copy's Settings.php file? I know I didn't, originally, so $pluginsdir was empty...

I'm currently going through Pete's commits. 2000 more lines to go... Known song, this week :lol:
Unfortunately I can't devote a lot of time to Wedge this week. RL stuff :(
Quote
btw, how to enable or disable "Core Features"? I had disabled the gallery a while ago and now I cant find an option to enable the gallery again.. Maybe I'm blind but the "Core features" don't allow me to enable / disable a feature...
I don't believe the feature is buggy, but OTOH, Pete is adamant on deleting that page IIRC, so it'll end up being somewhere else.

If you want to re-enable it manually, that's in $modSettings/wedge_settings ;)
Posted: October 9th, 2011, 10:46 AM

Oh... And did you see the question for you above? (reply #183)
Posted: October 9th, 2011, 10:52 AM

(Found another syntax error in Activate.php, will fix in the next commit.)
Posted: October 9th, 2011, 11:21 AM

Pete -- there are so FEW fatal_error() calls left, I think it'd make sense to actually rename them to fatal_error_hardcoded() or something (who cares), and rename fatal_lang_error() to fatal_error()...
Posted: October 9th, 2011, 11:23 AM

Also, there are some places where the fatal error gets a 'user' value to it when the original was either false or 'general' (or empty, = 'general'). They're in Aeva-Gallery.php and Reminder.php:

-               fatal_error(sprintf($txt['media_cf_empty'], $field['name']));
+               fatal_lang_error('media_cf_empty', 'user', array($field['name']));

Any reason, Pete?
Title: Re: New revs - Public comments
Post by: TE on October 9th, 2011, 12:37 PM
Quote from Nao on October 6th, 2011, 02:58 PM
Similarly, every time we change the name of an SMF variable (from $modSettings and $settings, I mean), we should ensure it's also reflected in the import tool.

Thorsten, do you keep track of these...?
Haven't checked yet, but shouldn't be a big problem..
Title: Re: New revs - Public comments
Post by: Arantor on October 9th, 2011, 12:38 PM
With the changes to user, I had to specify a parameter (error type is param 2, sprintf vars is parameter 3). Where the type was specified I was fairly sure I'd got it right and where it wasn't specified (and thus it would be logged as general), I changed it, at the time it seemed more logical to flag it as a user error rather than a general error. It's not a general error in processing, it's because the user has done something wrong - and that to me makes more sense to flag as a user error.

Yes, Core Features is buggy and has been for some time due to an extra hide class in the template but as Nao says I'm looking to do away with it in due course so it's not like I've been worried about fixing it.

And I thought I'd fixed all the brackets but I guess I missed a couple :(
Title: Re: New revs - Public comments
Post by: Nao on October 9th, 2011, 01:37 PM
Pete, did you actually translate the new English strings to French? :lol:
Did you use a tool, or your own memories of the French language?

Well it's not perfect but I find it endearing to see you try ;)
Quote from Arantor on October 9th, 2011, 12:38 PM
With the changes to user, I had to specify a parameter (error type is param 2, sprintf vars is parameter 3). Where the type was specified I was fairly sure I'd got it right and where it wasn't specified (and thus it would be logged as general), I changed it, at the time it seemed more logical to flag it as a user error rather than a general error. It's not a general error in processing, it's because the user has done something wrong - and that to me makes more sense to flag as a user error.
If that's not an oversight, then that's fine with me ;)
Posted: October 9th, 2011, 12:58 PM

(Bump!)
Quote from Nao on October 9th, 2011, 11:28 AM
Pete -- there are so FEW fatal_error() calls left, I think it'd make sense to actually rename them to fatal_error_hardcoded() or something (who cares), and rename fatal_lang_error() to fatal_error()...
Posted: October 9th, 2011, 01:09 PM

In fatal_lang_error, we have this at some point:

   updateOnlineWithError($error, true, $sprintf);

At this point, $error is still the key to the $txt string, not the string itself. I'm changing this to $txt[$error], is it okay? (I suppose you're more acquainted to the Errors.php file than I am right now.)

Also, maybe we could simply remove fatal_error() and use the fatal_lang_error codepath all the time... I mean, if $txt[$error] isn't set, it simply shows $error... In both situations. (Well, it'd need some tweaking in fatal_lang_error though.)
Posted: October 9th, 2011, 01:20 PM

Any reason for removing the (strpos($str, '%p') !== false) test in Subs.php? (Not that I mind... :P)

Phew, only 600 lines left to check and I'll be 100% up to date with the newest rev... Yippie!
Posted: October 9th, 2011, 01:23 PM

index.language.php has:

$txt['merge_confirm'] = 'Are you sure you want to merge';
$txt['with'] = 'with';

I suspect the two are mixed together... And anyway, I couldn't find 'merge_confirm' used anywhere else. There's not even a single 'confirm' in SplitTopics.template.php... :-/
I'd remove these immediately (index language, hey! Waste of time!), but... $txt['with'] might be seen as 'important' for modders. So I'm at least asking whether there are objections to me deleting these ;)
Title: Re: New revs - Public comments
Post by: Arantor on October 9th, 2011, 02:06 PM
I used a mix of my own memory and Google Translate when my memory failed me. I knew it probably wasn't perfect but I figured I'd give it a shot, and while I haven't had time to check the fixed translation, I'm willing to bet that not having 'here' in a separate string (for example) allows for better translation.

No, it shouldn't be $txt[$error] passed to the update counter, it should be the $error on its own - the second parameter indicates where it came from, false for fatal_error, true for fatal_lang_error, because it deliberately doesn't stuff the entire message into the online table if it doesn't have to.

The removal of the %p test in Subs... At the time I concluded it was redundant; the only language that I'm aware of that uses AM/PM in a 12-hour context is English, and I don't know any other language that prefers a 12 hour context over a 24 hour one. I can reinstate it but frankly I'd rather push English to 24 hour before I supported 12 hour more...

Where else is $txt['with'] used? If it's not used anywhere, remove it. Also check for merge_ on its own, strings get compounded a lot in the code.
Title: Re: New revs - Public comments
Post by: Nao on October 9th, 2011, 02:17 PM
Okay, I'm finished with the review... Well, not completely, but I have committable material.
It's going to be a relatively big one, and I have to go for now, I hope to have it up and running within an hour.
Quote from Arantor on October 9th, 2011, 02:06 PM
I used a mix of my own memory and Google Translate when my memory failed me. I knew it probably wasn't perfect but I figured I'd give it a shot, and while I haven't had time to check the fixed translation, I'm willing to bet that not having 'here' in a separate string (for example) allows for better translation.
Definitely (although in French, it's not going to change anything.)
I also merged two strings for the same reason ('not_removed' error string.) Next commit.
Quote
No, it shouldn't be $txt[$error] passed to the update counter, it should be the $error on its own - the second parameter indicates where it came from, false for fatal_error, true for fatal_lang_error, because it deliberately doesn't stuff the entire message into the online table if it doesn't have to.
Okay, to save space... Good to know. As long as it's decoded back into $txt[$error] on the other side of the log viewing code... ;)
Still, what do you think of merging them?
Quote
The removal of the %p test in Subs... At the time I concluded it was redundant; the only language that I'm aware of that uses AM/PM in a 12-hour context is English, and I don't know any other language that prefers a 12 hour context over a 24 hour one.
I don't know either but I'm no specialist... Actually, in France, orally we use "5pm/5 o'clock" a lot, just like you British lot will say "teatime", we'll say "le quatre heures" (the 4pm). i.e. what we eat at teatime.
Now, with that said -- it's only oral, rarely written, because we don't have "pm" or "am", so we'll write "il est 20h" but we'll often say "il est 8h" and depending on the day time, it'll obviously mean 8h du matin (8am) or 8h du soir (8pm). There are also people, like me, who have a problem using *anything* else than military time. This morning, my girlfriend asked me for the time. I said "il est 11 heures 45". She replied, "why don't you just say midi moins le quart ?" (midi moins le quart = a quarter to noon.) I guess that's a problem with me mainly... Or because we geeks like to be precise. So the 2400 format is a blessing.
Quote
I can reinstate it but frankly I'd rather push English to 24 hour before I supported 12 hour more...
Do... Do you mean you actually removed support for am/pm entirely?! Really? (I like the idea... It's quite bold :lol:)
Quote
Where else is $txt['with'] used?
Nowhere...
Quote
If it's not used anywhere, remove it. Also check for merge_ on its own, strings get compounded a lot in the code.
I know, with strings like _desc or _info you have to be careful... But I just couldn't find anywhere the confirmation code for merging topics.
Title: Re: New revs - Public comments
Post by: Arantor on October 9th, 2011, 02:28 PM
Quote
As long as it's decoded back into $txt[$error] on the other side of the log viewing code...
The log itself doesn't make use of it. The point is to log the error into the users online log, so if a user hits a fatal error while trying to do something (ostensibly something they shouldn't), admins will be able to see that error from Who's Online.

So, if a user tries to read a topic they can't access, the usual "Reading <topic>" will appear in Who's Online, with a little warning icon whose tooltip is the error. It was the cleanest way I could think of to solve the problem of "hey, I think my forum is broken, users can see topics in private boards" because when it looks up the list, it only looks at what the user is requesting, not whether the user has permission.

I don't really have a problem with merging them, provided that we don't break anything else.
Quote
I don't know either but I'm no specialist.
Remember that AM/PM support was very late in the day, not only as a fix but as a report. It can't be that big a problem. It would be interesting to see what languages actually have updated $txt['am'] and $txt['pm'].
Quote
Really?
Support is very limited. All it does is search for %p, work out whether it's AM or PM and substitute in the relevant $txt item. Since I removed the $txt items and the test... it is all gone. Basically it just brings us back to around 2.0 RC4 - but the language itself now dictates what format to use, rather than a language independent version set by the admin.
Quote
Nowhere...
Kill it. If it isn't being used, get rid of it, pure and simple.
Quote
But I just couldn't find...
Yeah, there are a lot of funny strings, often unexpectedly not clearly being mashed together, but that needs to be straightened out. There is, in fact, a bug report about this sort of thing in SMF where the board index has a big fact composite string that's wrong in just about every language other than English.
Title: Re: New revs - Public comments
Post by: Nao on October 12th, 2011, 04:25 PM
Regarding the latest few commits... Wouldn't it make sense to have a function like, 'complex_string', whose purpose would be to do the common string replacements? (boardurl, scripturl...)
It wouldn't be as fast, though. But from the moment you implemented {variables}, I suppose it mattered less than having a non-dynamic list of text strings.
Quote from Arantor on October 9th, 2011, 02:28 PM
Remember that AM/PM support was very late in the day, not only as a fix but as a report. It can't be that big a problem. It would be interesting to see what languages actually have updated $txt['am'] and $txt['pm'].
I totally forgot that this was recent, indeed...
I don't even know why people would need to translate this, meh.

Oh, and so... What about this %Y problem?
We *could* do it in a complicated way, such as {, %Y} where everything between {} would be removed if %Y is empty, but we'd need to apply this to all occurrences, which isn't cool... (Well, of course we could simply integrate the removal in the same code that gets rid of %Y in the first place.)

$show_today = str_replace(' %Y', '', $user_info['time_format']);

->

$show_today = preg_replace('~,? %Y~', '', $user_info['time_format']);
or
$show_today = str_replace(array(', %Y', ' %Y'), '', $user_info['time_format']);

(The second one is faster. strtr() has similar performance, can be 10%-20% faster or slower, totally randomly.)

Or simply remove the comma entirely..?
I really like not having the year when it's a recent post... It's halfway between hardcoded and dynamic dates. And it saves precious space.
Quote
Support is very limited. All it does is search for %p, work out whether it's AM or PM and substitute in the relevant $txt item. Since I removed the $txt items and the test... it is all gone. Basically it just brings us back to around 2.0 RC4 - but the language itself now dictates what format to use, rather than a language independent version set by the admin.
Definitely better...
Quote
Quote
Nowhere...
Kill it. If it isn't being used, get rid of it, pure and simple.
We could also kill $txt['by']... Either do $txt['by_person'] = 'by %1$s', or a series of more strings that would allow for 'by <strong>%1$s</strong>', etc...
Dunno.
It's just that in Japanese, the 'by' is usually shown after the name. But I think it can be put before the name as well, if needed. It just doesn't feel as natural. (And yeah, I know, even SMF doesn't have a Japanese version... But Kyôdai Mahjongg does :P)
Title: Re: New revs - Public comments
Post by: Arantor on October 12th, 2011, 04:36 PM
Quote
Regarding the latest few commits... Wouldn't it make sense to have a function like, 'complex_string', whose purpose would be to do the common string replacements? (boardurl, scripturl...)
It would indeed be slower, though I'd suspect it would be much more convenient to use something like <we:script> and replace it in the buffer at the end. It would certainly avoid juggling the variable about so much.

For other stuff like $boardurl, I wouldn't bother, it's just not used enough. But for $scripturl, there is a practical convenience vs performance decision to be made.
Quote
I totally forgot that this was recent, indeed...
I don't even know why people would need to translate this, meh.
It's not so much that some people need to translate it, it's more than some languages simply have no concept of am/pm, and use 24 hour systems instead. In fact, I think it is a peculiarity of English the more I read up on it.
Quote
Or simply remove the comma entirely..?
I really like not having the year when it's a recent post... It's halfway between hardcoded and dynamic dates. And it saves precious space.
Hmm, I'm not actually that fussed personally. I'd say that whatever is reliably going to strip it without leaving too much fluff is fine.
Quote
We could also kill $txt['by']
I want to. I just haven't gotten round to it yet because it's used in a lot of places, just as $txt['in'], $txt['on'] and similar joining clauses are. I'd rather strip them all and use properly constructed phrases, even if it is slower.
Quote
t's just that in Japanese, the 'by' is usually shown after the name. But I think it can be put before the name as well, if needed. It just doesn't feel as natural. (And yeah, I know, even SMF doesn't have a Japanese version... But Kyôdai Mahjongg does
http://download.simplemachines.org/?smflanguages disagrees with you.

What would really help is if I could talk to people who know more languages; ideally I'd like to speak to people who know Chinese, Russian and Arabic. While I'm aware it's a gross simplification, Japanese, Chinese, Russian and Arabic between them hit up all the key problems in the language files.

Internationalisation is an incredibly complex art, and if I'm honest it's not one I'm that familiar with, but I'd like to think that my gut instinct on the practicalities of it are serving Wedge well.

For example, I'm aware of the whole use of : in strings in the admin panel and other places. My gut instinct tells me that they should be in the language file, not the template, because from my understanding of RTL and the way it's currently handled, you'd risk ending up with <setting> <string>: rather than the more correct <setting> :<string>. But I don't know any RTL languages, my knowledge of French is limited and rusty, my knowledge of other languages even more so (but it's enough to recognise that the constructions used currently do not work consistently outside English)
Title: Re: New revs - Public comments
Post by: Nao on October 12th, 2011, 09:13 PM
Quote from Arantor on October 12th, 2011, 04:36 PM
It would indeed be slower, though I'd suspect it would be much more convenient to use something like <we:script> and replace it in the buffer at the end. It would certainly avoid juggling the variable about so much.
I don't know... We'd only need to call complex_string on strings that we KNOW to have variables in them. In effect, it doesn't represent a lot of strings. Thus, calling a preg_replace on every page will probably eat more time than this, I'd think. Although a page-wide buffer could OTOH allow us to use {scripturl} directly in strings in the template, and thus save us from globalling it... Dunno, it could warrant some performance tests.
Quote
It's not so much that some people need to translate it, it's more than some languages simply have no concept of am/pm, and use 24 hour systems instead. In fact, I think it is a peculiarity of English the more I read up on it.
According to Wikipedia, English isn't the only one, and Greece has strings for it (π.µ. and µ.µ.). In the Philippines, one of the local languages has 'sb' and 'sg'. Japanese has its own -- gozen/a.m. 午前 and gogo/p.m 午後, but they're shown before the hour, not after. Same for Chinese. Heck, IIRC Japanese even has additional words like 'deep night'...
http://en.wikipedia.org/wiki/12-hour_clock
I'd tend to say that it's up to the server to translate that to the current locale.
Quote
Hmm, I'm not actually that fussed personally. I'd say that whatever is reliably going to strip it without leaving too much fluff is fine.
I can only think of one solution... Introduce a $txt['time_format_this_year'], with the simplified time format, and use it accordingly in timeformat() when required.
I'll be working on that...
Quote
http://download.simplemachines.org/?smflanguages disagrees with you.
I'm surprised... I didn't remember anything about that. I've been on many, many Japanese forums. A large majority uses 2ch-derived crap. A small minority uses Western forum boards, mostly vBulletin IIRC. I have yet to see a single Japanese forum using SMF. And I do mean a forum in Japanese, maintained by Japanese people.
Quote
What would really help is if I could talk to people who know more languages; ideally I'd like to speak to people who know Chinese, Russian and Arabic. While I'm aware it's a gross simplification, Japanese, Chinese, Russian and Arabic between them hit up all the key problems in the language files.
Well, my knowledge of Japanese (not fluent but I can read it just fine) would definitely be helpful here, when it comes to modifying our code so that it helps the Japanese version feel more natural.
Quote
Internationalisation is an incredibly complex art,
...And normally the job of an internationalizer. But apparently, at SMF, that job consists in making sure that the various language packs are returned in time... It doesn't even require speaking English correctly. :P
I speak French and English. I have a good knowledge of Japanese and Spanish. I can read some Italian (well, didn't learn it, but it's not very hard for a French :P). That's all I can say about myself. I'm a bit old to be learning any other language ;) Oh yes, I read a bit of Chinese, too. But that's only because common traditional hanzi and kanji are identical... Wo bu shi zhongguoren.
Quote
For example, I'm aware of the whole use of : in strings in the admin panel and other places. My gut instinct tells me that they should be in the language file, not the template, because from my understanding of RTL and the way it's currently handled, you'd risk ending up with <setting> <string>: rather than the more correct <setting> :<string>. But I don't know any RTL languages, my knowledge of French is limited and rusty, my knowledge of other languages even more so (but it's enough to recognise that the constructions used currently do not work consistently outside English)
Hmm... I don't know any RTL language so I can't really speak on this matter.
Additionally, I haven't tested Wedge in RTL mode for a VERY long time... :-/
Title: Re: New revs - Public comments
Post by: Arantor on October 12th, 2011, 09:33 PM
Quote
We'd only need to call complex_string on strings that we KNOW to have variables in them. In effect, it doesn't represent a lot of strings.
$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.

Things like boardurl are rare enough that you can just do a str_replace as needed; no need to wrap it in a special function.

But it doesn't require a page wide regex, just a page wide str_replace as it's constant and source level.
Quote
I'd tend to say that it's up to the server to translate that to the current locale
Yup. I seem to recall setting up a setlocale call for that purpose, assuming LC_TIME or LC_ALL is still passed. Again this is something I'd like more input because I don't know about other languages and cultures.


Oh, and last I heard, the i18n team is now called Localizers, which isn't really much better, and while I do remember debates about languages, I don't remember much strong debate about how to practically approach these matters, almost as if they were just accepted as faults that weren't going to be fixed. IIRC, the only reason the AM/PM thing happened was because a real[1] team member kicked up a fuss.


Lastly, I wouldn't worry about RTL too much at this time.
 1. The Internationalizers/Localizers have never been considered a real team, even if some tried to treat them as valuable equals. In all honesty I think Akyhne has more power as a consulting dev than he did as Lead Internationalizers.
Title: Re: New revs - Public comments
Post by: stackmouse on October 12th, 2011, 10:01 PM
Translating software into Finnish can be a major pain in the a**, mostly because of the fusional nature of the language. If the software uses a single word in several different places the translation might be a bit problematic.

Simple example: the words "your", "users" and "password" are defined separately in language files. If you translate the words into Finnish as they would be used in a phrase "your password", the output is a bit different than what a phrase "users password" would require.

Your password = Sinun salasanasi (or you can just use "Salasanasi", as the -si ending here says it already)
Users password = Käyttäjän salasana (no ending used for the password, or "salasana")

This is problem only if the language items are broken into small pieces. If the items in the language files are full phrases or their use is limited to singular places, the translation can be exact (or at least appear to be decent).

Anyway... I offer myself as volunteer for the Finnish localisation effort when the time comes for that line of work.
Title: Re: New revs - Public comments
Post by: Nao on October 12th, 2011, 10:39 PM
@stackmouse> I remember when I had to ask the SMF team for a $txt['reply_noun'] as opposed to just $txt['reply'] because they used the same string both as a verb and a noun ('reply number 1' / 'reply to this message'), even when most languages don't use the same word for both...
Quote from Arantor on October 12th, 2011, 09:33 PM
$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.
Well, then we could consider doing that str_replace on the buffer yeah, I guess...
Posted: October 12th, 2011, 10:17 PM

Okay, did it... I'm a bit disappointed by the low number of replacements this saves us from doing. It's mostly stuff in the Who language files (determineAction)... But it's so fast to do (I think a hundredth of a millisecond), it's not worth worrying about -- especially since there'll ALWAYS be a {scripturl} to replace, given that they're being used in the main macros.
Posted: October 12th, 2011, 10:35 PM

Oh, and maybe we could also use that for the quote tag. If you look into install.sql, {{scripturl}} is being used, and then replaced in Subs-BBC.php with $scripturl.

And now I just realized a problem...
What if users actually type {scripturl} in their posts...?!?!

(Good thing I committed this as a stand-alone commit, so that we can easily revert it...)
Title: Re: New revs - Public comments
Post by: Arantor on October 12th, 2011, 10:50 PM
@stackmouse, this is exactly we've done work on it lately, compounded strings are workable in English but no other language.

@Nao, that's why I suggested doing it with a <we> variable ;) it won't ever be used in posts directly.

But if it's a global replace, you can replace any instance of scripturl throughout the entire source, except for its definition in QueryString, and the actual replace itself.
Title: Re: New revs - Public comments
Post by: Nao on October 12th, 2011, 11:28 PM
Quote from Arantor on October 12th, 2011, 10:50 PM
@Nao, that's why I suggested doing it with a <we> variable ;) it won't ever be used in posts directly.
Why not..?
Do you think {scripturl} is likelier to be used in a post? Well, if it's used, it's only to explain users what it's for, or post code samples etc... <we:script> would be in the same situation, wouldn't it? (Also, it would be caught by the macro replacement code AFAIK...)
Quote
But if it's a global replace, you can replace any instance of scripturl throughout the entire source, except for its definition in QueryString, and the actual replace itself.
QueryString....?
Title: Re: New revs - Public comments
Post by: Arantor on October 13th, 2011, 12:08 AM
Quote
Why not..?
Do you think {scripturl} is likelier to be used in a post? Well, if it's used, it's only to explain users what it's for, or post code samples etc... <we:script> would be in the same situation, wouldn't it? (Also, it would be caught by the macro replacement code AFAIK...)
It's likely to be used if someone posts code. <we:*> on the other hand won't be caught by the replace filter because it'll have been converted to entities and thus the raw form is never exposed to the replacer.
Quote
QueryString....?
Isn't QueryString.php where $scripturl is first defined?
Title: Re: New revs - Public comments
Post by: Nao on October 13th, 2011, 12:13 AM
Ah yes. Entities.

As for replacing -- we have to do it before pretty urls are done (forgot that) so I'll have to move that code down the page.
Title: Re: New revs - Public comments
Post by: Nao on October 13th, 2011, 12:14 AM
Btw context isn't globaled in the Who code. Error log. Fixed locally.
Title: Re: New revs - Public comments
Post by: live627 on October 15th, 2011, 06:50 AM
Notice: Undefined index: scripturl in J:\Backups\Linux Drive\www\wedge\trunk\Sources\Subs-BBC.php(133) : regexp code on line 1
Title: Re: New revs - Public comments
Post by: Nao on October 15th, 2011, 09:03 AM
That's because you didn't update your wedge_bbcode table ;)
Title: Re: New revs - Public comments
Post by: TE on October 15th, 2011, 09:25 AM
Just another small bug report (ipv6 related):
install.sql
Code: [Select]
poster_ip int(10) NOT NULL default '0',
needs to be changed to
Code: [Select]
poster_ip varchar(32) NOT NULL default '',
Title: Re: New revs - Public comments
Post by: Arantor on October 15th, 2011, 12:49 PM
No it doesn't.

For places like that where there are likely a lot of duplicates, they were turned into pointers to the log_ips table. Even if we end up making it a 64 bit value (for 2^64 *unique addresses per site*) that's still a quarter of the space used.
Title: Re: New revs - Public comments
Post by: TE on October 15th, 2011, 02:33 PM
ok, thanks.. I believe I should have studied the code a little bit more.. :whistle:
/meneeds to fix the importer files..
Title: Re: New revs - Public comments
Post by: Arantor on October 15th, 2011, 05:47 PM
Yeah, that's a slightly odd thing to have done but it seemed the most logical way of proceeding to cope with storing IP addresses per post.
Title: Re: New revs - Public comments
Post by: TE on October 16th, 2011, 08:40 AM
Related to OpenID, there is still a "bug" in QueryString.php (problems with some german webmail providers)

http://dev.simplemachines.org/mantis/view.php?id=2669#c12080
the bug was re-introduced in SMF 2.0 RC5. Now, with OpenID  dropped from the code, we could fix it..
Title: Re: New revs - Public comments
Post by: Nao on October 16th, 2011, 10:38 AM
Lol... Yes, you do care about this bug ;)
Sorry, I committed my own stack of things before I read your post :(

I'll leave it up to Pete to fix it, I have to go. Late breakfast! I love Sunday mornings.

PS: I also removed openid_uri from the members table. I'm telling you guys because it may not be something people would want to remove in the first place, at least at import time...
Title: Re: New revs - Public comments
Post by: Arantor on October 16th, 2011, 12:59 PM
I did see that, wasn't sure of the background in respect to fixing it or not, so I left it as is. As for the openid_uri column, I just forgot that.

Didn't touch detailed_version because it's quite a bit out of date and I figured we'd fix it closer to release.
Title: Re: New revs - Public comments
Post by: TE on October 17th, 2011, 07:21 AM
Quote from Nao on October 16th, 2011, 10:38 AM
Lol... Yes, you do care about this bug ;)
Yes, I do.. GMX has taken over the domain mail.com last year, thus not only germans will be affected..
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 07:47 AM
I had a busy weekend. I'll look into it today.
Title: Re: New revs - Public comments
Post by: Arantor on October 17th, 2011, 08:53 AM
I already fixed it locally going by the code in the bug report.
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 12:22 PM
I believe there are a few items remaining from the OpenID code... Not a lot really. Just a few lines.
Just search for 'authenticate' (single word) and 'auth_method'. Because the authentication method is only 'password' now, the variable is useless.
As always, I would remove it myself but it may serve as a future hook point to plug OpenID and Facebook into the system so I'm leaving up to you to decide whether to remove these or not, Pete.

On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
(I've already transformed all three set types.)

Code: [Select]
if ($set == 'normal')
{
$select_columns = array(
'IFNULL(lo.log_time, 0) AS is_online', 'IFNULL(a.id_attach, 0) AS id_attach', 'a.filename', 'a.attachment_type',
'mem.signature', 'mem.personal_text', 'mem.location', 'mem.gender', 'mem.avatar', 'mem.id_member', 'mem.member_name',
'mem.real_name', 'mem.email_address', 'mem.hide_email', 'mem.date_registered', 'mem.website_title', 'mem.website_url',
'mem.birthdate', 'mem.member_ip', 'mem.member_ip2', 'mem.posts', 'mem.last_login', 'mem.id_post_group', 'mem.lngfile',
'mem.id_group', 'mem.time_offset', 'mem.show_online', 'mem.media_items', 'mem.media_comments', 'mem.buddy_list', 'mem.warning',
'mg.online_color AS member_group_color', 'IFNULL(mg.group_name, {string:blank}) AS member_group',
'pg.online_color AS post_group_color', 'IFNULL(pg.group_name, {string:blank}) AS post_group', 'mem.is_activated',
'CASE WHEN mem.id_group = 0 OR mg.stars = {string:blank} THEN pg.stars ELSE mg.stars END AS stars'
);
if (!empty($modSettings['titlesEnable']))
$select_columns[] = 'mem.usertitle';
$select_tables = array(
'LEFT JOIN {db_prefix}log_online AS lo ON (lo.id_member = mem.id_member)',
'LEFT JOIN {db_prefix}attachments AS a ON (a.id_member = mem.id_member)',
'LEFT JOIN {db_prefix}membergroups AS pg ON (pg.id_group = mem.id_post_group)',
'LEFT JOIN {db_prefix}membergroups AS mg ON (mg.id_group = mem.id_group)'
);
}

Then we just need to add a hook passing $select_columns and $select_tables as parameters and voilà, we have an often modified area that becomes very easy to hook into.
(Obviously, the code is adapted to fit the array format.)
Right after the set building, I added this hook:

call_hook('load_member_data', array($set, &$select_columns, &$select_tables, &$users, &$is_name));

The performance difference is barely noticeable even with benchmarking -- about 5 to 10% slower on a code block that takes less than a millisecond to execute, MySQL call included... So it would make sense to make it easier to modify.

I've added the hook to the ManagePlugins array as well.
Just wanna know if everything's in order... If you don't like it, please tell me so that I revert these changes before my next commit ;)
Posted: October 17th, 2011, 11:32 AM

Oh, I'm also considering adding a 'process_member_data' hook AFTER the query, but my main problem is that I don't know WHERE exactly to put it... Right after the query? Right before the final 'return'? Somewhere in between...? Suggestions welcome!
Posted: October 17th, 2011, 11:40 AM

One other thing I'm looking into is loadMemberContext()... It's really heavy.
Moreover, it crams pretty much everything it can into the various arrays, but it's not always used.
For instance, Memberlist calls it for every single name in the list, but it only shows a subset of the data.
Okay, I can live with that... I can live with the multiple calls to censorText and other preg_replaces.
But I have a hard time with the signature parsing.
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!

And while we're at it -- I think it'd make sense to also have a param saying whether we want the member link to use group colors. They're not used in many areas and I'm not sure why. Actually, it could even make sense to always use the group colors. They're loaded at this point... Even in the topic pages it would make sense to show group colors (although I'm not sure about that.)
Posted: October 17th, 2011, 11:56 AM

More things to get rid of...

- $txt['profile_of'] is used in things like $memberContext as a title. I'd rather have it say just 'View profile' than 'View profile of...' followed by a name that is *already* in the link... Totally silly. Plus, we already have $txt['profile_of_username'] which is correctly handled by a more logical sprintf.
Opinions?

- $txt['time_am'] and $txt['time_pm']... They were removed in rev 1071, but they're actually still being used in timeformat()...! They were used twice in the function, and only one occurrence got removed. It doesn't generate an error because it's only being called when $non_twelve_hour is set to true, i.e. the server doesn't support the '%p' parameter in time formatting. I'd suggest simply replacing them with 'am' and 'pm'... (Note, though: %p will usually use AM and PM, in uppercase. I don't know which is the better one. I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
Posted: October 17th, 2011, 12:15 PM

I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])

Code: [Select]
if ($then['year'] == $now['year'])
{
if (!isset($year_shortcut[$format]))
{
if (strpos($format, ', %Y'))
$y = ', %Y';
elseif (strpos($format, ' %Y'))
$y = ' %Y';
elseif (strpos($format, '-%Y'))
$y = '-%Y';
elseif (strpos($format, '%Y-'))
$y = '%Y-';
$year_shortcut[$format] = isset($y) ? $y : '%Y';
}
$show_today = str_replace($year_shortcut[$format], '', $format);
}

Posted: October 17th, 2011, 12:21 PM

PS, sorry for the huge post Pete... :^^;:

I'll take a break now.
Title: Re: New revs - Public comments
Post by: Arantor on October 17th, 2011, 03:52 PM
Quote
I believe there are a few items remaining from the OpenID code... Not a lot really. Just a few lines.
Just search for 'authenticate' (single word) and 'auth_method'. Because the authentication method is only 'password' now, the variable is useless.
Odd, I searched for 'authenticate' and 'auth_method' but I guess I somehow missed those :/
Quote
On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?
Quote
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!
Hmm. What I'd rather do is do the minimal stuff (user name/profile/group) and optionally then add extra stuff if needed, e.g. array('avatar', 'signature', 'custom fields'). Then I'd feel more comfortable extending loadMemberContext into general use (see in a moment).
Quote
And while we're at it -- I think it'd make sense to also have a param saying whether we want the member link to use group colors. They're not used in many areas and I'm not sure why. Actually, it could even make sense to always use the group colors. They're loaded at this point... Even in the topic pages it would make sense to show group colors (although I'm not sure about that.)
I've been wanting to add group colours for a while, just never got around to it. The real problem is that a surprising number of places do not reference loadMemberData/loadMemberContext for getting things like names, but do a raw join from whatever table into the members table to get the name. PMs is by far the worst offender for this from memory.

As I said above, it seems to me that making loadMemberContext more generally used would be advantageous, but at the same time that comes with an overhead in performance and memory. If it were better able to be segmented (both in lMC and lMD), as to what information you're looking for, that can be avoided.
Quote
- $txt['profile_of'] is used in things like $memberContext as a title. I'd rather have it say just 'View profile' than 'View profile of...' followed by a name that is *already* in the link... Totally silly. Plus, we already have $txt['profile_of_username'] which is correctly handled by a more logical sprintf.
Opinions?
Works for me. Is there anywhere $txt['profile_of'] is used as a link description where it wouldn't have the name available to it (and so wouldn't make sense if used that way)?
Quote
- $txt['time_am'] and $txt['time_pm']...
Crap, I thought I'd nailed all instances, guess I didn't search so thoroughly :/
Quote
I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
'am' and 'pm' is probably nicer looking and more consistent with what everyone else seems to use.
Quote
I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])
Looks fine to me.
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 04:59 PM
Quote from Arantor on October 17th, 2011, 03:52 PM
Odd, I searched for 'authenticate' and 'auth_method' but I guess I somehow missed those :/
Do you want to remove them, or me?
Quote
I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK. I'm not well up to date on what Dragooon is up to -- sorry. What I know, though, is that we can always change it later... but if we don't implement a generic hook for queries by the first release, at least we'll have a hookable member query. It's not particularly hard to retool into something generic anyway...

Still, I'd like to know where I'm going to put the post-query hook :P
Right now it's set to just after the query...
Quote
Quote
I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!
Hmm. What I'd rather do is do the minimal stuff (user name/profile/group) and optionally then add extra stuff if needed, e.g. array('avatar', 'signature', 'custom fields'). Then I'd feel more comfortable extending loadMemberContext into general use (see in a moment).
Quote
I've been wanting to add group colours for a while, just never got around to it. The real problem is that a surprising number of places do not reference loadMemberData/loadMemberContext for getting things like names, but do a raw join from whatever table into the members table to get the name. PMs is by far the worst offender for this from memory.
Not a big problem, I mean, we can always update them later... Or just don't bother.

PM example: the PM sender's name is specified with the group color. The PM recipient list isn't. Hmm...

Oh, and PT Sans + red for admin group = terribly ugly. Need to do something about that... Red is suitable for small Verdana fonts, but as soon as you make it a big font, it tends to catch attention too much.
Quote
As I said above, it seems to me that making loadMemberContext more generally used would be advantageous, but at the same time that comes with an overhead in performance and memory.
Definitely...
Quote
If it were better able to be segmented (both in lMC and lMD), as to what information you're looking for, that can be avoided.
You mean, like specifying the list of fields we want...? Or maybe a 'thematic' load or something? Like, $set is too restrictive... It'd probably benefit from being turned into one big array where items are added individually after tests are performed (if (isset($set['sig']) $select_columns[] = 'mem.signature'...?)
And then in lMC we test whether said field is present before we process it.

I'd tend to say that lMD and lMC are two of the most important functions in Wedge, and they should be handled with special care.
Quote
Works for me. Is there anywhere $txt['profile_of'] is used as a link description where it wouldn't have the name available to it (and so wouldn't make sense if used that way)?
Nope... It's always the same. <a title="View profile of Arantor">Arantor</a>. (Plus, as you can see, it's perfectly natural English... ::))
Removed in 1116.
Quote
Crap, I thought I'd nailed all instances, guess I didn't search so thoroughly :/
Don't sweat it, that's what I'm here for...! It may take me a long time to go through your code changes but I always try to catch this kind of stuff... And I hope you do the same for me :P Even though I tend to triple-check my commits, I'm never sure I'm doing the right thing.
Quote
'am' and 'pm' is probably nicer looking and more consistent with what everyone else seems to use.
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
Quote
Quote
I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])
Looks fine to me.
Changed it a bit in the meantime, but the idea stays the same.

I think I'm gonna go with the $txt solution where I provide the full year shortcut in the language files, and then if user doesn't use the default txt, we'll fall back to that test.
Title: Re: New revs - Public comments
Post by: Arantor on October 17th, 2011, 05:12 PM
Quote
Do you want to remove them, or me?
They can all go as far as I'm concerned. Even as a plugin I don't see OpenID as *replacing* the current login, but working alongside it. If FB Connect can be done as a plugin, so can OpenID, and FBC doesn't need the auth method setup AFAIK.
Quote
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.
Well, for the most part I was pretty happy to use it, and I was curious to know what you thought of it because it would require rewriting the more important queries to make them hookable directly.
Quote
Still, I'd like to know where I'm going to put the post-query hook
What, exactly, is it for? That's the question to ask. If it's for pushing things into $user_profile, it shouldn't be needed because $user_profile just gets the entire row as-is so providing it's in the query, it's pulled into PHP-land.
Quote
Not a big problem, I mean, we can always update them later... Or just don't bother.

PM example: the PM sender's name is specified with the group color. The PM recipient list isn't. Hmm...
I understand the logic of why it was done that way, it's primarily to avoid an extra query when that query (probably) isn't necessary, but it doesn't make it flexible. I'd almost be inclined to add an option in the admin panel for 'use member group colours', and make everything actually use that (doing the relevant join(s) to the membergroups table as appropriate). If nothing else, it's one more that's highly desirable that really, to me, should be in core.
Quote
Oh, and PT Sans + red for admin group = terribly ugly. Need to do something about that... Red is suitable for small Verdana fonts, but as soon as you make it a big font, it tends to catch attention too much.
*nods* I have no preference, but whatever is used, the rank images should adhere to it.
Quote
You mean, like specifying the list of fields we want...? Or maybe a 'thematic' load or something? Like, $set is too restrictive... It'd probably benefit from being turned into one big array where items are added individually after tests are performed (if (isset($set['sig']) $select_columns[] = 'mem.signature'...?)
And then in lMC we test whether said field is present before we process it.

I'd tend to say that lMD and lMC are two of the most important functions in Wedge, and they should be handled with special care.
Pretty much, at least. 'minimal', 'normal' and 'profile' are useful but not really *that* useful. Normal is used far more often than it's really needed to be, I find.

Now, if it were done thematically, you could really tighten up what's loaded when, though it would make bolting things into that query a lot more complicated.

I think figuring out where minimal and profile are used would be the first step, and making minimal a shade bigger to allow for things like member-group colour (and then making it used consistently!) would help - though I can't get the idea out of my head of splitting it into three to cope with the varied uses therein; places like PMs only need the minimal version, places like Display need the modest version and places like Profile need everything.
Quote
Removed in 1116.
Awesome.
Quote
Don't sweat it, that's what I'm here for...! It may take me a long time to go through your code changes but I always try to catch this kind of stuff... And I hope you do the same for me
I try to go through them, but I still miss stuff occasionally. Before our gold release, I'd like us to go through the language strings - at a minimum - to look for stray things that should have been removed.
Quote
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
Hrm. This smells like a partial reversion to me :/ If the format contains %p, I think we'll have to reinject am/pm instead.
Quote
I think I'm gonna go with the $txt solution where I provide the full year shortcut in the language files, and then if user doesn't use the default txt, we'll fall back to that test.
Works for me :)
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 06:53 PM
Quote from Arantor on October 17th, 2011, 05:12 PM
They can all go as far as I'm concerned. Even as a plugin I don't see OpenID as *replacing* the current login, but working alongside it. If FB Connect can be done as a plugin, so can OpenID, and FBC doesn't need the auth method setup AFAIK.
Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.
Quote
Quote
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.
Well, for the most part I was pretty happy to use it, and I was curious to know what you thought of it because it would require rewriting the more important queries to make them hookable directly.
My opinion...? Too complicated. I read through the topic and then I forgot it all.
I suppose that given we won't use this in all queries, it's okay to use it. But I'm not the one who'll implement it ;)
I simply did what I felt I needed to do with lMD while I was studying the changes after you removed OpenID... Now if you could just tell me whether you want me to commit it or not, I promise I won't mind either way. I'll just post my diff here for you to use if it inspires you.
Quote
What, exactly, is it for? That's the question to ask. If it's for pushing things into $user_profile, it shouldn't be needed because $user_profile just gets the entire row as-is so providing it's in the query, it's pulled into PHP-land.
Yeah, I suppose you're right... I did notice the $row stuff, but I thought that plugins might wanna change some settings for the rest of lMD, such as removing users from $users (although I guess it could be done by adding an INNER JOIN to filter people out directly from within the query), or processing user names and changing the value of $is_name accordingly. Hmm... Yeah it's a bit overdone. So, no post-processing hook.
Quote
I understand the logic of why it was done that way, it's primarily to avoid an extra query when that query (probably) isn't necessary,
An extra query are you sure? I have a feeling everything can be done with a LEFT JOIN on the membergroups table...
Quote
but it doesn't make it flexible. I'd almost be inclined to add an option in the admin panel for 'use member group colours', and make everything actually use that (doing the relevant join(s) to the membergroups table as appropriate). If nothing else, it's one more that's highly desirable that really, to me, should be in core.
Certainly something we should explore.

Other opinions on this...?
Quote
Now, if it were done thematically, you could really tighten up what's loaded when, though it would make bolting things into that query a lot more complicated.
(Hence my custom query to make it easier to add elements according to a variable test.)
Quote
I think figuring out where minimal and profile are used would be the first step,
From a quick look...
- normal: used nowhere.
- minimal: used in ManageErrors to pull only the real_name. And... that's all. Sigh!!
- profile: used in PersonalMessages.php when editing PM settings in the profile area, for use in the subsequently called saveProfileFields(), and in Profile and Profile-Modify, as expected.
- no param (i.e. normal):
* used in SSI (ssi_queryMembers), Display (load post authors), Feed (getXmlProfile), Memberlist (load member list -- serious candidate for 'minimal'), PersonalMessage (used in MessageFolder to load PM authors, MessageSearch2 for the same, MessagePost, and drafts. Used in Aeva Media's admin page to list moderators (strong candidate for deletion.)
* Also used in Profile-Actions.php only to retrieve the list of groups of a member for use in subscriptions(). Candidate for 'minimal', or even 'custom' by specifying only the membergroup data...
* Used in Search2 to get authors for found posts. Used in Who.php for the Who's Online list. Another candidate for 'minimal'...
* Used in Aeva Media to get comment authors, and then immediately after that to get the item author's data... Woot, nice oversight. We definitely should merge the two of these...

minimal is DEFINITELY in dire need of being reused elsewhere. We can safely add more data (who cares about ManageErrors performance!), and do things like making sure we don't retrieve the signature, etc.
Quote
and making minimal a shade bigger to allow for things like member-group colour (and then making it used consistently!) would help
I was thinking... Maybe, *maybe* we could 'simply' have ob_sessrewrite look through the list of links and color them accordingly... i.e. it gets the profile ID from the link, then fetches a list of users and groups. We'd just need to get a (cacheable!) list of membergroups and associated IDs. Then we can build a list of colors associated with member IDs. And voilà. We simply inject the needed CSS at rewrite time... :)

Seems like a very good idea to me. Plus, we can get rid of the existing custom colors, and we have an easy way to simply 'skip' the whole color thing (of course this option should be part of the option that allows to show membergroups in the info center... Or, we simply hardcode colors for these, and make sure ob_sessrewrite won't reparse them.)
Quote
I try to go through them, but I still miss stuff occasionally. Before our gold release, I'd like us to go through the language strings - at a minimum - to look for stray things that should have been removed.
I think there will be some, yeah... It's bound to happen. But I'd rather have too many strings than not enough :P
Quote
Quote
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
Hrm. This smells like a partial reversion to me :/ If the format contains %p, I think we'll have to reinject am/pm instead.
I'm not sure I understand. AFAIK SMF has always used %p to show the am/pm bit... Even Wedge uses %H:%I %p everywhere (in English). Maybe you mixed it up with %P, which shows a *lowercase* version, but isn't Mac OS-compatible... (I would have used that instead, otherwise. Heck...)
Title: Re: New revs - Public comments
Post by: TE on October 17th, 2011, 07:38 PM
Quote
Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.
That's indeed a very important point. there is the password reminder, the admin-center password verification and the profile page (account settings: password verification while changing important account data & password change in general)

I have some plans for a universal bridge  (webserver authentication, LDAP, external databases), thus I'd need a proper solution for these things...
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 08:21 PM
Quote from TE on October 17th, 2011, 07:38 PM
That's indeed a very important point. there is the password reminder, the admin-center password verification
I suspect that no one in their right mind would use Facebook to register/log into a forum they're administrating...
Quote
and the profile page (account settings: password verification while changing important account data & password change in general)
Password change would be disabled if no password is recorded in the first place. :)
Quote
I have some plans for a universal bridge  (webserver authentication, LDAP, external databases), thus I'd need a proper solution for these things...
Ah, LDAP... I've never understood what this is about ;)
Title: Re: New revs - Public comments
Post by: spoogs on October 17th, 2011, 08:31 PM
I use facebook to login to a forum I admin. I use SA's facebook mod for SMF which allows creating a forum username and password when registering... it is done this way so if there are any issues with facebook (which there has been in the past.. the reason this feature was requested and added) a user can still login into the forum using their user name and pass. You cannot however use your facebook info to access the ACP.
Title: Re: New revs - Public comments
Post by: Arantor on October 17th, 2011, 09:50 PM
Allowing a third party login system to be able to admin the forum is a security risk.

But all the third party logins should really create a true forum account, in which case whatever auth method can bootstrap the reminder process; OpenID had its own reminder page to remind you what OpenID login you used.

LDAP is something I thought about actually but even then you'd still authenticate against the LDAP server (eg Windows Server Active Directory) then create a forum account if necessary as the old LDAP bridge did.
Title: Re: New revs - Public comments
Post by: Nao on October 17th, 2011, 11:26 PM
Pete, there's a long post above for you :P

(Okay, okay, I've got one waiting for me, too...)
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 12:13 AM
OK, so for the rest of the stuff...
Quote
Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.
See above. The reminder functionality should be rediverted to however the plugin wants to support it.
Quote
My opinion...? Too complicated. I read through the topic and then I forgot it all.
I suppose that given we won't use this in all queries, it's okay to use it. But I'm not the one who'll implement it
Heh, that's really why I wanted your input since it would require converting queries and 'big' queries would need this treatment later.
Quote
An extra query are you sure? I have a feeling everything can be done with a LEFT JOIN on the membergroups table...
That's precisely my point. There are two routes: bolt on the left join on top of everything, every single place where member names are pulled directly (and trust me, there's a lot), or route it through loadMemberData which is an extra query.

Ideally everything should have gone through lMD/lMC for consistency but it's not done that way for performance.
Quote
I was thinking... Maybe, *maybe* we could 'simply' have ob_sessrewrite look through the list of links and color them accordingly... i.e. it gets the profile ID from the link, then fetches a list of users and groups. We'd just need to get a (cacheable!) list of membergroups and associated IDs. Then we can build a list of colors associated with member IDs. And voilà. We simply inject the needed CSS at rewrite time...
Works for me. But note that it's essentially the same query that I mentioned above, just run at a different time.

There are some interesting side-effects to doing that in the replace hook to beware of. Firstly, we'd have to disengage it if XML output is being used. Secondly, if there's a link in the middle of a post or something to someone's profile, that's going to be hit too.

Also, I'm wondering whether it wouldn't be cleaner[1] to put the different replace processes in their own buffer, to be called at the appropriate time. Just for the sake of putting code together and making it easier to follow (as opposed to one monolith function that makes it harder to understand, especially since its original purpose is slowly being outweighed by all its extra work)
Quote
- profile: used in PersonalMessages.php when editing PM settings in the profile area, for use in the subsequently called saveProfileFields(), and in Profile and Profile-Modify, as expected.
*nods* Profiles do actually need everything.
Quote
* used in SSI (ssi_queryMembers), Display (load post authors), Feed (getXmlProfile), Memberlist (load member list -- serious candidate for 'minimal'), PersonalMessage (used in MessageFolder to load PM authors, MessageSearch2 for the same, MessagePost, and drafts. Used in Aeva Media's admin page to list moderators (strong candidate for deletion.)
SSI use makes sense, though it could become a 'minimal' use without too much effort IIRC.

Display - naturally needs to be pretty thorough given what's displayed.

Feed - should be minimal, right?

Memberlist - it sort of depends what we put in the memberlist, and whether we add things like custom profile fields and avatars. (I've been meaning to add an option to CPFs to display in the memberlist, but I keep also meaning to think about doing something with its layout and making it less sterile)

PM - it uses lMD? I'm surprised, I'd actually thought there wasn't a use within PMs to do so, especially given how many other places within the PMs *don't* use it.[2]

Post I can understand for displaying the form back to users, but I don't remember it in drafts. There must have been a reason, very likely to find usernames, but I don't remember.
Quote
* Used in Search2 to get authors for found posts. Used in Who.php for the Who's Online list. Another candidate for 'minimal'...
Yup, though it's nice having the member's name in the right colour there as it should currently be.
Quote
I think there will be some, yeah... It's bound to happen. But I'd rather have too many strings than not enough
Sure, but I'd rather have the *right* strings for the job, even if that means adding or stripping some.
Quote
I'm not sure I understand. AFAIK SMF has always used %p to show the am/pm bit... Even Wedge uses %H:%I %p everywhere (in English). Maybe you mixed it up with %P, which shows a *lowercase* version, but isn't Mac OS-compatible... (I would have used that instead, otherwise. Heck...)
Hmm. The point I was getting at is that I didn't realise there was a %P for lowercase, and that I assumed %p was the only one out there, so that if it were found and we wanted to use lowercase, we'd have to manually replace - as was originally done by SMF...
 1. It won't be faster, and it probably will use more memory, though.
 2. I once wrote a 'slash through banned members' mod, which naturally means extending the places where a user's name is used to pull is_activated, plus obviously changing the displayed name. I recall there being 20+ changes I had to make to PersonalMessage to achieve this.
Title: Re: New revs - Public comments
Post by: live627 on October 18th, 2011, 12:54 AM
Quote
On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?
That looks familiar... :whistle:
Quote
I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?
But everything should be converted to arrays like that first.
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 01:34 AM
Quote
That looks familiar...
There are only so many ways you can make that beast hookable in its present form. Hardly surprising that both we and folks on sm.org were discussing it (theoretically independently) at the same time. Had I seen discussion there about bootstrapping a query object around it like we already talked about (and publicly), then I'd suggest all was not well in the garden of plenty. But hooking it conventionally... not so amazing.
Title: Re: New revs - Public comments
Post by: TE on October 18th, 2011, 07:28 AM
Quote from Nao on October 17th, 2011, 08:21 PM
I suspect that no one in their right mind would use Facebook to register/log into a forum they're administrating...
why not? We have implemented a smartcard authentication in our company, thus my account has been validated during Windows logon to our Active Directory. All following systems (e.g. a webserver) are using a passthrough authentication via kerberos ticket / ntlm.

The backend webservers know me from my kerberos ticket ($_SERVER['PHP_AUTH_USER'] is defined) but I don't have a password, therefore $_SERVER['PHP_AUTH_PW'] isn't set. Sure, I can generate some kind of random password but that's against the idea of SSO (SingleSignOn).
Quote from Nao on October 17th, 2011, 08:21 PM
Ah, LDAP... I've never understood what this is about ;)
An LDAP-Directory isn't  a miracle, just a "database" with user /account information designed for central authentication.
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 08:56 AM
Authenticating to a specific third party under your control is one thing, authenticating to a separate third party that you have absolutely no control over is something else.

The former is one place where I can see the logic, though surely all that's needed in that case is to turn over authentication over to the separate backend and if authenticated through that method, silently turn on 'disable admin security' (but only for the life of that page)?
Title: Re: New revs - Public comments
Post by: Nao on October 18th, 2011, 09:10 AM
Quote from Arantor on October 18th, 2011, 12:13 AM
Heh, that's really why I wanted your input since it would require converting queries and 'big' queries would need this treatment later.
Well, if you and Dragooon are into it, then you should do it... I don't have the perfect answer to everything ;)
Quote
That's precisely my point. There are two routes: bolt on the left join on top of everything, every single place where member names are pulled directly (and trust me, there's a lot), or route it through loadMemberData which is an extra query.
Yeah...
Or, as I said: select m.id_member, g.online_color from members as m, membergroups as g where m.id_group = g.id_group
Something like that... (?)
Then get the entire list of people, push it into the cache for a few minutes, and use that cache internally to associate people with a color. It might represent a large cache file but if we ensure the option can be disabled, it's okay I guess... (?)
Quote
Works for me. But note that it's essentially the same query that I mentioned above, just run at a different time.
Sure... And in a cacheable fashion.
Quote
There are some interesting side-effects to doing that in the replace hook to beware of. Firstly, we'd have to disengage it if XML output is being used.
Why? I can't think of an example where adding a class to an anchor would be detrimental to XML functionality...?
Quote
Secondly, if there's a link in the middle of a post or something to someone's profile, that's going to be hit too.
Hmm yeah, I suppose... Although it's unlikely to happen.
But we could look through the entire anchor tag and reject it if it has bbc_ in it or something...
Quote
Also, I'm wondering whether it wouldn't be cleaner[1] to put the different replace processes in their own buffer, to be called at the appropriate time.
 1. It won't be faster, and it probably will use more memory, though.
Definitely cleaner. But easier to understand? I don't know, I've never been much into 'nested' output buffers, they never made much of a sense to me, I'd rather have it all in the same place...
Quote
Just for the sake of putting code together and making it easier to follow (as opposed to one monolith function that makes it harder to understand, especially since its original purpose is slowly being outweighed by all its extra work)
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
Quote
Feed - should be minimal, right?
Or 'custom', in my mind.
Quote
Memberlist - it sort of depends what we put in the memberlist, and whether we add things like custom profile fields and avatars. (I've been meaning to add an option to CPFs to display in the memberlist, but I keep also meaning to think about doing something with its layout and making it less sterile)
Definitely a 'custom' candidate then...
Quote
PM - it uses lMD? I'm surprised, I'd actually thought there wasn't a use within PMs to do so, especially given how many other places within the PMs *don't* use it.
It only uses lMD when you're setting PM options in your profile...
Quote
I once wrote a 'slash through banned members' mod, which naturally means extending the places where a user's name is used to pull is_activated, plus obviously changing the displayed name. I recall there being 20+ changes I had to make to PersonalMessage to achieve this.
Looks interesting, though.
Quote
Post I can understand for displaying the form back to users, but I don't remember it in drafts. There must have been a reason, very likely to find usernames, but I don't remember.
I'll let you check the files independently... Yeah IIRC it's to find usernames for recipients that didn't go through the auto-suggest.
Quote
Yup, though it's nice having the member's name in the right colour there as it should currently be.
I think that's the only place you get it apart from the info center... A real bummer.
Quote
Hmm. The point I was getting at is that I didn't realise there was a %P for lowercase,
It's technically valid only in Linux. It doesn't work in Windows and Mac OS.
Quote
and that I assumed %p was the only one out there, so that if it were found and we wanted to use lowercase, we'd have to manually replace - as was originally done by SMF...
You know, you COULD revert this and no one would blame you for that... ;)
Title: Re: New revs - Public comments
Post by: Nao on October 18th, 2011, 09:13 AM
Quote from live627 on October 18th, 2011, 12:54 AM
That looks familiar... :whistle:
I suspect that means something you offered before, sorry I can't remember.
I just looked at the huge query, remembered the hassle it was to plug some of AeMe's code into it (one of the biggest incompatibility generators out there), and wanted it gone, like, now.

Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?

Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
Title: Re: New revs - Public comments
Post by: TE on October 18th, 2011, 09:15 AM
Quote from Arantor on October 18th, 2011, 08:56 AM
The former is one place where I can see the logic, though surely all that's needed in that case is to turn over authentication over to the separate backend and if authenticated through that method, silently turn on 'disable admin security' (but only for the life of that page)?
yep, that's a perfect solution regarding admin security but there would still be an issue with the profile account data (can't be updated because I don't know my password). Maybe I can set that field as a hidden form field with a pre-filled password or something similar.. I currently have no clue to work around that issue with a proper solution..  Any ideas?
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 09:25 AM
Quote
Well, if you and Dragooon are into it, then you should do it... I don't have the perfect answer to everything
It's on my todo list :P
Quote
Or, as I said: select m.id_member, g.online_color from members as m, membergroups as g where m.id_group = g.id_group
Something like that... (?)
Yes, but it means doing that treatment everywhere where names are pulled directly. The alternatives are converting everything to a case of loadMemberData (minimal) or doing it in the post-replace phase, either way that's an extra query.
Quote
Then get the entire list of people, push it into the cache for a few minutes, and use that cache internally to associate people with a color. It might represent a large cache file but if we ensure the option can be disabled, it's okay I guess... (?)
Hmm. I'm thinking that we could do it better by querying and caching the member group colours on a longer term basis, and fetching user+group instead, as querying every user with their group is going to be quite expensive.
Quote
Why? I can't think of an example where adding a class to an anchor would be detrimental to XML functionality...?
It depends how fussy the receiver is. A receiver expecting Atom and gets not-strictly-valid Atom might throw a wobbly. Besides, in XML modes, there's no point running that operation, might as well save a few CPU cycles...
Quote
Hmm yeah, I suppose... Although it's unlikely to happen.
But we could look through the entire anchor tag and reject it if it has bbc_ in it or something...
Works for me. Just something I wanted to be careful of, really.
Quote
Definitely cleaner. But easier to understand? I don't know, I've never been much into 'nested' output buffers, they never made much of a sense to me, I'd rather have it all in the same place...
It works like any other nesting, and for the most part it's pretty transparent. The buffer's passed in with each successive nesting, callback run when the buffer's done, then it's passed back up the nesting.
Quote
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
That would work and would probably be faster than using true buffers to pass back and forth.
Quote
Or 'custom', in my mind.
If you're sending out a feed of new members, there's really only so much you can put into it before you break Atom format, no?
Quote
Definitely a 'custom' candidate then...
Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.
Quote
It only uses lMD when you're setting PM options in your profile...
That seems... illogical somehow.
Quote
I'll let you check the files independently... Yeah IIRC it's to find usernames for recipients that didn't go through the auto-suggest.
Ahhhh, loadMemberData with second parameter as true, that makes sense now.
Quote
I think that's the only place you get it apart from the info center... A real bummer.
Yup, it either should be throughout or not at all.
Quote
It's technically valid only in Linux. It doesn't work in Windows and Mac OS.
That'll be why I didn't think of it.
Quote
You know, you COULD revert this and no one would blame you for that...
I could but it would feel wrong. The whole solution seems hacky and I don't like it but I just don't know a better one.
Quote
I suspect that means something you offered before, sorry I can't remember.
I just looked at the huge query, remembered the hassle it was to plug some of AeMe's code into it (one of the biggest incompatibility generators out there), and wanted it gone, like, now.

Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?

Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
There was a discussion on sm.org where someone offered a patch that did almost the exact same thing.

Also, why would you want to pass in parameters not related to the query itself, exactly?
Quote
yep, that's a perfect solution regarding admin security but there would still be an issue with the profile account data (can't be updated because I don't know my password). Maybe I can set that field as a hidden form field with a pre-filled password or something similar.. I currently have no clue to work around that issue with a proper solution..  Any ideas?
There was some stuff in the profile code relating to this for OpenID purposes, actually. There's a parameter 'password' that's needed to be set if password is going to be required for changing, IIRC, which was set to false if OpenID was used. But OpenID wasn't capable of taking any case where validatePassword was called (which meant you couldn't go into the admin panel, or change someone else's profile, though you could change your own because of the above)

It wouldn't be too bad to provide somewhere that that value can be reset through a hook, and optionally a hook in the validatePassword subsystem to allow authentication plugins to safely handle admin-type security checks.
Title: Re: New revs - Public comments
Post by: Dragooon on October 18th, 2011, 09:37 AM
Quote from Nao on October 18th, 2011, 09:13 AM
I suspect that means something you offered before, sorry I can't remember..
He provided a very similar patch on SM.org, plus it's very similar to how I pass parameters to wesqlQuery.
Quote from Nao on October 18th, 2011, 09:13 AM
Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?

Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
It does via the fetch function, the parameters are passed to result callbacks.
Quote
Also, why would you want to pass in parameters not related to the query itself, exactly?
They can be required for processing the result.
Title: Re: New revs - Public comments
Post by: Nao on October 18th, 2011, 03:04 PM
Quote from Arantor on October 18th, 2011, 09:25 AM
It's on my todo list :P
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
Quote
Yes, but it means doing that treatment everywhere where names are pulled directly. The alternatives are converting everything to a case of loadMemberData (minimal) or doing it in the post-replace phase, either way that's an extra query.
And lMD is going to be slower...
I have to admit I'm a sucker for dynamic replacements. Even on very text-heavy pages, it's still always super fast, and as long as it's done correctly... Well, there's nothing better :P
Right now, my color injection code, as slow and unoptimized as it is (preg_replace_callback...), only takes a millisecond to execute, and that includes loading the cached data. And with recaching, it takes 3ms, but OTOH I only have one custom group on my test site (admin), so it's bound to be fast overall...
Quote
Hmm. I'm thinking that we could do it better by querying and caching the member group colours on a longer term basis, and fetching user+group instead, as querying every user with their group is going to be quite expensive.
Can you elaborate on this...?
I've rewritten my code to store members+groups followed with a list of colors per group, to avoid repetition and thus generate a smaller cache file for bigger arrays. But I'm not sure what you're suggesting...?
The result is something like this: (let's say users 1, 2 and 5 are admins and user 3 is from group 7)
$member_colors = array(
  'group' => array(
    1 => 1,
    2 => 1,
    3 => 7,
    5 => 1,
  ),
  'color' => array(
    1 => '#FF0000',
    7 => '#FFCC99',
  ),
);

So, basically, we retrieve the color with $member_colors['color'][$member_colors['group'][$USER_ID]].

Of course, I'm also testing for 'bbc_link' inside the match, and it works well.
Quote
It depends how fussy the receiver is. A receiver expecting Atom and gets not-strictly-valid Atom might throw a wobbly. Besides, in XML modes, there's no point running that operation, might as well save a few CPU cycles...
I'm not sure... For instance, I quick-edited a post and the result had the proper group color, which was fine (and wouldn't have happened if XML didn't run it.) Obviously I've disabled it now, but basically I don't really see a reason to prevent any XML that shows a profile link, to actually show it in the proper color...
Quote
Works for me. Just something I wanted to be careful of, really.
I'm not entirely convinced it's the best way though. I mean, to me as a user, it would make sense to have my link show in red if I'm linking inside my post to an admin's profile... I don't know.
Of course, if I'm using PURLs, the link will show with the regular color because then Wedge has no way to (easily) figure out the target's group color...
Quote
It works like any other nesting, and for the most part it's pretty transparent.
Sorry, I don't mean that I don't understand them, I just mean that I don't get the point. To me, output buffers are nice if you're trying to 'catch' data output by something else, etc, but if you know the exact execution order, it's best to just put everything into the same OB...
For instance, link replacements have to happen after <URL> is transformed, but before pretty URLs are applied. I was thinking of using my replacement code right inside the purl filter file, to be able to both transform profile URLs and add a color at the same time, but... Err, one millisecond...? Who cares. Might as well make the code clearer and put everything in the same place.
Quote
Quote
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
That would work and would probably be faster than using true buffers to pass back and forth.
Definitely... But I'm not in a hurry to do that either, though :lol:
Quote
Quote
Or 'custom', in my mind.
If you're sending out a feed of new members, there's really only so much you can put into it before you break Atom format, no?
What do you mean?
Quote
Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.
Sure.......................... Who's up for it? :P
Quote
Quote
I think that's the only place you get it apart from the info center... A real bummer.
Yup, it either should be throughout or not at all.
(With the technicality of big user names (e.g. userbox authors) being potentially a problem. I'm thinking of fixing it by changing the default colors to pastel ones, like the group colors on wedge.org... #d2653a is definitely nicer than red for admins!)
Quote
Quote
You know, you COULD revert this and no one would blame you for that...
I could but it would feel wrong. The whole solution seems hacky and I don't like it but I just don't know a better one.
Looking at the SMF2 code, it only checks for %p (lowercase), which generates uppercase AM and PM, and manually transforms them to time_am and time_pm, but they're not dealing with %P... Just so you know-- if you add a %P on a server that doesn't support it, it'll return an empty string... Not an empty am/pm; but an entirely empty string. (At least under Windows.) I don't think 'wrong' values are being filtered out if the user enters a custom time format...

(Heck, if it wasn't for the custom time format thing, I wouldn't have had to do the whole preg_match stuff to find the year.)
Quote
Also, why would you want to pass in parameters not related to the query itself, exactly?
<evil grin> "I don't know, but it's going to be a lot of fun finding out!" (Lister, epilogue, Red Dwarf 2x06)
Okay, forget it, once the query is converted, plugins will still have access to $users from within the query anyway... ;)

Oh... I just found out that my replacement code was also changing the color for links inside the profile area (showposts, etc.), ah ah... Well, easy to fix (just match against URLs with just a profile ID and nothing else...)
I could make the fix 'perfect' by storing user names in addition to groups in the cache. Then I would simply need to determine if the visible link matches the real_name, but... That would make for a bigger cache. I don't like the idea too much.
Quote
It wouldn't be too bad to provide somewhere that that value can be reset through a hook, and optionally a hook in the validatePassword subsystem to allow authentication plugins to safely handle admin-type security checks.
I'm definitely leaving that one up to you ;)
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 03:19 PM
Quote
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
The discussion on wesqlQuery showed examples of doing that, no?
Quote
Can you elaborate on this...?
I've rewritten my code to store members+groups followed with a list of colors per group, to avoid repetition and thus generate a smaller cache file for bigger arrays. But I'm not sure what you're suggesting...?
I figured we might as well cache the membergroups and their colours generally (including post count groups), and in places we already do a join to the members table to get the member's name, add the id_group and id_post_group parameters from there into the query.

The idea is to save either the extra join or the extra query, since if we're already doing the join to members, there's no need to do any further joining or querying if we already have the list of membergroups and their colours available to us.
Quote
Sorry, I don't mean that I don't understand them, I just mean that I don't get the point. To me, output buffers are nice if you're trying to 'catch' data output by something else, etc, but if you know the exact execution order, it's best to just put everything into the same OB...
For instance, link replacements have to happen after <URL> is transformed, but before pretty URLs are applied. I was thinking of using my replacement code right inside the purl filter file, to be able to both transform profile URLs and add a color at the same time, but... Err, one millisecond...? Who cares. Might as well make the code clearer and put everything in the same place.
The argument I'm suggesting - but not that heavily - is encapsulating functionality. Right now the post-replace phase is pretty complex, and is made up of a series of stages. Wouldn't it be better to make each stage a separate function, so that if ever you need to alter behaviour, firstly it's localised into a single function, and secondly if you need to rearrange them, you're rearranging a few lines rather than bulk copy/paste?
Quote
Sure.......................... Who's up for it?
I kind of like the columns on here/Noisen actually, it's an improvement over the default. I also hear that what Antechinus made for the 'dynamic memberlist' isn't too bad either, might be worth looking at the visual side to see if it isn't hideous and see whether something vaguely like that wouldn't be a bad idea.[1]
Quote
What do you mean?
Atom is XML. If you add an attribute to that XML, it's still valid XML - but it stops being a valid Atom file. Remember, XML formats aren't just randomly extensible, they have schemas to direct what elements there are and what the valid list of attributes is.

Some XML consumers won't care and will totally ignore that attribute. Some will care a great deal and write the XML feed off as invalid. So yeah, it's kind of important not to just randomly mess with set XML formats unless you're the only one using it and can afford not to be too picky about it come consumption time. For example, the plugin manager doesn't ever expressly validate the plugin-info.xml files against the schema. It *can* but it doesn't. It only validates the content to make sure it makes sense and is understandable, not that it's strictly legal. (I figure we'll do that on plugin upload, you see)
Quote
(With the technicality of big user names (e.g. userbox authors) being potentially a problem. I'm thinking of fixing it by changing the default colors to pastel ones, like the group colors on wedge.org... #d2653a is definitely nicer than red for admins!)
*nods* I don't have a problem with that, I think it would be an improvement.
Quote
Looking at the SMF2 code, it only checks for %p (lowercase), which generates uppercase AM and PM, and manually transforms them to time_am and time_pm, but they're not dealing with %P... Just so you know-- if you add a %P on a server that doesn't support it, it'll return an empty string... Not an empty am/pm; but an entirely empty string. (At least under Windows.) I don't think 'wrong' values are being filtered out if the user enters a custom time format...

(Heck, if it wasn't for the custom time format thing, I wouldn't have had to do the whole preg_match stuff to find the year.)
No, Windows doesn't do any filtering, which is a bit poor really. (It should at least return them as literals.)
Quote
<evil grin> "I don't know, but it's going to be a lot of fun finding out!"
Actually, Dragooon answered that one, and wesqlQuery provides for it.

 1. But I'd code it from scratch anyway, not only to avoid claims of copying but simply because we'd have to do it differently.
Title: Re: New revs - Public comments
Post by: Nao on October 18th, 2011, 06:43 PM
Quote from Arantor on October 18th, 2011, 03:19 PM
I figured we might as well cache the membergroups and their colours generally (including post count groups),
Oh, I forgot about post count groups... I never enable colors for these.

Okay, done... (Half an hour later :P)
I also managed to catch the place where postgroups are updated so I can clear the cache, but I wouldn't mind some help spotting other areas where regular groups are updated.

Also, looked into rev 1118, just a note: there are plenty of multiple spaces (not tabs) in the file, most notably several distinct lines often find themselves on the same line separated by many spaces... Odd!
And the ManagePlugins template -- you committed an empty function, is this as intended?

Oh, and before I forget... There are dozens (hundreds?) of &quot; in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
Quote
and in places we already do a join to the members table to get the member's name, add the id_group and id_post_group parameters from there into the query.
I think it's better (for now) to harmonize the queries, so I started removing online_color when not required by something else...
Well, I'm a bit lost in the amount of changes I made today so I'll just commit what I have now and you can look into it.
Quote
The idea is to save either the extra join or the extra query, since if we're already doing the join to members, there's no need to do any further joining or querying if we already have the list of membergroups and their colours available to us.
That's the idea... I think.
Quote
The argument I'm suggesting - but not that heavily - is encapsulating functionality. Right now the post-replace phase is pretty complex, and is made up of a series of stages. Wouldn't it be better to make each stage a separate function, so that if ever you need to alter behaviour, firstly it's localised into a single function, and secondly if you need to rearrange them, you're rearranging a few lines rather than bulk copy/paste?
I haven't been moving a lot of code honestly, only recently to straighten it up but I don't see myself adding to that function on a daily basis anyway..... :^^;:
Quote
I kind of like the columns on here/Noisen actually, it's an improvement over the default.
I just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
Quote
I also hear that what Antechinus made for the 'dynamic memberlist' isn't too bad either, might be worth looking at the visual side to see if it isn't hideous
Isn't there a 'super memberlist' mod around? The one where members are listed in boxes -avatar, then some info below... I'm not a big fan of the way it's shown, but it's probably a way to do it that's logical to most people.
Quote
Atom is XML. If you add an attribute to that XML, it's still valid XML - but it stops being a valid Atom file. Remember, XML formats aren't just randomly extensible, they have schemas to direct what elements there are and what the valid list of attributes is.
Hmm... I see. Well, now that the code is committed (I wanted to post this before, but I had a browser crash -- thank you for drafts! -- and committed while waiting for my tab list to reload), you can look into it and test the XML maybe...?

And please generally tell me what you think about the overall building of the feature ;)
Quote
Actually, Dragooon answered that one, and wesqlQuery provides for it.
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
Title: Re: New revs - Public comments
Post by: Arantor on October 18th, 2011, 09:18 PM
Quote from Nao on October 18th, 2011, 06:43 PM
Oh, I forgot about post count groups... I never enable colors for these.
We might not but I know sites that do.
Quote
I also managed to catch the place where postgroups are updated so I can clear the cache, but I wouldn't mind some help spotting other areas where regular groups are updated.
Profile area is the main one, but it's not the only one. Group management (Groups.php) is the other main one for assigned groups. Theory says updateMemberData() should be called.
Quote
Also, looked into rev 1118, just a note: there are plenty of multiple spaces (not tabs) in the file, most notably several distinct lines often find themselves on the same line separated by many spaces... Odd!
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
Quote
And the ManagePlugins template -- you committed an empty function, is this as intended?
Yes, that was intended; I am going to populate that function but after fighting with the Class-FileWritable and Subs-Plugins code I was a bit fed up, so committed it as was, raw and unfinished.
Quote
Oh, and before I forget... There are dozens (hundreds?) of &quot; in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
Be very careful with those. There are cases where mismatching goes on - when I created the Birthdays plugin out of the email templates, I made use of a little known quirk of SMF's language editor.

Specifically, you can actually do this in the language files and expect it to work properly in the language editor for both loading and saving:
Code: [Select]
$txt['string'] = 'line 1' . "\n\n" . 'line 2';

I don't know how ManageLanguages does that, so without testing to understand whether there are interesting side effects or not.
Quote
I think it's better (for now) to harmonize the queries, so I started removing online_color when not required by something else...
Well, I'm a bit lost in the amount of changes I made today so I'll just commit what I have now and you can look into it.
Harmonisation is good :) And yeah, I understand exactly what you mean where lots of changes happen, I had points during the early plugin manager dev where it was doing that to me.
Quote
I haven't been moving a lot of code honestly, only recently to straighten it up but I don't see myself adding to that function on a daily basis anyway..... :^^;:
I'm just thinking of the case of having to come back to it in 6 months time.
Quote
I just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
I like it.
Quote
Isn't there a 'super memberlist' mod around? The one where members are listed in boxes -avatar, then some info below... I'm not a big fan of the way it's shown, but it's probably a way to do it that's logical to most people.
Yes, that's the one.
Quote
Hmm... I see. Well, now that the code is committed (I wanted to post this before, but I had a browser crash -- thank you for drafts! -- and committed while waiting for my tab list to reload), you can look into it and test the XML maybe...?
Well, I'll take a look but we might as well not run that particular process if we're outputting XML, I can't see any case in XML (valid or otherwise) where we'd want the colour to be added.
Quote
And please generally tell me what you think about the overall building of the feature ;)
I like the idea but will look at the code later on.
Quote
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
Of course, I'm going to need it before long ;)
Title: Re: New revs - Public comments
Post by: Nao on October 19th, 2011, 12:46 AM
I'm looking at Settings.template.php and only one question comes to mind... Why this? I can understand some themes might wanna add options, but... This makes it very hard to actually find them (they're neither accessible from Profile > Look & Layout, not from the regular admin area... You have to go to Admin > Current Theme, which I don't find very intuitive.)
And because they're not in the admin area per se, they're not searchable, even they they DO show up in the admin.
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...

I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.
Quote from Arantor on October 18th, 2011, 09:18 PM
We might not but I know sites that do.
Which is why I added a default color for the highest post group in Wedge... :)
Quote
Profile area is the main one, but it's not the only one. Group management (Groups.php) is the other main one for assigned groups. Theory says updateMemberData() should be called.
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything ;)
Quote
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
It only matters if you're not going to update the file in the future.
Quote
Be very careful with those. There are cases where mismatching goes on - when I created the Birthdays plugin out of the email templates, I made use of a little known quirk of SMF's language editor.
Well, we still have a lot of " in the language files, which we used naturally this year AFAIK. So it's pretty much a mixup...
Quote
Harmonisation is good :)
Feel free to delete these on your side, too. For instance it's bed time for me... :P

Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)
Quote
Well, I'll take a look but we might as well not run that particular process if we're outputting XML, I can't see any case in XML (valid or otherwise) where we'd want the colour to be added.
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
Title: Re: New revs - Public comments
Post by: Arantor on October 19th, 2011, 03:17 AM
Quote
I'm looking at Settings.template.php and only one question comes to mind... Why this? I can understand some themes might wanna add options, but... This makes it very hard to actually find them (they're neither accessible from Profile > Look & Layout, not from the regular admin area... You have to go to Admin > Current Theme, which I don't find very intuitive.)
It's to make it easier for themes to add options, that are under admin control. There's no way for themes to add user options AFAIK without replacing some/all of the profile template.

Admin > Current Theme makes some modicum of sense, but not a lot - though it's a world better than how unobvious theme settings are to find normally.
Quote
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...

I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.
It's a theme option because not all themes provide it. Seriously tempted to move that back out into being a plugin anyway because partly not all themes provide it and partly because so many people want it 'ordered how they want, not just alphabetic', and I think it would be a stretch too far to make core with that in mind. It's not like it's tough to expand any more or anything.
Quote
Which is why I added a default color for the highest post group in Wedge...
Nice. I spent the rest of my evening trying to score the one remaining achievement I had for Monkey Island II on Steam (complete the game in under 3 hours, just finished with 30 mins to spare), so I haven't looked at the commit yet.
Quote
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
Is there really a lot of places that call updateMemberData?
Quote
It only matters if you're not going to update the file in the future.
I'll update it if it becomes necessary but given how there haven't been updates for a while and it's one of those things that generally 'just works', it should be OK to fix up now.
Quote
Well, we still have a lot of " in the language files, which we used naturally this year AFAIK. So it's pretty much a mixup...
Hmm, we should probably test that. It's likely I'm worrying about nothing but I'd rather that and be proven wrong than to be bitten by it later.
Quote
Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)
I'll do that in the morning to see what's going on.
Quote
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
Testing for $_GET['xml'] is good but it doesn't automagically do that for the feeds IIRC. But if we had the feeds set that too (if they don't already), then it's a no-brainer.
Title: Re: New revs - Public comments
Post by: live627 on October 29th, 2011, 05:48 AM
ManagePlugins is missing a comma at the end of line 1408 casuing a fatal error.
Title: Re: New revs - Public comments
Post by: Nao on October 29th, 2011, 10:52 AM
I'll look into it. I shall be committing today anyway.

Oh and I need to answer the post above...
Title: Re: New revs - Public comments
Post by: Arantor on October 30th, 2011, 02:10 AM
I fixed the comma issue in r1138.

The template layer issue I referred to (that you asked about in the notes on r1137) stems from what happens in the event that a template layer is empty. The post was in http://wedge.org/pub/off/6980/battlefield-3/msg269815/#msg269815

I don't seem to have a problem if the array is defined with some content up front, or with ::layer, but it gets upset if it's declared in a master wetem::load call as an empty array.


On a related note, I have a case where I'm defining a container layer, which has before and after content, but that there may or may not be content added to that layer, and because that container is designed to be hookable, I see two routes. Either the plugin (of a plugin) tests for layer existence and re-adds it if necessary, or I create the layer by default, let hooks run, then have some kind of is-empty test on the layer, and if so, remove the layer.

I'm not sure whether it's necessary to have the is-empty test because I do have the ability to test and add if necessary but it seems that it might be nicer to be able to check is-empty status to allow things to do cleanup. (I'm not really fussed if it isn't implemented)
Title: Re: New revs - Public comments
Post by: live627 on October 30th, 2011, 06:03 AM
Quote
! Provide a hook for altering the list of posts to be retrieved, as suggested by live627. (ManagePlugins.php, Display.php)
What is the time for? If it's what I think it is (plugin-side caching based on time) shouldn't it also include modified time? Whichever is higher? Or am I totally missing the point?
Title: Re: New revs - Public comments
Post by: Arantor on October 30th, 2011, 04:22 PM
I added it because the time is expressly queried when fetching the list of messages (and posters, as a by product)

It's used in relation to the double post merging, I believe.
Title: Re: New revs - Public comments
Post by: live627 on October 30th, 2011, 08:48 PM
Go up and go down links are backwards.
Title: Re: New revs - Public comments
Post by: Arantor on October 30th, 2011, 08:49 PM
That's... interesting since I didn't change any of the logic, just unwrapped the ifs in them. I'll take a look in a bit.
Title: Re: New revs - Public comments
Post by: live627 on October 30th, 2011, 08:53 PM
Looks like the two JS functions in topic.js need swapped to fix it.
Title: Re: New revs - Public comments
Post by: Nao on October 30th, 2011, 10:56 PM
Hmm, my fault apparently! rev 1070. Sorry :^^;: will fix.
Title: Re: New revs - Public comments
Post by: Arantor on October 31st, 2011, 12:12 PM
In other news, remember I said about the ob_sessrewrite rewriting stuff being split up into multiple functions for clarity? I found another reason I would do that, or at least part of that.

Specifically, I'm working on WedgeDesk a bit, and there's a point where a link to a user's profile might be retrieved via AJAX. But because it's sent back via AJAX, the user name isn't reformatted.

Now, I know I can invoke the output buffer callback manually but when the entirety of what I'm sending back is:
Code: [Select]
<?xml version="1.0" encoding="UTF-8"?><response><item><![CDATA[<a href="http://smf/wedge/index.php?action=profile;u=1">Arantor</a>]]></item></response>

...it almost doesn't seem worth invoking the entire buffer operation for that.
Title: Re: New revs - Public comments
Post by: Aaron on December 22nd, 2011, 01:12 AM
Quote
* Even with all of the keyboard shortcut additions, still managed to go from 2386 to 2351... I eat bytes for breakfast. (And if you're French: I said bytes, with a y.) (sbox.js)
Not French, but I knew exactly what you meant after reading the comment. Oh you. :lol:
Title: Re: New revs - Public comments
Post by: Nao on December 22nd, 2011, 10:52 AM
With pleasure! :P

Oh, and about the last rev.... It seems that there's a glitch when showing dropdowns in Opera 12. I don't know why, but the last 8 pixels or so at the bottom don't have any border, rounded corners or even box shadow... It's just plain white. If I try to inspect the element, it suddenly fixes itself, so it's clearly a bug linked to how they mark their areas as 'dirty'. Hopefully they'll fix it later... It doesn't bother me too much because it works in other browsers I tested.

Also, the new code makes an unnecessary call to .outerHeight() when repositioning a dropdown, which probably wastes a couple milliseconds, but saves a few bytes. Anyone contesting my choices? :niark:
Posted: December 22nd, 2011, 10:52 AM
Quote from Arantor on October 31st, 2011, 12:12 PM
...it almost doesn't seem worth invoking the entire buffer operation for that.
...hook? :P

(I feel like the librarian in Discworld :lol:)
Title: Re: New revs - Public comments
Post by: Arantor on December 22nd, 2011, 01:52 PM
I'm not sure a hook would help though :/
Title: Re: New revs - Public comments
Post by: live627 on December 24th, 2011, 07:59 AM
Links on titlebg2 are  yellowish and hard to read (advanced search)
Posted: December 24th, 2011, 04:49 AM


Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';' in J:\Backups\Linux Drive\www\wedge\trunk\Themes\default\ManageBoards.template.php on line 161
Posted: December 24th, 2011, 05:22 AM

The profile field templates don't work. I select Facebook, Twitter, nothing happens.
Title: Re: New revs - Public comments
Post by: Nao on December 24th, 2011, 11:38 AM
First one is due to wanting to have a clear hint that they were clickable, by keeping them the same color as usual IIRC... And yeah, I know, it bothers me a bit too... I should also make links a bit smaller. But everything in my mind is controlled by how the Quick Reply link looks like... Meh.
Any color to suggest as replacement...?

Second issue: fixed, thank you. (4 errors overall in the file.)

Third issue: fixed, thank you again. This is due to the change event never being triggered because the original value was already overwritten at the time the change was tested against.

It's annoying how many bugs are going to be caused by the new select box... But OTOH, it looks really cool... :^^;:
Title: Re: New revs - Public comments
Post by: Nao on December 24th, 2011, 03:56 PM
Really impressed with the number of glitches due to the new select box code..... :( :( :(

Just have a look at the 'add/remove label' select box from the PM area. It's completely broken... Argh. I'm starting to have second thoughts about all this...
Title: Re: New revs - Public comments
Post by: Arantor on December 24th, 2011, 04:54 PM
Only because so much of SMF used selectboxes in interesting and inconsistent ways. It'll be worth fixing them.
Title: Re: New revs - Public comments
Post by: Nao on December 24th, 2011, 05:20 PM
Actually that feature was broken even before the new select box code. Hmm. Maybe it's broken in SMF as well?
Title: Re: New revs - Public comments
Post by: Arantor on December 24th, 2011, 07:19 PM
Very possibly, I'm not entirely sure how well it works, most don't even know it's there...
Title: Re: New revs - Public comments
Post by: Nao on December 24th, 2011, 10:45 PM
I used to use it a couple years ago. The feature would benefit from having default labels like {to_answer} etc. No?
Title: Re: New revs - Public comments
Post by: Arantor on December 25th, 2011, 12:02 AM
I use it too, but its usefulness is diminished with convo mode, as compared to unlabelled.

Default labels would be quite good but it really depends whether it would be more useful spun as folders or Gmail like tags, which is really what it's closer to.
Title: Re: New revs - Public comments
Post by: Nao on December 25th, 2011, 12:10 AM
I think doing default labels could also encourage us to make them more prominent ie show them as sidebar folders or whatever rather than menu things.
Title: Re: New revs - Public comments
Post by: live627 on December 25th, 2011, 06:02 AM
What's the point of using an array for a post error if it isn't run through sprintf()? Currently only tag errors get such treatment. (C&P error, I assume)
Title: Re: New revs - Public comments
Post by: live627 on December 28th, 2011, 10:28 AM
Bump
Posted: December 28th, 2011, 10:23 AM

Also, I think I found a bug with either the CSS parser or the caching subsystem. I have a stylesheet with my plugin that uses $here. Well, that variable spits out the correct path.  Isn't it supposed to give the URI?
Title: Re: New revs - Public comments
Post by: Nao on December 28th, 2011, 10:44 AM
I don't understand your bumped question. Line numbers and files please?

$here spits out the relative path from the cache folder to wherever your skin file is (for images in the same folder). Iirc because I'm on my iPod.
Title: Re: New revs - Public comments
Post by: live627 on December 28th, 2011, 10:58 AM
I found the issue. $boarddir uses backslashes but dirname($file) has forward slashes.
Quote from Nao on December 28th, 2011, 10:44 AM
I don't understand your bumped question. Line numbers and files please?
Post.php, line 410. Does it make more sense for that to use sprintf()?
Title: Re: New revs - Public comments
Post by: Nao on December 28th, 2011, 12:35 PM
Yes, it does -- $post_errors can still contain arrays as filled in by Class-Editor.php with the 'mismatched_tags' type.
However, there IS an error indeed -- missing_tags is no longer a valid error, which I forgot to remove from that. After thinking it through, I decided to merge the methods for mismatched_tags and long_message, and thus I rewrote every area that filled in long_message, and put it into a sub-array instead. This makes for a cleaner code. (Hopefully it'll work... :P)

As for $here, does that still mean there's a bug for me to fix...?
Title: Re: New revs - Public comments
Post by: Nao on December 28th, 2011, 01:42 PM
So... I made a quick benchmark with script positioning, and here are my (non-scientific) results:

- all browsers pretty much execute the stuff in the same time. So the time before .load() is available remains the same, whatever the method used.

- IE6 benefits from having scripts at the bottom, because it's so slow at executing JS, and running jQuery + script in the head slows it down by a second or two... :( So, I've disabled it for IE6, it'll always execute below.

- IE7, IE8 and IE9 give similar results in both situations.

- Same for Chrome, Firefox 3 and Safari.

- Opera looks clearly better with the scripts at the top, plus it probably fixes the occasional FOUC I would get (only in admin pages). So it's definitely staying this way for Opera (i.e. always at the bottom, except if user is logged in and came recently.)

Interestingly, the YSlow tool recommends having the scripts at the bottom -- but wherever I have them, it still gives me an A ranking for that category. It probably 'understands' that some scripts can't be put at the bottom (which is actually completely untrue, given what I managed to do with SMF/Wedge, but whatever.)
Title: Re: New revs - Public comments
Post by: live627 on December 29th, 2011, 05:23 AM
Quote from Nao on December 28th, 2011, 12:35 PM
As for $here, does that still mean there's a bug for me to fix...?
Yes. Actually, the problem seems to be in Load.php, where $sane_path is defined. Replacing it with $pluginsdir solves the problem.
Posted: December 28th, 2011, 11:36 PM
Quote
I'm counting on you to check this out
Will do later tonight
Posted: December 29th, 2011, 01:51 AM

Flawless! Actually, I tested only the post area. My plugin can now use a dynamic string in place of %1$s. :D I use post_post_validate to extend $post_errors, which isn't run in preview mode[1].
 1. Neither does pre_post_validate.
Title: Re: New revs - Public comments
Post by: Nao on December 29th, 2011, 02:35 PM
so...
Quote from live627 on December 29th, 2011, 05:23 AM
Quote from Nao on December 28th, 2011, 12:35 PM
As for $here, does that still mean there's a bug for me to fix...?
Yes. Actually, the problem seems to be in Load.php, where $sane_path is defined. Replacing it with $pluginsdir solves the problem.
I see. But from what I see, it's simply $pluginsdir with '\' turned into '/' (i.e. Windows paths to Linux paths.)
I'm not familiar with that part of the code, as Pete wrote it as part of his plugin code.
Can you suggest a fix that would only deal with $here...? Like, in Subs-Cache.php:

Code: [Select]
$final .= str_replace('$here', '..' . str_replace($boarddir, '', dirname($file)), file_get_contents($file));

Into something like...

Code: [Select]
$final .= str_replace('$here', '..' . str_replace(str_replace('\\', '/', $boarddir), '', dirname($file)), file_get_contents($file));

(I don't know if that's what causes trouble to you. And maybe dirname($file) also needs to be rewritten...?)
Quote
Flawless! Actually, I tested only the post area.
I doubt anything will break because I definitely double-checked all of my changes, but never say never...
Quote
My plugin can now use a dynamic string in place of %1$s. :D
And everyone's happy!
Title: Re: New revs - Public comments
Post by: live627 on December 30th, 2011, 02:05 AM
That would work and fix the issue, but I'd like to fix the *real* problem, which is as I described above.
Title: Re: New revs - Public comments
Post by: Nao on December 30th, 2011, 06:44 AM
I'm not sure. Pete? Peeete...?
Title: Re: New revs - Public comments
Post by: Nao on December 30th, 2011, 01:47 PM
Okay, so, to elaborate: I don't know *why* $sane_path is set at all. I suspect that Pete had issues with his plugins on his local install. But, OTOH, I also have no idea how this has any influence on $here, which is why I don't feel comfortable tackling this problem. So, maybe my 'fix' would be just a quick hack that needs to be removed later, but at least it wouldn't break anything...

Ah, well... I have a strange feeling that I'm on my own, these days... :(
I'm working on rev 1231, and Pete's last commit (apart from rev 1183 that consisted in adding a semi-colon) was rev 1168, back in November 17. That's 6 weeks and 60+ revisions without a commit. A new record I'm afraid...

Maybe we should start giving SVN commit access to some people... Because at the current pace, even with me spending my entire Christmas holidays on Wedge, it won't be out before 2014... :^^;:
Title: Re: New revs - Public comments
Post by: Arantor on December 30th, 2011, 02:43 PM
Quote from Nao on December 30th, 2011, 01:47 PM
Okay, so, to elaborate: I don't know *why* $sane_path is set at all. I suspect that Pete had issues with his plugins on his local install. But, OTOH, I also have no idea how this has any influence on $here, which is why I don't feel comfortable tackling this problem. So, maybe my 'fix' would be just a quick hack that needs to be removed later, but at least it wouldn't break anything...
OK, the point of $sane_path is to cope with the fact that PHP on Windows sometimes issues \ in the path strings and sometimes uses / as well; the idea is that it should be consistently using the same both ways (i.e. always using /) because that works on Windows.

Oh, I remember now why I did it. When doing error reporting, and using the path of the file-causing-error for discovery purposes, debug_backtrace() always returns it with / even if on Windows, so I made it so it was stored up front with that in.



Yes, I'm sorry that I haven't committed much, but the last few months have been shitty for me (death of two family members in six months, another family member with dementia), and given that right now I'm trying to prevent a breakdown of a 10 year relationship which may or may not end up with me splitting up with my partner (which will entail me moving out, selling my house and finding somewhere to live etc.)... plus stuff going on with my consulting clients, you can probably imagine that it's not exactly the best time for me to be doing anything.

There is a part of me that thinks I should probably resign at this point, actually, and clear the way for someone who can properly devote time and energy to this project. Especially because of comments like this(http://www.blocweb.net/index.php?topic=1157.msg5322;topicseen#msg5307), makes me wonder if I'm really not suited to doing this sort of thing anyway.
Title: Re: New revs - Public comments
Post by: Nao on December 30th, 2011, 04:32 PM
So... How would you solve that...?



Yup, I remember our PMs (sorry I didn't follow up on the last one but it started to be taxing even on me... :sob:), and I deeply sympathize with you. Things are happening, not all them good. I would perfectly understand that you'd want to resign, however I'd rather you choose to be seen as 'on hiatus'.

Bloc-- don't bother with him, he's too unstable emotionally. How many times have we had to deal with his issues? How many times did he start getting angry at us because we weren't enthusiastic about one of his endeavours? I'm not saying we're better than he is, but when I see him think that he's "the better skilled one" (same topic) and complain about our reception (let's be clear: he's referring to my saying I'd already gone through this path(http://wedge.org/pub/6271/logo-madness/msg267379/#msg267379), which was far from being insulting!), and as a result he asked for his account to be removed from Wedge for the Nth time... Meh, he's got his issues, and he's certainly not in a position to tell you what you are and what you can do.

One thing he's true about, on that topic, is that you can't expect to get anything in return from working on SMF-related projects. I already experienced that with Aeva, now with Wedge... I probably should have gone to WordPress, but love has its reasons that reason doesn't know... I made my peace with that idea long ago!
Title: Re: New revs - Public comments
Post by: live627 on January 13th, 2012, 03:26 AM
Quote
updated visible copyright dates. Not brave enough to update every file in distribution so left it purely at the publicly visible dates
I know you're brave enough :)
Title: Re: New revs - Public comments
Post by: Arantor on January 13th, 2012, 03:41 AM
Not brave enough right now. Today's been an... interesting day.
Title: Re: New revs - Public comments
Post by: Nao on January 13th, 2012, 08:07 AM
I'll do a sitewide global replace if you want.

Congrats on your return!
I will have made a total of 67 consecutive commits, my personal record. 81 if not counting your single-character commit of a semi-colon ;)
Title: Re: New revs - Public comments
Post by: Arantor on January 13th, 2012, 08:10 AM
Yeah, it needs to be done, but there's no hurry...
Title: Re: New revs - Public comments
Post by: Nao on January 13th, 2012, 08:12 AM
Priority should be on fixing skin_folders for now.
Title: Re: New revs - Public comments
Post by: Nao on January 14th, 2012, 11:14 AM
Looking through my Apache error log... Interesting things to be found, including PHP errors that aren't reported on screen.

I noticed that one: it seems that sometimes, $_SERVER['HTTP_HOST'] isn't even set at all... cleanRequest() relies on this on a couple of occasions (and also once in Errors.php, at least.)
Any idea why this shouldn't be set at all...? And in this case, what could it be replaced with...?
Title: Re: New revs - Public comments
Post by: Arantor on January 14th, 2012, 04:36 PM
Quote
$_SERVER['HTTP_HOST'] isn't even set at all...
What page(s) is that being requested on?

The only time that it shouldn't be being set is if the user is using HTTP/1.0 not 1.1 and you're using very specific configuration in the webserver itself so that you're using virtual management through IP address, not name based (and/or only have one site on the server so it doesn't matter what you do, you end up on the site anyway)
Title: Re: New revs - Public comments
Post by: Nao on January 14th, 2012, 05:33 PM
Among other things it's used to re create the current URL... pretty urls etc.
Title: Re: New revs - Public comments
Post by: Arantor on January 14th, 2012, 11:51 PM
Quote from Lurker on January 14th, 2012, 04:36 PM
What page(s) is that being requested on?
I don't care so much *why* it's used. I want to know where you're calling where it isn't being logged.
Title: Re: New revs - Public comments
Post by: Nao on January 15th, 2012, 12:38 AM
As mentioned above...?
Title: Re: New revs - Public comments
Post by: Arantor on January 15th, 2012, 02:39 AM
That's the point, it tells me nothing.

All of the $_SERVER['HTTP_*'] items are directly injected into $_SERVER from the request headers. That means either something is *removing it* from $_SERVER when it shouldn't be, or it's not being passed down through the chain between browser and PHP (i.e. either the browser isn't sending it, or it's not being passed onwards properly between Apache and PHP)

The chain is broken. I can't diagnose the end of the chain without seeing more of it...
Title: Re: New revs - Public comments
Post by: Nao on January 15th, 2012, 09:54 AM
I don't know. The error appeared twice in my log in November (early and late), IIRC. It's not THAT important... Let's just put that aside and deal with it if it happens again.
Title: Re: New revs - Public comments
Post by: ethankcvds on January 20th, 2012, 07:16 PM
Quote from Nao
- Removed MegaVideo from Aeva's video site list. In case you didn't hear on the news, it would seem that they're gone for good... (Subs-Aeva-Sites.php)
I have the feeling that they might be back up sometime in the future. http://blogs.wsj.com/tech-europe/2012/01/20/spanish-anger-at-fbi-megaupload-closure/
Title: Re: New revs - Public comments
Post by: Dismal Shadow on January 20th, 2012, 07:54 PM
No domian yet but...http://109.236.83.66/
Title: Re: New revs - Public comments
Post by: Nao on January 20th, 2012, 08:03 PM
It's a fake site, AFAIK... IP was already circulating this morning, with the same stupid content.
Title: Re: New revs - Public comments
Post by: Aaron on February 9th, 2012, 09:53 PM
Quote from Nao
* The musical chairs commit. $theme (a local variable) becomes $th, while $settings becomes $theme and $modSettings is renamed to $settings. This is because $modSettings never made sense, as it didn't represent "modification settings", but instead Wedge/SMF's general settings. (207 files, not gonna list any. Pretty much all PHP files in Wedge.)
Hurray!
Quote from Arantor
(Yes, Core Features is NOW GONE FROM SVN :D And note that this is still a WIP so things can and will change.)
Hurray!
Title: Re: New revs - Public comments
Post by: live627 on February 10th, 2012, 01:02 AM
Quote
+ Added the two new hooks to the known hooks list, and removed the old core features hook from it. I wasn't sure about the sections to file them in, so I did my best to make a guess. (ManagePlugins.php)
This deserves a high-five. First commit from Nao regarding plugins/hooks. Well done! ;)
Title: Re: New revs - Public comments
Post by: Arantor on February 10th, 2012, 01:14 AM
It's not the first commit from Nao regarding hooks. Nao was the one who added the facility for hooks to be able to load files, and to fix the bugs in the initial versions of add_integration_function in SMF where sometimes you'd end up with things being registered when they weren't supposed to be.
Title: Re: New revs - Public comments
Post by: Nao on February 10th, 2012, 12:23 PM
Yeah absolutely, I even added the first new hooks back then... And then when Pete started coding the plugin system, it went totally out of my hands and became a much more extensive hook system ;) But using hooks as replacements for file edits was one of our strongest feelings about Wedge. I mean, we really, REALLY wanted to have this and disable file edits as much as possible.

Pete, while I'm at it. Your moderation code (which is looking great!) has a "matching" feature. I noticed that the only difference with "regex" is that it makes sure the text "starts" with the regex. Wouldn't it make more sense to ensure it starts AND ends with it...? (^this$) Or, just change the text string to say "starts with regex"...?
Title: Re: New revs - Public comments
Post by: Arantor on February 10th, 2012, 12:52 PM
Quote
Or, just change the text string to say "starts with regex"...?
That's what 'begins' is supposed to do, so yeah, I forgot the $.
Title: Re: New revs - Public comments
Post by: Nao on February 10th, 2012, 01:16 PM
I'll add it in my next commit if you want. Otherwise I'll leave it to you. Not done with my current work on other things, and I have to eat etc etc...
Title: Re: New revs - Public comments
Post by: Arantor on February 10th, 2012, 01:22 PM
I'll fix it locally, I have other stuff to add yet ;)
Title: Re: New revs - Public comments
Post by: TE on February 15th, 2012, 03:46 PM
related to: Tweaked auto-suggest

is the new auto-suggest capable to use qoutes inside a member's name?

please check http://dev.simplemachines.org/mantis/view.php?id=4940
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 03:54 PM
While my testing wasn't what could be called thorough, it does seem to work as expected. I created a new user, test3, whose display name is test3 "testing" test, and I was able to send that message just fine, with all behaviour exactly as expected.
Posted: February 15th, 2012, 03:50 PM

Though, looking at it, I think somewhere we broke something, I go to a profile, and 'send a message' just goes to the base send-PM page, no user id is being passed.
Posted: February 15th, 2012, 03:53 PM

That is, going through the menu; the send-PM link in the personal info area is fine.
Title: Re: New revs - Public comments
Post by: Nao on February 15th, 2012, 04:42 PM
@TE> Didn't touch these areas, so if Wedge doesn't do it already, it won't do it more now.

@Pete> I hope you don't mind -- I was fixing something in the ManageModeration template, and started finding some JS that's not formatted in the way I'm doing it, and I'm a bit anal when it comes to this... Even though most of my writing standards are due to the ability to compress data even further, and it's not the case in inline JS, but I like having it done consistently thoughout the project. Is it okay with you if I commit my changes...?

Re: user ID, never looked into this... I'll do it as soon as I'm done.
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 05:15 PM
Feel free to modify the JS any way you see fit - as long as it works afterwards ;)
Title: Re: New revs - Public comments
Post by: Nao on February 15th, 2012, 05:25 PM
Yeah it works, I'm just wary it'll break any of your local changes...

Among the things I changed:

- A class="hr" doesn't need to declare disabled, it's done by sbox automatically,
- I added a couple of data-hide's
- Replaced text-align styles with left/right/center classes.
- Some .show()/.hide() combinations were turned into .toggle()
- Removed {} when there's only one line. I don't like this jQuery "habit" :P
- Used bindEvents at one point, instead of reproducing the function. I just modified bindEvents to allow passing specific DOM elements to it.

Which also led me to notice that I'd left alone an annoying thing in Wedge's CSS -- the over-use of .lefttext and such, instead of .left... So I'm in the process of changing all templates to harmonize this. I guess it will break some areas (only when it comes to alignment, obviously) because I'm doing it quickly, but for what I've seen, it works fine.
Posted: February 15th, 2012, 05:23 PM

(:edit: Added a couple of items)
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 05:29 PM
Quote
- A class="hr" doesn't need to declare disabled, it's done by sbox automatically,
Cool, wasn't sure exactly what it did or didn't do.
Quote
- I added a couple of data-hide's
With the result that a selectbox now has a pre-filled value where it wouldn't have had one before? I've been careful with that, to make sure things have a forced empty value to work with, most importantly the selectbox that's populated with the list of rule types (name="condtype") because if it's not done that way, it's actually going to break functionality. As is the one at the top (name/id="action"), they're implicitly supposed to have a default empty value so that the user *has* to do something with them before they can proceed.
Quote
- Replaced text-align styles with left/right/center classes.
Cool.
Quote
- Some .show()/.hide() combinations were turned into .toggle()
Which ones? With some of them, there's no certainty over whether the content is hidden or shown, and it needs to be pushed to a specific state.
Quote
Removed {} when there's only one line. I don't like this jQuery "habit"
I always forget whether JS supports this syntax or not :/
Quote
Used bindEvents at one point, instead of reproducing the function. I just modified bindEvents to allow passing specific DOM elements to it.
I was gonna ask you about that, actually.
Title: Re: New revs - Public comments
Post by: Nao on February 15th, 2012, 05:36 PM
Quote from Arantor on February 15th, 2012, 05:29 PM
Quote
- A class="hr" doesn't need to declare disabled, it's done by sbox automatically,
Cool, wasn't sure exactly what it did or didn't do.
It does everything (you don't need to set a blank value either, although it's also the case on anything that's set to disabled ;)), it just is underused in Wedge now that I've replaced most of the calls with data-hide ;)
Quote
Quote
- I added a couple of data-hide's
With the result that a selectbox now has a pre-filled value where it wouldn't have had one before?
No no. It doesn't change a thing... data-hide will simply mark the item to not show up in the list. It's one of these neat little 'extra' sbox features I'm proud of :)
Quote
I've been careful with that, to make sure things have a forced empty value to work with, most importantly the selectbox that's populated with the list of rule types (name="condtype") because if it's not done that way, it's actually going to break functionality.
It only broke because I'd removed the empty value on the data-hide. After noticing that it showed an area it shouldn't, I quickly restored the empty value and all was well.

BTW, that UI is really cool :) It's like a conversation between the admin and the website...! Or a wizard, if you like!
Quote
Quote
- Some .show()/.hide() combinations were turned into .toggle()
Which ones? With some of them, there's no certainty over whether the content is hidden or shown, and it needs to be pushed to a specific state.
.toggle(true) = .show()
.toggle(false) = .hide()
.toggle(hello) = {
  if (hello)
    .show()
  else
    .hide()
}
Quote
I always forget whether JS supports this syntax or not :/
It does. Actually, I'd tend to say that JS supports more quirks than PHP does. I'd love to be able to do ($something = $param || 0) in PHP... :P (Well, it's just an example. Of course PHP has default values for function parameters, but it'd be nice to have it everywhere.)
Quote
I was gonna ask you about that, actually.
See, you didn't even have to :)
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 05:57 PM
Quote
you don't need to set a blank value either, although it's also the case on anything that's set to disabled
Well, I had trouble with val("") to force it to be reset at one point which is why one of the selects got an option with value 0 even though it would never be actually used for anything.
Quote
No no. It doesn't change a thing... data-hide will simply mark the item to not show up in the list. It's one of these neat little 'extra' sbox features I'm proud of
I was concerned that it would break things, because there is more than one place where a default value should be thrown at the user so they have to do something but it looks like it all works properly :)
Quote
It only broke because I'd removed the empty value on the data-hide. After noticing that it showed an area it shouldn't, I quickly restored the empty value and all was well.
Yeah, it's funny like that, though I need to change some of the code slightly as it happens because that screenshot showed me an interesting bug from the code, not a hard one to fix though.
Quote
BTW, that UI is really cool  It's like a conversation between the admin and the website...! Or a wizard, if you like!
Thanks :) That's really the point: there's no other way I could think of doing this than as a wizard type deal, simply because of the complexity involved in getting all the information required. The only decision was whether to string it out over several pages or do it all in JS in the one page.
Quote
.toggle(true) = .show()
.toggle(false) = .hide()
.toggle(hello) = {
  if (hello)
    .show()
  else
    .hide()
}
See, I forget stuff like that. It doesn't help that I haven't touched jQuery much in the last 3 months, I've been working mostly in Impact which is a very different beast, though it does all kinds of neat stuff with classes and extending thereof.
Quote
I'd love to be able to do ($something = $param || 0) in PHP
As an expression? What should that expression mean logically? (Seems to me like it means $something = (bool) $param)
Quote
Well, it's just an example. Of course PHP has default values for function parameters, but it'd be nice to have it everywhere.
Oh, essentially being shorthand for $something = isset($param) ? $param : 0, I see. The thing is, JS has a very different idea of what a variable is compared to PHP and I think I prefer PHP's idea in that direction.
Title: Re: New revs - Public comments
Post by: Nao on February 15th, 2012, 10:45 PM
Quote from Arantor on February 15th, 2012, 03:54 PM
Though, looking at it, I think somewhere we broke something, I go to a profile, and 'send a message' just goes to the base send-PM page, no user id is being passed.
Posted: February 15th, 2012, 03:53 PM

That is, going through the menu; the send-PM link in the personal info area is fine.
Okay fixed, thanks!
Posted: February 15th, 2012, 10:37 PM
Quote from Arantor on February 15th, 2012, 05:57 PM
I was concerned that it would break things, because there is more than one place where a default value should be thrown at the user so they have to do something but it looks like it all works properly :)
There are probably dozens of places where sbox broke something. That's what public beta testing is for ;)
Quote
See, I forget stuff like that. It doesn't help that I haven't touched jQuery much in the last 3 months, I've been working mostly in Impact which is a very different beast, though it does all kinds of neat stuff with classes and extending thereof.
Hey I'm the front-end guy, I'm not expecting you to delve into JS on a daily basis :P
Quote
Quote
I'd love to be able to do ($something = $param || 0) in PHP
As an expression? What should that expression mean logically? (Seems to me like it means $something = (bool) $param)
Would be the equivalent of... Hmm...
$something = isset($param) ? $param : 0;
More importantly, it also sets the fallback variable type. i.e. if you have "undefined || false", it the final variable will be a boolean, not undefined.
Quote
Oh, essentially being shorthand for $something = isset($param) ? $param : 0, I see. The thing is, JS has a very different idea of what a variable is compared to PHP and I think I prefer PHP's idea in that direction.
I just never was fond of isset()... Even in later versions of PHP, they added "?:", which is a nice idea, but WHO will use that anyway? Since it doesn't work on variables you're not sure have been initialized...
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 10:51 PM
Well, I haven't seen any other places where it's broken but I guess I can give it some testing; I'm on my Mac for the rest of the evening (because my PC currently can't play DVDs, and I got the Buffy collection today!) and I have MAMP on there so I can install it.
Quote
More importantly, it also sets the fallback variable type. i.e. if you have "undefined || false", it the final variable will be a boolean, not undefined.
*nods* It's a nice shortcut, however I guess I prefer the more thorough requirement with isset().
Title: Re: New revs - Public comments
Post by: Nao on February 15th, 2012, 11:06 PM
Are you planning to watch all 7 seasons of Buffy for the foreseeable future...? :^^;:

Really, don't bother testing. I don't think there are any important places where I missed it.
Title: Re: New revs - Public comments
Post by: Arantor on February 15th, 2012, 11:24 PM
No, I'm just planning to watch an episode or two a day. Mind you, if I can find a *good* SVN client, I can develop on here as well.

(I already have Komodo Edit but it should be quite easy to make Notepad++ work)
Title: Re: New revs - Public comments
Post by: Aaron on February 19th, 2012, 10:50 PM
Quote from Nao
! Tahoma is not always installed on Linux. (index.css, Wine/index.css)
Cheers for fixing that. :)
Title: Re: New revs - Public comments
Post by: Nao on February 19th, 2012, 11:50 PM
I'd rather have feedback on the new 'reset' keyword you know :niark:

(Woohoo I'm so happy it's finally in... Now it's become much easier to make child skins, because you can simply inherit everything, and if you have a single element like a header that you'd like to redo entirely, you can just reset it and not have to worry about Wedge making further changes to the parent skin... :))
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 03:21 PM
Re:

! Thoughts were using the wrong permissions for 'any', no such permission as 'moderate', since there's either 'moderate_forum' or 'moderate_board', and nothing else magically defines 'moderate' on its own. (Ajax.php)

--> I'm not exactly sure the changelog relates to what was actually committed... There was a single change in that file -- a 'moderate' instead of 'moderate_forum' (and yes, it's certainly my fault), but it doesn't change anything else (including the other 'moderate' permission test...)
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 05:28 PM
I only noticed that one check against 'moderate', which is a permission that doesn't exist, I didn't see any other checks.

Re 'any', it does sort of fall into the own/any convention that permissions have, users can alter their own but only moderators can alter anyone else's.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 05:36 PM
Quote from Arantor on March 29th, 2012, 05:28 PM
I only noticed that one check against 'moderate', which is a permission that doesn't exist, I didn't see any other checks.
Err, can you look into rev 1522? It looks like the exact same thing to me...?
i.e. I did a search on allowedTo('moderate') BEFORE updating my copy, and it found two entries in the file. Your commit only fixed one. That's why I'm reporting it...
Quote
Re 'any', it does sort of fall into the own/any convention that permissions have, users can alter their own but only moderators can alter anyone else's.
I still don't get what it has to do with Ajax.php and the single change you made to it...?
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 05:58 PM
In absence of having a real 'own/any' pair of permissions, it's using 'is it the owner' or 'can they moderate the forum'. That's really what I'm stating there, it made sense in my head >_>

Egad, I need sleep *yawn*
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 06:01 PM
But it's not something you fixed is it?
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 06:16 PM
No, all I did was make moderate_forum be the equivalent of the 'any' permission if there were actually such permissions.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 06:41 PM
It's like we're both deaf and we keep pretending we can hear each other... :lol:
OMG I'm sorry! Let's just say my English is not good enough to convey what I wanted to ask ;)
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 06:55 PM
It's OK, I'm too zombified from walking around miles and miles of Brighton trying to take pictures to think too clearly anyway >_>
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 07:24 PM
Are you closer to Brighton now than when you used to be in HH?
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 07:27 PM
Only a few minutes closer by train. Where I get on the train now is merely one stop further down the London-Brighton line. But I wanted to get out, get some fresh air, even some sunlight, and road-test my camera. Good afternoon of walking but I must have walked about 5 miles in total and I'm just not used to it.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2012, 07:39 PM
Every time Milady and I see the English countryside on tv is like playing a drinking game. We just love 'la campagne... Anglaaaaaaaise !', as we say for fun. It's got a little green something that we just don't have here in France. We love to walk around in the countryside :)
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2012, 08:08 PM
I'm trying to do that a bit more, hence tromping around Brighton today. Photos are in the process of being uploaded in an experiment trying out Tumblr.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2012, 10:20 AM
Site is updated.

Just two minor tidbits:

- you called the unique key in categories 'id_cat', but yesterday you called the exact same unique key in board 'board_id'... :P

- since you're using date_offset_get(), shouldn't you pass to it... date_create()? Like, date_offset_get(date_create()). I know the date_offset_get page has an example that uses your syntax, but I'm just saying... Semantically, it feels more logical... :^^;:

Seen your tumblr. You could have shared the URL here, eh? ;) It's pretty good.
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2012, 11:15 AM
Hmm, wasn't there already another index called id_board though? I can't remember.

date_offset_get is a synonym of one of the DateTime methods, yes, I suppose I could use date_create but I was in a bit of a hurry last night. There are also so many methods and aliases that it's genuinely confusing as to which to use when.

I will link my Tumblr when I decide how best to do so, thinking I might put it in my sig ;)
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2012, 11:25 AM
Nope, no such id_board index, at least in install.sql and in my database...
I understand your issue with aliases eheh. I'd just recommend renaming the code, although obviously it will do exactly the same, but it tickles me ;)

Also. Working on the board creation bug. (Having new boards breaking the *entire* forum until I fix them in phpmyadmin isn't exactly cool...)

The bug is two-fold: member groups and pretty URLs.

I fixed the PURL bug a few minutes ago -- it was a sad, a very sad typo (a forgotten backslash) which broke the URL generation code for boards, and worst of all -- that particular piece of code wasn't even needed...

So I'm working on member groups and, wow. It seems that there's a minor difficulty.
Wedge, like SMF, initializes the member_groups field to '-1,0' by default.
Then SMF will do this:

Code: [Select]
// Who's allowed to access this board.
if (isset($boardOptions['access_groups']))
{
$boardUpdates[] = 'member_groups = {string:member_groups}';
$boardUpdateParameters['member_groups'] = implode(',', $boardOptions['access_groups']);
}

Only, Wedge no longer has this. Because it uses a new table with the same data (for access), it directly fills in the data in the table, and ignores the member_groups field in the boards table, which may or may not break the board access system. Actually, I don't know... But if it isn't used anymore, maybe this field should be removed entirely...?
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2012, 11:28 AM
Primary access to boards is handled through the separate table, sure. But in Load.php there is some code that actually relies on member_groups being set in the boards table to set some parameters for board privacy. I don't know if you plan to reuse that or rework it in light of topic privacy or not, so I didn't remove it but there is a note above it asking whether that should be removed.

If *that*'s removed, then the entire structure of member_groups can go from the boards table.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2012, 12:27 PM
Are you talking about that bit?

Code: [Select]
// !!! Are we still meant to be using this now we have query_see_topic ? It's going to be inaccurate!

If yes -- it's probably something I added from noisen. It uses the (older) topic privacy format for boards. And yes, it's not 'inaccurate' per se because it's mainly of use in case topic privacy is set to inherit the board privacy setting. Other than that... Well, yes it can go, it's only a UI thing at this point.
Posted: March 30th, 2012, 12:18 PM

Hey, I think you rewrote the board privacy feature in Load.php... That bit with switch ($board_info['privacy'])... It gives you away because I never use switch() in my code :P

The only feature that board privacy has, that isn't in your implementation, is friends. But because it's a pretty basic thing to implement in the user-group mindset, it can go easily. It just won't be 'available' to users right now...
I think I'll you play with removing the code because, basically, I'm getting short on time today.
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2012, 12:33 PM
I only rewrote it insofar as it would actually not throw fatal errors to non admins ;)

I'm thinking this should be converted to a setting stored in the boards table, rather than implied or inferred from the (old) groups setup. I'm wary of touching it because I'm not quite so sure how you want to set it up ultimately, and I have other things to play with today anyway.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2012, 12:50 PM
How come it would be wrong to use the board access table to emulate this anyway...?
If you don't want to show it to guests, remove -1 from the list... If you want to restrict it from access to group 4, add 4 to the deny list... It seems to me that it is a more efficient way of dealing with it than mine.

The only thing that's missing is an "easy UI", e.g. when creating a board, it should offer to have either a simple or complex membergroup list, and in simple mode it should have models -- "Only my groups", for instance, would only give access to user groups that you own, i.e. no guests and regular members and non-personal/non-hidden groups...
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2012, 12:53 PM
Doing it off groups is an inference, it's also not possible to infer 'friends' from that either, assuming you wanted to do that, nor is it possible to infer 'just me' or 'everyone' without guessing or coming up with some magic state to refer to these. Much better would simply be to define a value in the boards table to indicate that board's default privacy, which avoids any risk or inference being wrong, and it's almost certainly faster too.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2012, 01:09 PM
Quote from Arantor on March 30th, 2012, 12:53 PM
Doing it off groups is an inference, it's also not possible to infer 'friends' from that either, assuming you wanted to do that,
Any first group created by anyone would be called 'Friends' by default. Or 'Contacts', I'm not sure. I suspect that people would never create more than one group anyway. (How many of you with a FB account have *several* friend lists...? It'd be interesting to know. I have a few, but I know it took me years to get there.)
Quote
is it possible to infer 'just me' or 'everyone' without guessing or coming up with some magic state to refer to these.
How so...? board_access doesn't support that?
Quote
Much better would simply be to define a value in the boards table to indicate that board's default privacy, which avoids any risk or inference being wrong, and it's almost certainly faster too.
How faster would it be, since you need to join the board_access table anyway..?
Posted: March 30th, 2012, 01:08 PM

(I love it how Wedge auto-fixed the mismatched tags when I changed them in quick edit. That one is mine, too, IIRC :P)
Title: Re: New revs - Public comments
Post by: nolsilang on March 30th, 2012, 01:23 PM
Quote from Nao on March 30th, 2012, 01:09 PM
Any first group created by anyone would be called 'Friends' by default. Or 'Contacts', I'm not sure. I suspect that people would never create more than one group anyway. (How many of you with a FB account have *several* friend lists...? It'd be interesting to know. I have a few, but I know it took me years to get there.)
I have several friend list, to differentiate school friends(High School,University) Work friends(former,current) Online Game Friends(several title).

If you talked about forum groups. I'm using groups to categorize member that enrolled on same year(it's university forum). I think it's standard use.
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2012, 01:31 PM
Quote
How so...? board_access doesn't support that?
How can it, when it is view/enter per group per board. There's absolutely no way using the groups table to work out 'just me' or 'everyone', unless you override a board's access by being an admin or board owner, and everyone is only inferrable if it contains every group, and then if you add a new group, you have to remember to add that group to that board, by which time it isn't 'everyone' but 'everyone who was here when I set it up' (sort of)
Quote
How faster would it be, since you need to join the board_access table anyway..?
No, you don't, not necessarily. The list of boards you can see and access is calculated and cached ready for use, which is done to avoid that join.
Title: Re: New revs - Public comments
Post by: Nao on March 31st, 2012, 02:50 PM
Quote from Arantor on March 30th, 2012, 01:31 PM
How can it, when it is view/enter per group per board. There's absolutely no way using the groups table to work out 'just me' or 'everyone', unless you override a board's access by being an admin or board owner,
Which is the case... I mean, why waste time reading another table when you know it's your topic...?
Quote
and everyone is only inferrable if it contains every group,
Everyone really is a meta-group for 'guests and members alike'...
If you mean 'all of my custom groups', then yes, board access has to be updated later. I don't know about the best solution for that. Except another meta-group, of course...
Quote
Quote
How faster would it be, since you need to join the board_access table anyway..?
No, you don't, not necessarily. The list of boards you can see and access is calculated and cached ready for use, which is done to avoid that join.
Hmm, it's something that can't really be done for topics, unfortunately...
Title: Re: New revs - Public comments
Post by: Arantor on April 19th, 2012, 11:51 PM
Quote
A tiny fix for French. Note to self and Pete: seriously, 30+KB is too large for the index language... It should only hold the most commonly used text strings, and certainly not things like a merge topic feature description... If anything, index.english.php should be short and easy to translate, so that we can have obscure translations that deal with at least the most common strings. (index.french.php)
Why the fuck is that string there? I certainly didn't put it there.

Mind you, this is related to what I've been saying about splitting some of those files - the view I hold is that index should hold stuff that's used everywhere or on the 'majority' of pages. Stuff in topics, for example, would be OK there.
Title: Re: New revs - Public comments
Post by: Nao on April 21st, 2012, 08:14 PM
Quote from Arantor on April 19th, 2012, 11:51 PM
Why the fuck is that string there? I certainly didn't put it there.
Neither did I :)
It was already in SMF2, if you want to have a look!
Quote
Mind you, this is related to what I've been saying about splitting some of those files - the view I hold is that index should hold stuff that's used everywhere or on the 'majority' of pages. Stuff in topics, for example, would be OK there.
Yup.
Thanks for doing it in the latest rev, BTW...!

I just have a note about the moderation filter for link count... They won't take [URL] tags into account, will they...? i.e. they're case-sensitive here. Is it as desired?
Title: Re: New revs - Public comments
Post by: Arantor on April 21st, 2012, 08:47 PM
Yes, it will. First thing it does is strtolower the string.
Title: Re: New revs - Public comments
Post by: Nao on April 21st, 2012, 09:04 PM
Oh sorry, missed that :)

I'm currently looking into the index language file. (Also translated the moderation filter stuff.)
It's very interesting... There are plenty of strings that simply aren't used anymore in Wedge (and probably in SMF too), and they're still in the index file...
Obviously I'm removing them, but we'll have to be careful whether or not they were actually used by modified in such a way that they can't be found with a simple search on the name :)

For instance, $txt['time_offset'] is no longer used anywhere but in the Profile template, so I'm moving it over there.
Also, template_profile_timeoffset_modify() seems to be a leftover from the previous system. Did you keep it "just in case" or was it an oversight?
Title: Re: New revs - Public comments
Post by: Arantor on April 21st, 2012, 10:06 PM
The thing about legacy strings is that they're sometimes used in composite form elsewhere e.g. $txt['something_' . $something] so while it might not be obviously used, it may end up being used anyway, as you mentioned, though some of them will just have to be tested to see if the string isn't used, heh.

The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.
Title: Re: New revs - Public comments
Post by: Nao on April 21st, 2012, 10:09 PM
Quote from Arantor on April 21st, 2012, 10:06 PM
The thing about legacy strings is that they're sometimes used in composite form elsewhere e.g. $txt['something_' . $something]
That's what I mentioned in the changelog... And that's after checking for multiple possible composites, really.
Quote
so while it might not be obviously used, it may end up being used anyway, as you mentioned, though some of them will just have to be tested to see if the string isn't used, heh.
I think SMF is wayyyyyyyyy too cool when it comes to outdated strings... The move to SMF 2.0 wasn't smooth.
Quote
The time offset stuff is deprecated, but I didn't remove it pending finishing (or reverting) the timezone stuff.
Okay. And not need to remove it... Tss :P
Title: Re: New revs - Public comments
Post by: Arantor on April 21st, 2012, 10:17 PM
No, the move to 2.0 wasn't pretty, I wasn't involved but I was aware that 1.1 used numeric indexes and that there's even hints of that still in Wedge (e.g. the movetopic strings I moved yesterday, being numbered 1 through 4)

But either way, we're definitely moving in the right direction.
Title: Re: New revs - Public comments
Post by: Nao on April 22nd, 2012, 12:01 AM
Yup... And there are even more useless entries in index. You have no idea the number of crap that should be in Login.language.php for instance... :^^;:

Oh, and this $txt['times'] thing... Another generic thingy that isn't used anywhere, to my surprise. (Feel free to double-check.)
It also has a $txt['attach_times'] entry that has the same content. (Very smart...)
So I removed both 'times', and made a single string for both attach_downloaded and attach_viewed or whatever.
Then I figured, okay what about adapting it for "Viewed 1 time"... Instead of "Viewed 1 times"...
So I changed it to attach_viewed_n and attach_viewed_1. But in French, times is 'fois', which is both singular and plural, and I don't want to have to set a dummy attach_viewed_1 for it just because it'll show the English version instead...
Reminds you of the month days, doesn't it...?
I think maybe there's an issue in how we're handling number_context. Maybe we should use an array for every single entry... I know, doesn't sound great, and it may actually slow down Wedge (by a few microseconds), but I don't know how to do it otherwise.
Title: Re: New revs - Public comments
Post by: Aaron on April 22nd, 2012, 12:12 AM
I'm glad to see you guys tackling these internationalisation-related issues, really. :)
Title: Re: New revs - Public comments
Post by: Nao on April 22nd, 2012, 12:27 AM
(BTW, your ManageTopics files were in Windows CRLF format. I tend to double-check for new files so I caught it and fixed it. Try and have your notepad app generate LF files by default :))
(Also, maybe it should be renamed to Topics.language.php?)
Posted: April 22nd, 2012, 12:14 AM

Oh and thanks Aaron. Pete is all the more commendable for this because by definition his native language doesn't require any work :P
I'm still lazy enough that I only deal with stuff that makes Wedge better in French. Just like Spip (my fave French CMS which I used back in 2003) had excellent French support.
Title: Re: New revs - Public comments
Post by: Arantor on April 22nd, 2012, 01:31 AM
Oh, sorry, yeah, this is a mostly new install of Notepad++ which I forgot to reconfigure for LF only. When I first made the file I actually called it SplitTopics because it was just the stuff for SplitTopics.php (namely splitting and merging) but then I moved the topic-moving stuff in as well.

Thing is, it's totally related to managing topics, rather than topics in general, hence the name.

And thanks Aaron :) Certainly I find that I forget some things, notably dates and times which Nao's done a lot of work on, but for the rest of the things out there, I've got a fair idea of how I think it has to work to actually be meaningfully suited to i18n, and the biggest thing is tackling these awkward composite strings where a single line is made out of $txt['something'], $variable, $txt['something_else'], because that causes so many problems!

I am aware though that some of my moderation filters UI won't work properly in RTL because of the way it builds certain strings but I figure to a point we'll deal with that when there are people around who actually use an RTL language and can be best placed to tell us how it has to work. I'm not familiar enough with other languages to make that much of a call on it.

And actually while my native language doesn't require me to think outside the box in terms of phasing out composite strings and bringing in sprintf type strings, it does make me acute of how to cope with multiple languages at once, and I'm still not sure how exactly I want to handle English US vs English UK though I know I will want to do just that. (It makes me chuckle that phpBB has the exact opposite problem, having a strong British heritage)

Without wishing to sound like I'm taking a cheap shot at SMF (because I'm not), I'm a bit concerned how they're planning to solve this fundamental problem in the future. I can't remember when it was logged on the tracker, but AngelinaBelle (IIRC) logged an issue to deal with these composite strings, and the general approach was to create multiple forms of the relevant words for composite elements, so when you had some of these, you'd have multiple different words depending on the context, e.g. $txt['members_normative'] and $txt['members_declarative'] which in English would be the same string but would be different strings in other languages, I think it was talking about German.

But instead of doing that, I figured it's simply cleaner and easier (if very slightly slower) to create the complete string so you always have the term in relevant context.

Still, it's not like XenForo or other systems where we put it all in the DB...
Title: Re: New revs - Public comments
Post by: Nao on April 22nd, 2012, 04:00 PM
Quote from Arantor on April 22nd, 2012, 01:31 AM
Oh, sorry, yeah, this is a mostly new install of Notepad++ which I forgot to reconfigure for LF only.
Hey yeah, it's not a problem :) I did my share of CRLF commits too...!
Quote
Thing is, it's totally related to managing topics, rather than topics in general, hence the name.
For now it's okay, even though I moved SendTopic strings there.
Quote
and the biggest thing is tackling these awkward composite strings where a single line is made out of $txt['something'], $variable, $txt['something_else'], because that causes so many problems!
Yep, and sometimes it's annoying to find some generic strings that are found across different files used in multiple strings...

BTW, you didn't tell me whether you thought it'd be best to rewrite number_context to use an array directly?
Oh and we could for instance put a string instead of an array, and that would mean 'no special treatment' (i.e. always '_n'), meaning that instead of doing sprintf() on strings, we could directly call number_context even if we don't have special treatment for them in French or English -- because it doesn't mean other languages won't need it...

Also -- I looked into loadLanguage and it has an oddity.
loadLanguage('index+Errors') would be an acceptable call. It will explode the string and deal with both language files.
However:
- it could benefit from being turned into an array parameter, like loadSource etc...
- currently, $already_loaded stores the entire string in its cache. Meaning that if we did loadLanguage('index') and then someone did loadLanguage('index+Errors'), the index file would be loaded a second time. It can be fixed by moving the caching operations to within the foreach, and using a continue; instead of a return $lang, but I don't know if it's acceptable to you...?
Quote
I am aware though that some of my moderation filters UI won't work properly in RTL because of the way it builds certain strings but I figure to a point we'll deal with that when there are people around who actually use an RTL language and can be best placed to tell us how it has to work.
Certainly. I know that Wedge's skins are currently not set up for RTL use at all... It may work. Then again it may not.
Quote
e.g. $txt['members_normative'] and $txt['members_declarative'] which in English would be the same string but would be different strings in other languages, I think it was talking about German.
Which is what was done after I requested to have $txt['reply'] disambiguated because it was used both as a verb and as a noun... :)
Quote
But instead of doing that, I figured it's simply cleaner and easier (if very slightly slower) to create the complete string so you always have the term in relevant context.
It's not always going to be possible though, e.g. 'reply' is too short for that. :)
Quote
Still, it's not like XenForo or other systems where we put it all in the DB...
Even THAT..?! Hmm...
I'm not convinced that performance-wise, it's a good idea to put into the DB whatever you're simply going to retrieve later without any sorting work... I mean, SMF/Wedge has the settings table to load entirely, but even that is cached to file, as you kindly reminded me a few days ago... :lol:
Posted: April 22nd, 2012, 02:25 PM

Something else... MoveTopic.php does, in a few occasions, load the default language for a file, just to retrieve a string in particular, and then reverts to the user's preference.
However, it 'simply' reloads the file without a second thought about the static cache.
I think it should reload by doing loadLanguage('File', '', false, true) (i.e. $force_reload = true and $fatal = false), don't you agree?

:edit: Forget what I said -- since it stores the latest language loaded in the static cache, then it will automatically continue loading the file. :)
Posted: April 22nd, 2012, 02:46 PM

BTW-- index.english.php went from 32KB to 27KB in size... And I'm not even finished!
An incredible amount of data really shouldn't have been in there in the first place ;)
Title: Re: New revs - Public comments
Post by: Aaron on April 22nd, 2012, 10:22 PM
Quote from Nao on April 22nd, 2012, 04:00 PM
Also -- I looked into loadLanguage and it has an oddity.
loadLanguage('index+Errors') would be an acceptable call. It will explode the string and deal with both language files.
However:
- it could benefit from being turned into an array parameter, like loadSource etc...
Yes, please! That's how it should've been done in SMF, too. (I like how PHP 5.4 will allow you to write loadLanguage(['index', 'Errors']), too.)
Title: Re: New revs - Public comments
Post by: Nao on April 23rd, 2012, 04:39 PM
Committed that today :)
How do you like all the changes?
Hopefully I didn't break anything... I changed so many things...

Oh, and I'm not sure about the short notation... Not because I don't like it, but because I don't see anyone using a PHP 5.4-only feature (that otherwise will break a site) in generic software (i.e. not stuff you write for yourself) for many years...
Title: Re: New revs - Public comments
Post by: Aaron on April 23rd, 2012, 09:17 PM
Haven't had time to look into things at all, sorry. It's on my to do list ...
Title: Re: New revs - Public comments
Post by: Nao on April 23rd, 2012, 09:21 PM
Eh, you don't have any obligations to Wedge... ;)
Title: Re: New revs - Public comments
Post by: Arantor on April 25th, 2012, 06:42 PM
It's nice to see loadLanguage using arrays :)
Quote
BTW, you didn't tell me whether you thought it'd be best to rewrite number_context to use an array directly?
Oh and we could for instance put a string instead of an array, and that would mean 'no special treatment' (i.e. always '_n'), meaning that instead of doing sprintf() on strings, we could directly call number_context even if we don't have special treatment for them in French or English -- because it doesn't mean other languages won't need it...
Actually it could be better to use an array like that. The thing is, the sprintf does actually inject the value in, so even on _n cases you'd still have to always inject it, no?


Regarding 5.4's inclusion of array syntax... it's an interesting choice but one that I personally would have put into PHP sooner if given a choice, putting it at a .x release makes that quite hard for a language construct; things like namespaces in 5.3 is a feature not a language construct and it's not so hard to get your head around that as a requirement. But as a language construct, I think it should have been pushed into the next major release, not a minor one, personally.
Title: Re: New revs - Public comments
Post by: Aaron on April 25th, 2012, 07:44 PM
Not sure where to post this, but can I just say I like having the action buttons below the posts? It could do with some more tweaking (the 'more' menu is empty for me now, for instance), but it's a promising move, I think. :)
Title: Re: New revs - Public comments
Post by: Arantor on April 25th, 2012, 07:46 PM
Hmm, I thought it was a bug originally >_> I guess I'm not yet adjusted to it, and I'm not entirely sure I like it yet, but maybe it'll grow on me. Especially since the checkbox for it is kept separate now from that menu making it even more weird for me. :/
Title: Re: New revs - Public comments
Post by: Nao on April 26th, 2012, 05:04 PM
Quote from Arantor on April 25th, 2012, 06:42 PM
It's nice to see loadLanguage using arrays :)
Indeed!
Is there anything left with a '+' syntax in Wedge...? I don't think so, but...
Quote
Actually it could be better to use an array like that. The thing is, the sprintf does actually inject the value in, so even on _n cases you'd still have to always inject it, no?
I have no idea what you mean, sorry.
Quote
Regarding 5.4's inclusion of array syntax... it's an interesting choice but one that I personally would have put into PHP sooner if given a choice, putting it at a .x release makes that quite hard for a language construct; things like namespaces in 5.3 is a feature not a language construct and it's not so hard to get your head around that as a requirement. But as a language construct, I think it should have been pushed into the next major release, not a minor one, personally.
Given how many years happen between each major release, I think it's safe to say that PHP 5.4 is a major update -- if only because it'll break stuff and server admins will take 10 years to install it, blah blah...
Posted: April 26th, 2012, 05:03 PM
Quote from Aaron on April 25th, 2012, 07:44 PM
Not sure where to post this, but can I just say I like having the action buttons below the posts? It could do with some more tweaking (the 'more' menu is empty for me now, for instance), but it's a promising move, I think. :)
Thanks :)
As for the More menu, I need to look into that...
Currently I'm fighting against an attempt at rewriting the button icon code. I hate CSS precedence... >_<
Title: Re: New revs - Public comments
Post by: Arantor on April 26th, 2012, 07:39 PM
I didn't think there were any left anyway, I thought the only use was index+Modifications, which I killed a bit back anyway.
Quote
I have no idea what you mean, sorry.
You can't do some magic to 'no special cases' and magically expect _n to just work. Let's go back to your suggestion:
Quote
Oh and we could for instance put a string instead of an array, and that would mean 'no special treatment' (i.e. always '_n'), meaning that instead of doing sprintf() on strings, we could directly call number_context even if we don't have special treatment for them in French or English -- because it doesn't mean other languages won't need it...
There is no way that can work without using sprintf on that string. Unless the string doesn't have the number in it in the first place, the whole point is that a _n number string will still have %1$s in it somewhere to indicate where the number will be injected (and it will be s not d because it will be injected as a string)

_1 cases may well have 1 in it and not have any need to inject a number, as well as _0 cases might avoid it by being 'No ... found' or whatever, so there won't be a number. But _n cases will have a number that needs to be added, so it has to be sprintf'd.
Quote
Given how many years happen between each major release, I think it's safe to say that PHP 5.4 is a major update -- if only because it'll break stuff and server admins will take 10 years to install it, blah blah...
That's the thing, PHP 5.4 isn't a particularly major update compared to 5.3. And already I gather 5.4.1 is out.
Title: Re: New revs - Public comments
Post by: Nao on April 27th, 2012, 04:55 PM
Quote from Arantor on April 26th, 2012, 07:39 PM
I didn't think there were any left anyway, I thought the only use was index+Modifications, which I killed a bit back anyway.
There were half a dozen or so left in the overall codebase.
Quote
You can't do some magic to 'no special cases' and magically expect _n to just work.
Hmm, with all due respect, did you look at my commit...? Because it returns a sprintf'ed string every time, even if the string isn't an array... (Which basically means, "it's _n all the way.")
Title: Re: New revs - Public comments
Post by: Arantor on April 27th, 2012, 04:59 PM
Quote
Hmm, with all due respect, did you look at my commit...? Because it returns a sprintf'ed string every time, even if the string isn't an array... (Which basically means, "it's _n all the way.")
No, I was responding to your comment, which seemed to imply that sprintf wasn't needed, and I wasn't sure how the code seemed relevant as it seemed to be discussing something not yet entirely implemented.

In any case I have a lot going on in my head right now, making it hard to cope with the fact that in between trying to work on Wedge, I'm also trying to learn Node.js[1] + Socket.IO + Express + MongoDB for something I need to build, plus some other stuff going on that is... complicated, so I do miss a lot of the subtlety, even though I have looked over the commits lately.
 1. Holy fuck this is a piece of work, even without the nightmare that is their module manager
Title: Re: New revs - Public comments
Post by: Nao on April 27th, 2012, 05:50 PM
Looks fun...
Anyway, number_context() works just fine, don't worry :)

And node.js, given all the coverage it got, I assumed it was less 'geek-oriented' than it seemed.
Title: Re: New revs - Public comments
Post by: Arantor on April 27th, 2012, 05:58 PM
Oh, it's quite geek orientated to do properly.

Consider that everything you do has a callback function. Want a DB query? Issue the query and handle content in a callback. Want to do another query as a consequence of that one? In that callback, issue the next one and deal with the response in another callback.

It quickly gets... interesting.
Title: Re: New revs - Public comments
Post by: Nao on April 28th, 2012, 12:27 PM
So... About the new blog style...

- I actually liked the earlier one, but that's because I'm crazy, don't worry about me. Mainly, I want the post width to be approx. the same as in display mode, because blog posts can be fine-tuned to the pixel, and it's always best to have a consistent width on them. Of course, I could apply some restrictions by CSS, or simply take from my Noisen templates...
- The view count... Wouldn't it be best next to the reply count? I don't know.
- This is unrelated to the style, but it looks like blog posts are ordered by last answer -- and it actually gives the last post's date as the original post date in the header... (Just have a look at the dev blog :))
Title: Re: New revs - Public comments
Post by: Arantor on April 28th, 2012, 02:17 PM
Well, it was annoying me that we had about a 1/3 of the area tied up with an almost entirely empty pair of table cells, which were legacy and needed to be moved somewhere.

Actually, as far as the view vs reply count, I figured that the view count was only of modest importance and thus fitted in small writing next to extra information rather than being as prominent as at the foot of the post (i.e. where you read the post then press reply to it or to see the comments) Can try moving it if you want, no big deal.

In that case, check the board's configuration and check you set the default ordering correctly ;)
Title: Re: New revs - Public comments
Post by: willemjan on April 28th, 2012, 03:06 PM
I'm not sure what you guys have done, but this site allways looked great on my phone. Today well errr lets say it did not. It seems to have shrinked in width or something?

Edit to add: Got an HTC Desire with Android
Title: Re: New revs - Public comments
Post by: NeobeatIKK on April 29th, 2012, 01:42 AM
Wow guys, you don't leave a detail flying around. :cool:
Title: Re: New revs - Public comments
Post by: Nao on April 29th, 2012, 08:19 AM
Quote from Arantor on April 28th, 2012, 02:17 PM
Well, it was annoying me that we had about a 1/3 of the area tied up with an almost entirely empty pair of table cells, which were legacy and needed to be moved somewhere.
Then are you annoyed too at the extra space left by the sidebar in long pages...?
(Heck, I could very well set up the sidebar so that it's a float and thus allows the page to extend, but I'm not a big fan of the idea of not letting the user control the maximum width of a post, at least per page...)
Quote
In that case, check the board's configuration and check you set the default ordering correctly ;)
Default ordering? There's default theme, default language, but no default ordering, is there...?
Title: Re: New revs - Public comments
Post by: Nao on April 29th, 2012, 08:21 AM
Quote from willemjan on April 28th, 2012, 03:06 PM
I'm not sure what you guys have done, but this site allways looked great on my phone. Today well errr lets say it did not. It seems to have shrinked in width or something?
Shrunk where?
There's a default mobile theme. You can change it if you don't like it... But seriously, I don't understand how you could find the desktop version to be more desirable (for an HTC Desire) than the wireless skin, which is precisely geared towards improving readability and usability...
Heck, I can't live without it now.
Title: Re: New revs - Public comments
Post by: Arantor on April 29th, 2012, 02:36 PM
Quote from Nao on April 29th, 2012, 08:19 AM
Quote from Arantor on April 28th, 2012, 02:17 PM
Well, it was annoying me that we had about a 1/3 of the area tied up with an almost entirely empty pair of table cells, which were legacy and needed to be moved somewhere.
Then are you annoyed too at the extra space left by the sidebar in long pages...?
(Heck, I could very well set up the sidebar so that it's a float and thus allows the page to extend, but I'm not a big fan of the idea of not letting the user control the maximum width of a post, at least per page...)
Quote
In that case, check the board's configuration and check you set the default ordering correctly ;)
Default ordering? There's default theme, default language, but no default ordering, is there...?
I actually have the sidebar at the bottom because I don't have my browser at full size (it would look a bit silly in other sites to run at 1920 wide)

As far as ordering, there isn't a UI for it, just as there isn't a UI to determine whether a board is a blog or not. However, in the boards table there is the sort_method and sort_override columns, sort_method defaults to last_post (order by last post in a topic) with the direction being set as naturally descending.

The override part allows four options: ascending/descending and natural/forced. Natural means that it defaults to whichever you've set of asc/desc, but forced means that it only allows that order and sort method.

Sorting method can be based on subject (alphabetically), starter, last poster (both by user name IIRC alphabetically), number of replies, number of views, and first post and last post. Blogging, typically, would use first post rather than last post.
Title: Re: New revs - Public comments
Post by: willemjan on April 29th, 2012, 04:12 PM
Quote from Nao on April 29th, 2012, 08:21 AM
Quote from willemjan on April 28th, 2012, 03:06 PM
I'm not sure what you guys have done, but this site allways looked great on my phone. Today well errr lets say it did not. It seems to have shrinked in width or something?
Shrunk where?
There's a default mobile theme. You can change it if you don't like it... But seriously, I don't understand how you could find the desktop version to be more desirable (for an HTC Desire) than the wireless skin, which is precisely geared towards improving readability and usability...
Heck, I can't live without it now.
See attaches.
Title: Re: New revs - Public comments
Post by: live627 on April 29th, 2012, 07:38 PM
You gotta be more specific.
Title: Re: New revs - Public comments
Post by: willemjan on May 1st, 2012, 05:20 PM
Well, for one the menu is not looking good. There is an gap at the right, and the register button is on an new line. Thats what I mean with shrinked, at first, it was just 1 line.

I also miss the date and time of the post. I'm not sure if this is an bug, or intended, but I just really miss it.

Things get more messy when I log in.
Title: Re: New revs - Public comments
Post by: Arantor on May 1st, 2012, 05:42 PM
What does it look like when signed in?
Title: Re: New revs - Public comments
Post by: live627 on May 1st, 2012, 10:25 PM
Quote
I also miss the date and time of the post. I'm not sure if this is an bug, or intended, but I just really miss it.
Isn't it on the top right of the post?
Title: Re: New revs - Public comments
Post by: Nao on May 3rd, 2012, 08:11 PM
In Xml.template.php, there's a template_results function... It's apparently an Ajax return function for search results.
However, it's never used in Wedge. It's actually used for remote searches on the SMF official website (Admin.php in SMF2), but never here.

I'm going to remove it, but I'd like to know if there's any reason to keep it in...

Also, I'd like to merge QuoteFast.php (5KB) into Ajax.php, and possibly JsModify.php (12KB) as well. I don't see much of a reason to multiply files that are of such a small size... It's alright for big files like Search.php/Search2.php, but other than that, considering we gave up on the idea of automatic action file discovery...
Posted: May 3rd, 2012, 08:05 PM
Quote from Arantor on April 29th, 2012, 02:36 PM
I actually have the sidebar at the bottom because I don't have my browser at full size (it would look a bit silly in other sites to run at 1920 wide)
Same here. I have the sidebar enabled in Opera, with my list of tabs, because with 736 tabs (as of now...), it's definitely impossible to use the horizontal tab bar for switching between tabs.
Heck, I absolutely hate Google for removing their vertical tabs sidebar, because it was actually usable at the time... It was a bit buggy, but removing it also removed my interest in Chrome entirely. (Heck, now I do my Chrome testing under... Maxthon Webkit, because it's got a more usable tab UI.)
Quote
As far as ordering, there isn't a UI for it, just as there isn't a UI to determine whether a board is a blog or not.
Yeah, there's also plenty of other options that are missing some kind of UI... Eh. (Mostly mine :P)
Quote
However, in the boards table there is the sort_method and sort_override columns, sort_method defaults to last_post (order by last post in a topic) with the direction being set as naturally descending.
(Modified after your post. Seems to work now.)
Quote
Sorting method can be based on subject (alphabetically), starter, last poster (both by user name IIRC alphabetically), number of replies, number of views, and first post and last post. Blogging, typically, would use first post rather than last post.
Before we forget -- when we add UI for choosing blog types, it should act as a 'template' like in the custom fields, i.e. it'll automatically set up other things in the page but users will be free to change them... I suppose that's how you envisioned it, too?
Title: Re: New revs - Public comments
Post by: Arantor on May 3rd, 2012, 08:12 PM
If it's not used for anything other than receiving those results, get rid of it because we don't need it.

As far as multiplying small files goes, it's a tricky one. Certainly for such things it would be faster to have the small files for specific actions rather than big files containing everything (because that all still has to be loaded and parsed even if not run).

In hindsight it was one of the things I didn't like about SimpleDesk in the end was putting all the AJAX stuff into a single file, when all the AJAX code was all called for every action even if only part of it was ever used. There is a part of me that would prefer to break things down where there's no commonality to code (if they don't have any shared code, split 'em up) but I can see the argument about fewer files too.

One thing I would say at this juncture is that I would quite like to split Aeva-Gallery up a bit. Loading all that code for every single action=media item (including items, previews, albums, etc.) is heavy.
Quote
Same here. I have the sidebar enabled in Opera, with my list of tabs, because with 736 tabs (as of now...), it's definitely impossible to use the horizontal tab bar for switching between tabs.
I've been working with ~50 tabs lately where I've been trying to piece together stuff on Node.js etc. but 700 tabs is insane!
Quote
Before we forget -- when we add UI for choosing blog types, it should act as a 'template' like in the custom fields, i.e. it'll automatically set up other things in the page but users will be free to change them... I suppose that's how you envisioned it, too?
Pretty much, yes.
Title: Re: New revs - Public comments
Post by: Nao on May 3rd, 2012, 08:16 PM
Quote from willemjan on May 1st, 2012, 05:20 PM
Well, for one the menu is not looking good. There is an gap at the right, and the register button is on an new line. Thats what I mean with shrinked, at first, it was just 1 line.
The menu issue is not an issue at all. Making the text bigger makes it easier to tap an option...
Also, the menu width always depends on how many items are in there. And it depends on whether you're logged in or not, and whether you have access to all options, etc...
Quote
I also miss the date and time of the post. I'm not sure if this is an bug, or intended, but I just really miss it.
It's still there. This is apparently a bug in your browser, as it shows up right-aligned next to the user name. Your browser seems to cut off the post right there... :-/
Title: Re: New revs - Public comments
Post by: Nao on May 3rd, 2012, 08:28 PM
Quick bug... Admin area > Search for 'post' > First result says "Array" (it's actually the option for signature_minposts). Looks like it's trying to echo an array...
Quote from Arantor on May 3rd, 2012, 08:12 PM
If it's not used for anything other than receiving those results, get rid of it because we don't need it.
Yup... We can always restore it later, although I doubt it. Saved 1.5KB off the 10KB filesize.
Quote
As far as multiplying small files goes, it's a tricky one. Certainly for such things it would be faster to have the small files for specific actions rather than big files containing everything (because that all still has to be loaded and parsed even if not run).
Yeah, it's perfectly true, and that's why I'm not sure about JsModify, but QuoteFast isn't used a lot I'd say, and other Ajax functions are the same... And I don't think that technically 10KB or 15KB isn't going to change the parsing time a lot. (It's not even an extra 5KB because there's the Wedge file header...)

Or perhaps we could add prefixes to the Ajax files? Ajax-QuoteFast, Ajax-JsModify...
Quote
In hindsight it was one of the things I didn't like about SimpleDesk in the end was putting all the AJAX stuff into a single file, when all the AJAX code was all called for every action even if only part of it was ever used. There is a part of me that would prefer to break things down where there's no commonality to code (if they don't have any shared code, split 'em up) but I can see the argument about fewer files too.
Let's say that we should try to keep files split up when we determine they're used relatively a lot, or they're very resource-intensive.
Quote
One thing I would say at this juncture is that I would quite like to split Aeva-Gallery up a bit. Loading all that code for every single action=media item (including items, previews, albums, etc.) is heavy.
I suppose so. Especially since it has its own folder anyway... It could be done. And it'd be a good idea to rename 'Aeva-Gallery2' or 'Subs-Aeva' to some self-explained names...
Quote
I've been working with ~50 tabs lately where I've been trying to piece together stuff on Node.js etc. but 700 tabs is insane!
Meh. About 200 of them are 'quick tabs' that I just don't have time to read... About 300 are late answers to Wedge.org... Things I promised myself I'll answer (and never will, of course.)
Title: Re: New revs - Public comments
Post by: Arantor on May 3rd, 2012, 08:48 PM
Quote
Yeah, it's perfectly true, and that's why I'm not sure about JsModify, but QuoteFast isn't used a lot I'd say, and other Ajax functions are the same... And I don't think that technically 10KB or 15KB isn't going to change the parsing time a lot. (It's not even an extra 5KB because there's the Wedge file header...)

Or perhaps we could add prefixes to the Ajax files? Ajax-QuoteFast, Ajax-JsModify...
QuoteFast is used any time you press quote to insert it into the editor. There's two sets of circumstances it can be called - either to insert from main display into quick reply, or to insert from the summary of topic into the main reply. Probably more than you'd suspect.
Quote
I suppose so. Especially since it has its own folder anyway... It could be done. And it'd be a good idea to rename 'Aeva-Gallery2' or 'Subs-Aeva' to some self-explained names...
That's the big one that occurs to me, anyway.
Quote
Meh. About 200 of them are 'quick tabs' that I just don't have time to read... About 300 are late answers to Wedge.org... Things I promised myself I'll answer (and never will, of course.)
Heh, I do know what you mean, though in my case all my tabs are passive ones that I'm keeping open until I've finished with the information therein.
Title: Re: New revs - Public comments
Post by: Nao on May 6th, 2012, 01:41 AM
Hey guys! Now here's for a good opportunity to use the Like system: since you can't post in the New Revs topic, you can share your satisfaction with a given commit by 'liking' it :)
(Don't 'like' a technical boring commit though, as I'll know you're just trying to make me feel good... :P)

Now for a good suggestion too... Should likes be disabled if a topic is locked? My gut feeling is 'no'.
Quote from Arantor on May 3rd, 2012, 08:48 PM
QuoteFast is used any time you press quote to insert it into the editor. There's two sets of circumstances it can be called - either to insert from main display into quick reply, or to insert from the summary of topic into the main reply. Probably more than you'd suspect.
I don't use it much, really.
Quote
Quote
I suppose so. Especially since it has its own folder anyway... It could be done. And it'd be a good idea to rename 'Aeva-Gallery2' or 'Subs-Aeva' to some self-explained names...
That's the big one that occurs to me, anyway.
And I suppose you're expecting me to find the names...... :lol:
Quote
Heh, I do know what you mean, though in my case all my tabs are passive ones that I'm keeping open until I've finished with the information therein.
Easy to say, cowboy! You read faster than your shadow... :P
Title: Re: New revs - Public comments
Post by: Arantor on May 6th, 2012, 03:33 AM
Quote
Now for a good suggestion too... Should likes be disabled if a topic is locked? My gut feeling is 'no'.
It wouldn't be a big deal to make a Likes configuration page which allows for disabling likes entirely (which of course has performance benefits if you don't want such things), to cover whether likes should be allowed on locked topics or not, or whether you're allowed to like your own posts or not, or even whether it is only allowed on the first post of a topic, or all posts.
Quote
I don't use it much, really.
No, neither do I, but I understand a lot of users do.
Quote
And I suppose you're expecting me to find the names......
Oh, I can sit and do it sometime but I don't know Aeva nearly as well as I'd like.
Quote
Easy to say, cowboy! You read faster than your shadow...
I know I'm not nearly as awesome as her shadow(http://www.youtube.com/watch?v=JGCsyshUU-A#ws), but it's not a case of reading, it's a case of actually finding the bloody information I need first and then actually being able to apply it. Most of what I have in tabs is stuff I don't need immediately but will very shortly.
Title: Re: New revs - Public comments
Post by: live627 on May 6th, 2012, 06:51 AM
Cowboy?? Am I missing something?
Title: Re: New revs - Public comments
Post by: Nao on May 16th, 2012, 09:55 AM
Oh crap, I don't know what to answer to Pete's post... :^^;:

John, it's just a reference to Lucky Luke(http://en.wikipedia.org/wiki/Lucky_Luke)...

Re: thoughts, indeed $last_thought was an error on my part.
Also, it's amusing that you put id_master and id_parent into a variable - I did the same yesterday ;) Hadn't come to commit yet though... It's part of my process to attempt to show 'clean' thoughts after a reply.
Title: Re: New revs - Public comments
Post by: Nao on May 16th, 2012, 06:10 PM
Quote from Nao on May 16th, 2012, 09:55 AM
Re: thoughts, indeed $last_thought was an error on my part.
I take that back... :P
$last_thought = id_thought.
I'm doing strlen($last_thought) because that's what it looks like when it's serialized... (I know it's a bit odd to do a search on a serialized array, but it's always going to be stored the same way, so why bother...)
Title: Re: New revs - Public comments
Post by: Arantor on May 16th, 2012, 06:12 PM
Searching on a serialised array is not unheard of. I just got really confused with what the search was trying to do, since it looked to me like it was searching for the string itself, not for the id for it.
Title: Re: New revs - Public comments
Post by: Nao on May 16th, 2012, 06:22 PM
Nope, it wasn't... :)

Yet, I still have issues with my current work on this... I'm trying to get Wedge to correctly determine that a deleted thought was deleted if it's being retrieved by a child as reference. Currently, if you delete a parent, it'll say "@> Something". Grmpf... I'd like for it to say something like "@(Deleted)> Something." Or just "Something", actually...
Title: Re: New revs - Public comments
Post by: live627 on May 31st, 2012, 12:02 AM
Quote
@ Of recent memory, this rewrite of Subs-BBC.php is my biggest disappointment... I was really hoping to optimize it a lot, until I realized it really didn't need optimizing that much. What a waste of time! Is that 'len' field really worth it..?0
Should probably keep that field. Is it tinyint(3) unsigned not nulll? IIRC, parse_bbc had several strlen calls to determine tag  length, and every little bit of savings helps, especially on large,  tag-heavy posts, right?
Title: Re: New revs - Public comments
Post by: Nao on May 31st, 2012, 04:56 PM
Quote from live627 on May 31st, 2012, 12:02 AM
Quote
@ Of recent memory, this rewrite of Subs-BBC.php is my biggest disappointment... I was really hoping to optimize it a lot, until I realized it really didn't need optimizing that much. What a waste of time! Is that 'len' field really worth it..?0
Should probably keep that field. Is it tinyint(3) unsigned not nulll? IIRC, parse_bbc had several strlen calls to determine tag  length, and every little bit of savings helps, especially on large,  tag-heavy posts, right?
Yes, it's as you describe it.
There's one call to strlen every time it matches a tag. It also adds another call in some situations later (unparsed_contents or whatever...), but in the end it'll only save time on tag-heavy posts as you said -- and even then, not THAT much..
Title: Re: New revs - Public comments
Post by: Arantor on May 31st, 2012, 04:58 PM
Every little helps though :)
Title: Re: New revs - Public comments
Post by: Nao on May 31st, 2012, 05:02 PM
Yep, sure...
But in the case of Aeva for instance, I'm still stuck with a half-baked Aeva-Embed.php+Subs-BBC.php that doesn't seem to know where it wants to go (autolink or not? should I get rid of the code I have no idea what it is doing like aeva_protection? etc.)
Title: Re: New revs - Public comments
Post by: Arantor on May 31st, 2012, 05:08 PM
Perhaps it's time we went back and looked over all the code and figured out what all of it did - including the protection code and whether it's all really necessary.

Oh, btw, I very kindly got told that, in theory, a closed bbc could accept parameters - something I've not tried but it would clean up the media bbc if it's true.
Title: Re: New revs - Public comments
Post by: Nao on May 31st, 2012, 05:30 PM
Nope. It's easy to add support for multiple params though. Well not too hard at least.
Dontforget that the quote tag has 5 entries in the list ;) it's not very flexible right now.
Title: Re: New revs - Public comments
Post by: Arantor on May 31st, 2012, 05:48 PM
I was told with some certainty that the closed tag actually supports parameters. I was sure it doesn't but the conviction behind the person who told me makes me wonder if I'm wrong...
Title: Re: New revs - Public comments
Post by: Nao on May 31st, 2012, 07:50 PM
Well... I'm perfectly willing to test again (after all, maybe this was added after 2009 or so), but how do I test for it...?
If anything, having the bbcodes in the database makes it VERY hard for me to do any testing on them... (Heck, it's happened so many times to me, I think we should have implemented this move right before going alpha, not before... :P)

I suppose the params list would be like this, but that's all I got done:

Code: [Select]
a:6:{s:2:"id";a:1:{s:5:"match";s:14:"(\d+(?:,\d+)*)";}s:4:"type";a:2:{s:5:"match";s:82:"(normal|box|av|link|preview|full|album|playlist|(?:media|audio|video|photo)_album)";s:8:"optional";b:1;}s:5:"align";a:2:{s:5:"match";s:24:"(none|right|left|center)";s:8:"optional";b:1;}s:5:"width";a:2:{s:5:"match";s:5:"(\d+)";s:8:"optional";b:1;}s:7:"details";a:2:{s:5:"match";s:97:"(none|all|no_name|(?:name|description|playlists|votes)(?:,(?:name|description|playlists|votes))*)";s:8:"optional";b:1;}s:7:"caption";a:2:{s:6:"quoted";b:1;s:8:"optional";b:1;}}

Perhaps I need to fix this code tag that doesn't behave perfectly with word-break...
Title: Re: New revs - Public comments
Post by: Arantor on May 31st, 2012, 07:57 PM
If only I'd built that configuration tool -_-

But apparently the test was carried out successfully on both SMF 1.1 and 2.0... might just be worth trying it there for now?
Title: Re: New revs - Public comments
Post by: Nao on May 31st, 2012, 08:10 PM
I just don't know if:
- it's really gonna help performance (SMF/Wedge's param tester in parse_bbc() basically does all possible permutations of all parameters, while AeMe only tests for the presence of every single param... So in the end I don't think it's better optimized...?)
- it's going to make it 'clearer' in any way. We'd still have to call aeva_showThumbnail() for any media tag...
Title: Re: New revs - Public comments
Post by: Arantor on July 4th, 2012, 05:44 PM
Loving the new popup in r1627 by the way. I like it even more than the lower-right-corner alignment (which is something I never thought would happen)

What I will do then, now we have the newer shinier version of it, is migrate the PM popup to use that - that was really what stopped me from changing the PM popup to use reqWin before was that the alignment of it seemed strange given the context, but putting it like that will work well.

I'm amused to note that some months ago I mused on doing exactly that: putting the popup info in the middle of the screen, though originally just for the PM, in http://wedge.org/pub/6943/pm-popup/msg268865/#msg268865
Posted: July 4th, 2012, 05:33 PM

One thing that does occur is that depending on what else is going on it might not be obvious enough. XenForo, for example, does their popups similarly, but adding something like a 10px border plus a massive shadow - personally I find that a bit much, but it definitely shows some contrast to the background.
Title: Re: New revs - Public comments
Post by: Nao on July 4th, 2012, 10:50 PM
Quote from Arantor on July 4th, 2012, 05:44 PM
Loving the new popup in r1627 by the way. I like it even more than the lower-right-corner alignment (which is something I never thought would happen)
Same here actually :)
But the alignment was probably something I cooked up because at the time it couldn't be dragged away.. I don't know. I think it was because of that. I think I implemented dragslide() after writing the initial code. Then I just forgot to consider centering it...
Quote
What I will do then, now we have the newer shinier version of it, is migrate the PM popup to use that - that was really what stopped me from changing the PM popup to use reqWin before was that the alignment of it seemed strange given the context, but putting it like that will work well.
Definitely.
One of my goals (which I'm unlikely to achieve though) is to ensure that as many UI elements as possible are harmonized. That would mean trying to use the same code (or at least identical CSS) for: the select box, the main menu, the mini-menu, Zoomedia, and the popups. I actually wrote all 5 of these separately, i.e. I didn't reuse any code inside another component, but right now I'm simply trying to determine whether it can be done and whether it would add to Wedge, or detract from it. The most likely candidates for merging are the main and mini menus, of course. But the mini-menus looks awfully like the popups right now. And Zoomedia is pretty much the same concept as the popup... And the select box uses a scrollbar which I could make use of in the popup. Maybe the first thing I'll try to do is split the scrollbar code from the SelectBox object into its own object (it's already done, actually, but it's an object that's internal to SB...!)
Ideally I would release the select box, zoomedia and popup code as separate components on github and offer people to help improve them (along with WeCSS). I just don't know whether it'll stick with them.
Quote
One thing that does occur is that depending on what else is going on it might not be obvious enough. XenForo, for example, does their popups similarly, but adding something like a 10px border plus a massive shadow - personally I find that a bit much, but it definitely shows some contrast to the background.
I haven't seen it in a while, but I've made the shadow a bit more obvious, and added boldness to the titles. Is that better now...?
Title: Re: New revs - Public comments
Post by: Arantor on July 4th, 2012, 11:04 PM
Quote
But the alignment was probably something I cooked up because at the time it couldn't be dragged away.. I don't know. I think it was because of that. I think I implemented dragslide() after writing the initial code. Then I just forgot to consider centering it...
Heh, I know that feeling.
Quote
One of my goals (which I'm unlikely to achieve though) is to ensure that as many UI elements as possible are harmonized.
A fine goal :) Though I wouldn't worry about trying to reuse styles - I think it might be better to keep them separate but well documented, so that a theme which wanted to change everything could do so and require a shade more work than a theme that doesn't. As long as they're consistent, they don't have to reuse code - I can see it would likely make things worse to forcibly try to reuse code like that.
Quote
Ideally I would release the select box, zoomedia and popup code as separate components on github and offer people to help improve them (along with WeCSS). I just don't know whether it'll stick with them.
I'd probably be inclined not to, not because of my usual fears etc. related to such but simply the maintenance aspect about how much work it would take to de-integrate then re-integrate it later with updates etc.
Quote
I haven't seen it in a while, but I've made the shadow a bit more obvious, and added boldness to the titles. Is that better now...?
Works for me :) It is much more clearly contrasted now :)
Title: Re: New revs - Public comments
Post by: Nao on July 5th, 2012, 12:28 AM
I can make reintegrating easier by simply splitting the stuff so that I only need to reimport the separate files... e.g. like sbox.js can be stand-alone if so desired, without any rewrites.
Title: Re: New revs - Public comments
Post by: Arantor on July 5th, 2012, 02:35 AM
That works, I guess...
Title: Re: New revs - Public comments
Post by: Nao on July 5th, 2012, 08:22 AM
Well, question is, do you have any issues with me going open source with these?
Because it'd be a way for me to test github or bitbucket or whatever... If anything, I want to release WeCSS because I think it's better than LESS or SASS (not in EVERY way but in most), and it pains me to read .Net every month and see them recommend them heartily :P
Title: Re: New revs - Public comments
Post by: Arantor on July 5th, 2012, 03:00 PM
I have no issues with them being open source, provided that you're happy to keep on top of what comes in and make sure that any changes don't conflict with what Wedge is doing, really.

I still think it's likely to eat time trying to keep everything in step if we're not careful, but other than my usual cynicism about workloads, no objections :)

I find WeCSS better than LESS to deal with.
Title: Re: New revs - Public comments
Post by: Nao on July 6th, 2012, 04:36 PM
Quote from Arantor on July 5th, 2012, 03:00 PM
I have no issues with them being open source, provided that you're happy to keep on top of what comes in and make sure that any changes don't conflict with what Wedge is doing, really.
I'm trying to find a structure that would 'work' at github... I'm sure it can be done. (An organization account for Wedge, where we'll put Wedge itself, and then I need to determine whether my own little projects will be in this account or mine.)
I probably won't post everything in a single go though -- I'm thinking of going with WeCSS or SelectBox first, and then working from there...
Quote
I still think it's likely to eat time trying to keep everything in step if we're not careful, but other than my usual cynicism about workloads, no objections :)
Yeah, it's one of my main concerns about this. But it can bring benefits. Plus, I wouldn't like someone else to fork some of these components into jQuery plugins on github, even if respecting our license terms... I'd rather host the whole thing myself :P
Quote
I find WeCSS better than LESS to deal with.
Yep :) I just don't know about the name, ah ah... I think "Wess" is probably simpler and people are going to understand it better than "Wecess", because it looks more like "Less".
I ponder for a long time over many silly things!
Posted: July 5th, 2012, 06:58 PM

Also, re: PM popup...
I just looked into it, and noticed that it calls ?action=pm, rather than a popup saying "you've got mail, suckah!"
So basically what it would do if using reqWin, would open an Ajax popup with a page that's built for fullscreen, while it should instead show a special version with, for instance, an extract of the latest PMs in it, etc...
Maybe we'll get rid of it in favor of the notification system (+ popup) later, but for now all I can suggest is adding a ";sa=popup" param to the URL and build a special version for it... Or simply link to "?action=help;in=you_ve_got_mail_suckah_no_dont_bother_looking_for_that_string"
Title: Re: New revs - Public comments
Post by: Nao on July 6th, 2012, 11:14 PM
Btw do you have an idea whether or not I should make dimming the default?
Title: Re: New revs - Public comments
Post by: Arantor on July 6th, 2012, 11:19 PM
Quote from Nao on July 6th, 2012, 11:14 PM
Btw do you have an idea whether or not I should make dimming the default?
Do it. It works very well for me.

I haven't looked at 2.1's source much (literally last looked ages ago), would rather not do so, ironically out of a weird sense of respect. I figure we branched off when we did and I've only re-incorporated stuff back in from the patches after we branched, I see it that we went our separate ways and that was that, you know?
Title: Re: New revs - Public comments
Post by: live627 on July 7th, 2012, 05:53 AM
reqWin here opens a new window. (It was DHTML yesterday, though...)
Title: Re: New revs - Public comments
Post by: Nao on July 7th, 2012, 09:13 AM
With what browser?
Title: Re: New revs - Public comments
Post by: live627 on July 7th, 2012, 10:08 PM
Quote from Nao on July 7th, 2012, 09:13 AM
With what browser?
Firefox 13
Title: Re: New revs - Public comments
Post by: Nao on July 8th, 2012, 09:53 AM
Quote from live627 on July 7th, 2012, 10:08 PM
Quote from Nao on July 7th, 2012, 09:13 AM
With what browser?
Firefox 13
It's working fine here for me....... :-/
Title: Re: New revs - Public comments
Post by: live627 on July 14th, 2012, 01:25 AM
Quote
* Changed default windowbg colors for Weaving. I like change from time to time... (index.css)
Liked the older colors better, seemed richer to me. Now they seem pale and bland[1].
 1. Could it be that I'm just really picky about color choice? Or maybe it''s my monitor...
Title: Re: New revs - Public comments
Post by: Nao on July 14th, 2012, 07:45 AM
Or maybe I have a tendency to either do Babylon ripoffs using Noisen-inspired color sets :P (Which are basically a series of color sets I build in a few minutes for fun and then offered as choices to blog creators on the site...)

I have a Samsung 971P monitor, it's a high-quality 5/4 monitor (like, one of the very last before this annoying 16/9 & 16/10 wave took over everything... Gosh where can I find 4/3 or 5/4 monitors now?!), it's pretty well known for the quality of its colors too.
I think that my IPS screen actually shows 'blander' but 'more accurate' colors than a TN screen. What's yours?
Posted: July 14th, 2012, 07:42 AM

(Also, these colors are closer to the postbg ones, I'd say.)
Title: Re: New revs - Public comments
Post by: live627 on July 14th, 2012, 09:08 AM
HP 2511 Series Wide LCD Monitor. I wanted a 4/3 but I couldn't find any that were large. :( I even looked for 16:10 but the ones I liked weren't on sale  for under $200. So it's too short for my liking (1080... only good for watching movies. But or net is so slow I cam only stream 480p... barely).

Ideally I'd want 1920 x 1440. But I haven't checked on the monitor market for over a year. Maybe I should try  Samsung. I wonder how  they compare to HP. Whatever. I'm stuck with this puppy.
Title: Re: New revs - Public comments
Post by: Arantor on July 14th, 2012, 06:16 PM
Hmm, I need to try it with both my IPS screen on my MacBook and perhaps the Samsung SyncMaster 193 I have (it runs to 1280x1024 though it's still basically 5:4 as a screen)
Title: Re: New revs - Public comments
Post by: Nao on September 4th, 2012, 11:44 PM
Sorry about the media_unseen error... It was a failed copy & paste operation, I'm afraid.

Okay, I'm nearly done with the @media query conversion process. The one thing that bothers me is that IE6/7 still don't support these, actually they do (thanks to a plugin I added on top of them), but it doesn't have any point because these browsers use a table layout for the sidebar, and thus I can't manipulate the sidebar into getting floated to the bottom. All I can do is (1) remove the padding around the window, (2) hide the sidebar entirely.
I'm not sure people would like solution 2, so I'll just stick to 1 for now.

(Uh, I could have posted this on the right topic, but it has too many unread posts right now... I try not to focus on answering posts when I'm busy with a backlog of code...)
Title: Re: New revs - Public comments
Post by: Nao on September 24th, 2012, 09:37 AM
Duplicate removal in language files: awesome :) Something I couldn't be arsed to start doing...

I think it's a good idea to turn pseudo-buttons into proper buttons, I think the point of pseudo-buttons is that people can open them in new windows or something, but really it's not that interesting and it's best to have a coherent interface.

If you look for this string in the Sources and Themes folder, you'll find more buttons that can (should?) be converted: "[<a "
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2012, 12:12 PM
Oh, I already did that. But there's a technical reason it's been done that way in the past - the point of pseudo buttons isn't really about new windows, but the fact that there's already a submit button inside the form that's involved, typically a delete button. Often that submit button belongs to a form that does processing, but where the link would go is a separate piece of code, which means far larger changes than just the HTML.
Title: Re: New revs - Public comments
Post by: Nao on September 24th, 2012, 12:14 PM
Oh, yes I see... So just forget about what I said :) I just did a quick search in case you'd forgotten something etc, like I enjoy doing... It's like a morning walk you know. Getting back into the game with checking out your commits, things like that, ain't done this in a few months, a pleasure to do :eheh:
Title: Re: New revs - Public comments
Post by: Arantor on September 24th, 2012, 12:47 PM
It's been grand getting back into the swing of things :)
Title: Re: New revs - Public comments
Post by: Nao on September 24th, 2012, 02:43 PM
It feels overwhelming, which is way better than feeling bored :P
Title: Re: New revs - Public comments
Post by: live627 on September 26th, 2012, 02:16 AM
Quote
The main reason I haven't tested it is because while I have an account that is PayPal capable, I can't pay for a subscription myself with my own account and I refuse to expect others to pay to test it on a site of mine, if that makes sense.
They have a sandbox. I would test it out if I could remember my sandbox login...
Title: Re: New revs - Public comments
Post by: Arantor on September 26th, 2012, 03:32 AM
Yeah, I knew about that, but I wasn't sure if I could actually pay myself even in the sandbox. Since there's no harm in trying... I might as well try it!

It will also let me try out a few other things that need to be experimented with, namely looking into the bug that apparently exists with failed subscription transactions that happen for no apparent reason.
Posted: September 26th, 2012, 02:27 AM

Also, the installation is currently completed broken. Moving that if() test around in Settings.php breaks the installer, because the installer now repeatedly and consistently removes the if() and the opening { of that test.

I'll fix it sometime, but I'm deep into other stuff first.
Posted: September 26th, 2012, 02:50 AM

And on a fresh install, it always seems to me that jQuery can't be loaded from Google. This has never once worked for me on any test install I've ever made, including localhost.
Posted: September 26th, 2012, 02:54 AM

Also, I have no idea how the sandbox works, especially since it doesn't seem to handle subscription payments. It seems to be geared for much larger and more complex stuff that we're trying to do.
Posted: September 26th, 2012, 03:03 AM

After struggling along with the banality of the Sandbox, it's broken. It just tells me the address for entering PayPal was wrong, but it also flags the code before my change as wrong, which suggests sandbox mode is actually broken anyway.
Title: Re: New revs - Public comments
Post by: Arantor on September 26th, 2012, 04:10 AM
OK, so after yet more digging, I find interesting things.

Recurring payments seems to be broken in SMF too.

There's still broken behaviour, but it's only partly Wedge's fault these days :P Basically, Wedge is broken right now because it always sets up the PayPal cmd as _xclick-subscriptions even when it isn't a recurring payment, so right now it will always fail. It needs to be _xclick for non-recurring and _xclick-subscriptions for recurring.

But... I just tried it on the only site I have live where I can mess about with such things, which is SMF RC3 site, and *that* fails if cmd is set to _xclick-subscriptions as well, so it's not a new issue.

I'll fix the issues I can fix my side (the template being the main one) but a more thorough debugging of PayPal is going to have to wait for another day.
Title: Re: New revs - Public comments
Post by: Nao on September 26th, 2012, 03:57 PM
Quote from Arantor on September 26th, 2012, 03:32 AM
Yeah, I knew about that, but I wasn't sure if I could actually pay myself even in the sandbox.
That's the whole point of the sandbox, actually... :)
Quote
Also, the installation is currently completed broken. Moving that if() test around in Settings.php breaks the installer, because the installer now repeatedly and consistently removes the if() and the opening { of that test.
Hmm, it's odd, did it work earlier...? Because it looks like those lines were already broken before I did my Settings.php change.. Anyway, line 1836, replace with:

Code: [Select]
// Remove the redirect (5 lines of code)...
if (trim($settingsArray[$i]) == 'if (file_exists(dirname(__FILE__) . \'/install.php\'))' && trim($settingsArray[$i + 1]) == '{' && trim($settingsArray[$i + 4]) == '}')
{
for ($j = $i + 5; $i < $j;)
$settingsArray[$i++] = '';
continue;
}

This is untested but it should work... (I'll be cooking up an even better version later today, that doesn't care about the length.)
Quote
And on a fresh install, it always seems to me that jQuery can't be loaded from Google. This has never once worked for me on any test install I've ever made, including localhost.
I've never had such any problem...?!
What's in your HTML head?
Quote
Also, I have no idea how the sandbox works, especially since it doesn't seem to handle subscription payments. It seems to be geared for much larger and more complex stuff that we're trying to do.
Ah, sorry, can't help... :(
Posted: September 26th, 2012, 03:47 PM

What about this one btw..?

Code: [Select]
// Remove the redirect (normally 5 lines of code)...
if (strpos($settingsArray[$i], 'file_exists') !== false && trim($settingsArray[$i]) == 'if (file_exists(dirname(__FILE__) . \'/install.php\'))')
{
$settingsArray[$i++] = '';
$tab = substr($settingsArray[$i], 0, strpos($settingsArray[$i], '{')); // It should normally be empty.
while ($i < $n - 1 && rtrim($settingsArray[$i]) != $tab . '}')
$settingsArray[$i++] = '';
$settingsArray[$i] = '';
continue;
}

--> basically, it just records the level of the first curly (so that we can find its closer easily), then it removes everything before the closer. (Also, the last $i call should ensure it doesn't increase it again because it's done through the for() loop... Oops.)
Title: Re: New revs - Public comments
Post by: Arantor on September 26th, 2012, 06:03 PM
Quote
I've never had such any problem...?!
What's in your HTML head?
Well, it's a fresh install, but I'll take a proper look later.
Quote
What about this one btw..?
I'm not honestly that bothered what it replaces, provided that from a fresh install it installs without having to manually hack the Settings file...
Title: Re: New revs - Public comments
Post by: Nao on September 26th, 2012, 07:59 PM
I tested my code through a file() call, and it seems to work just fine... (Phew.)
Title: Re: New revs - Public comments
Post by: Arantor on September 26th, 2012, 08:05 PM
Well, I'll do a fresh install and see what happens (which will check both issues at once)
Title: Re: New revs - Public comments
Post by: Nao on September 26th, 2012, 09:05 PM
So what's the resulting output?
Title: Re: New revs - Public comments
Post by: Arantor on September 26th, 2012, 09:35 PM
I haven't done it yet, had other things to do like eat...
Title: Re: New revs - Public comments
Post by: Arantor on September 30th, 2012, 03:31 AM
Install is currently completely broken, due to language caching - because it's trying to call updateSettings on the first pass, which of course it can't do because it doesn't have DB settings of any kind.

Guess I *really* need to set up caching now. That is, once I rebuild my installation >_<
Title: Re: New revs - Public comments
Post by: Arantor on September 30th, 2012, 04:00 AM
OK, so I've hacked together something that works for the time being.

So, the contents of my <head> is thus:

Code: [Select]
<head>
<link rel="stylesheet" href="http://localhost/wedge/css/member-chrome22-1348934260.css">
<!-- Powered by Wedge, © Wedgeward - http://wedge.org -->
<title>Localhost Wedge - Home</title>
<link rel="shortcut icon" href="http://localhost/wedge/favicon.ico" type="image/vnd.microsoft.icon">
<link rel="canonical" href="http://localhost/wedge/index.php">
<link rel="search" href="http://localhost/wedge/index.php?action=search">
<link rel="alternate" type="application/atom+xml" title="Localhost Wedge - Latest Posts Feed" href="http://localhost/wedge/index.php?action=feed">
<meta name="generator" content="Wedge">
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>
<script src="http://localhost/wedge/js/script-1348943198.js"></script>
</head>

Uncaught TypeError: Object [object Object] has no method 'sb'
Title: Re: New revs - Public comments
Post by: Arantor on September 30th, 2012, 04:38 AM
Seems that sbox.js is minified into things when jquery_origin is local but not when it isn't - at least for me.
Title: Re: New revs - Public comments
Post by: Nao on September 30th, 2012, 05:24 PM
The WEDGE_INSTALLER hack is fine, as long as we remember to remove it once your language deltas are implemented... Because at that point we won't need to cache this data, will we?
Oh yes, we'll probably still need to record the fact that a script file uses at least one language file... Hmm. It's probably better than doing one file_exists too many. But it's really micro-optimizations at this point

I don't have any problems with sbox.js myself. Are you sure you can reproduce this...?
Title: Re: New revs - Public comments
Post by: Arantor on September 30th, 2012, 05:29 PM
Quote
I don't have any problems with sbox.js myself. Are you sure you can reproduce this...?
Every fresh install reproduces this, without fail, even on a real server. Try it - grab all the files except for other/ and put them into a folder, then also grab the Settings and install files from other/ and put them in that folder, and run it.
Title: Re: New revs - Public comments
Post by: Nao on September 30th, 2012, 10:53 PM
Even with your fix..?
Title: Re: New revs - Public comments
Post by: Arantor on September 30th, 2012, 11:10 PM
It has been doing it for months on every single fresh install I perform.

The fix I've added is just enough to get through installation, it doesn't change this problem.
Title: Re: New revs - Public comments
Post by: Nao on October 1st, 2012, 07:10 PM
But I thought the problem was introduced with my updateSettings call in the language cache code..?
Title: Re: New revs - Public comments
Post by: Arantor on October 2nd, 2012, 03:01 AM
That would be the case if it weren't for the fact I'm talking about two completely different problems.

The problem of the installer crashing and burning is still related to updateSettings. The installer hack gets around that.

The problem of sbox.js being undefined on every single fresh install has been a problem for many months now. I was attempting to debug it - at which point you asked me what was in <head>, I attempted to do a fresh install to see what the state of play was, only to find it completely broken... but this problem is not resolved.
Title: Re: New revs - Public comments
Post by: Nao on October 2nd, 2012, 10:50 PM
Quote from Arantor on October 2nd, 2012, 03:01 AM
That would be the case if it weren't for the fact I'm talking about two completely different problems.

The problem of the installer crashing and burning is still related to updateSettings. The installer hack gets around that.
Not completely, though... updateSettings is called before even WEDGE_INSTALLER is defined, because the language files are loaded first. I worked around that by initializing language strings only after setting the constant, with an $init var to ensure it's only done once (because we're inside a loop at this point.)
The problem doesn't show up at first because the error message(s) (with XDebug) are shown inside an HTML tag, so you can't see them on the HTML rendition.
Quote
The problem of sbox.js being undefined on every single fresh install has been a problem for many months now.
Indeed. From what I see, it's quite simple... It never was defined at all in the add_js_file() call to script.js. I've added it, hopefully that'll fix it. I'm also adding common.css and sections.css to the loaded CSS. Can't believe I didn't even check that..?!
Quote
I was attempting to debug it - at which point you asked me what was in <head>, I attempted to do a fresh install to see what the state of play was, only to find it completely broken... but this problem is not resolved.
I don't remember asking you about head, though... Or maybe that was a long time ago?!
Another bug: the cache purge at the end of the install process still considers /cache/ to be where it can find CSS and JS files. Uh. I've fixed that... Same with the 404 redirect code in QueryString.php.
And I've set a default $theme['default_theme_url'] because it's used in loadLanguage and isn't defined during install. That one may be a SMF bug, though...! And again, the errors don't show up because they're inside a tag.

Anyway... I'm still right in the middle of all this. I'm stumped that I had so many outstanding bugs in the install script. Although it's true I haven't run it in a long time...
Caching is cool. But it really adds a lot of complexity... :)
Title: Re: New revs - Public comments
Post by: Arantor on October 2nd, 2012, 11:13 PM
Quote
Not completely, though... updateSettings is called before even WEDGE_INSTALLER is defined, because the language files are loaded first. I worked around that by initializing language strings only after setting the constant, with an $init var to ensure it's only done once (because we're inside a loop at this point.)
Odd, if that were true it should have failed before that - the error in question is that wesql doesn't exist, which is why updateSettings fails. wesql can't exist until there are DB settings and if it does work it means it's using settings it shouldn't be.
Quote
The problem doesn't show up at first because the error message(s) (with XDebug) are shown inside an HTML tag, so you can't see them on the HTML rendition.
No, I just got to a screen that only had a gradient and nothing else... ;) I couldn't even press anything to go to the next page.
Quote
I don't remember asking you about head, though... Or maybe that was a long time ago?!
It was last week - http://wedge.org/pub/feats/6803/new-revs-public-comments/msg282124/#msg282124
Title: Re: New revs - Public comments
Post by: Nao on October 2nd, 2012, 11:26 PM
I've fixed sbox.js, now it correctly applies its style to the language select box.
All that's left to fix is the CSS files showing a "../../Themes/" relative URL (i.e. one "../" too many), I must admit I don't know where to start with this one... (It's either in Subs-Cache or Class-CSS, obviously.)
Will have to wait until tomorrow...
Quote from Arantor on October 2nd, 2012, 11:13 PM
Odd, if that were true it should have failed before that - the error in question is that wesql doesn't exist, which is why updateSettings fails.
I don't know. Perhaps I'm wrong. The error I was trying to fix was the default_theme_url bug, which I fixed later by adding a proper alias for it. Perhaps moving the code around wasn't needed...

So, what you're saying is that updateSettings can be called without issues in the installer as long as wesql is loaded..? (I haven't looked into it...)
Quote
No, I just got to a screen that only had a gradient and nothing else... ;) I couldn't even press anything to go to the next page.
And the HTML had what...?
Quote
It was last week - http://wedge.org/pub/feats/6803/new-revs-public-comments/msg282124/#msg282124
Alrighty :)

Oh, I'm probably gonna have to fix language caching as well... I'm not sure... But it seems that the temp cache file for JS doesn't store the language, it always uses English strings even though my default language is French... Hmm.
Title: Re: New revs - Public comments
Post by: Arantor on October 2nd, 2012, 11:38 PM
Quote
So, what you're saying is that updateSettings can be called without issues in the installer as long as wesql is loaded..? (I haven't looked into it...)
Not entirely. The error it fails on, at the first hurdle is the wesql is not loaded. But that's symptomatic of a larger problem - it isn't going to get database settings it can actually use until the beginning of the third step (step 1 = welcome + checking for fundamentals, step 2 = gathering database settings, step 3 is getting other stuff)

That's really why I took the step I did - blocking all updateSettings calls until the very last step of the installer (which itself calls updateSettings, albeit indirectly)
Quote
And the HTML had what...?
Not a fat lot in it, seeing how it was fatally erroring out during population of the <head>. Consider the backtrace that would be occurring: a language file is loaded at the start of installation, but it fails there - the only thing that exists is the <head> tag, it's failing after the head tag is output.
Title: Re: New revs - Public comments
Post by: Nao on October 3rd, 2012, 11:44 PM
Quote from Arantor on October 2nd, 2012, 11:38 PM
Not entirely. The error it fails on, at the first hurdle is the wesql is not loaded. But that's symptomatic of a larger problem - it isn't going to get database settings it can actually use until the beginning of the third step (step 1 = welcome + checking for fundamentals, step 2 = gathering database settings, step 3 is getting other stuff)
It has other issues... Like, defining WEDGE_INSTALLER in the first few steps when they're called at the same time -- it generates a warning so I had to add a defined() test before defining it.

Also... Plenty of other little bugs. Like, in rev 1710 I committed an unfortunate change to the ban groups table structure -- by renaming id_ban_group to id_ban_id_group. Probably a failed search & replace...!

Anyway -- I've successfully installed a copy without any bugs.

I should be able to make a commit tomorrow. I'm also going to commit a few changes to Welcome.template.php -- it's been left alone for so long, it's become very ugly...

BTW would it be possible to have you write a small plugin for wedge.org...? I'd just like to move the rev.txt and Facebook code to a plugin so that it doesn't end up by mistake in our final files... ;)
That's in index.template.php, of course.
Posted: October 3rd, 2012, 11:33 PM

Any ideas how to fix that one..?

8: Undefined index: latestRealName
File: /Sources/Subs.php
Line: 1534
(And more.)

It's the common_stats code. Very likely a bug caused by updateSettings being disabled during the install process..? But it should be enabled at that point, shouldn't it...?
Title: Re: New revs - Public comments
Post by: Arantor on October 3rd, 2012, 11:56 PM
Quote
It has other issues... Like, defining WEDGE_INSTALLER in the first few steps when they're called at the same time -- it generates a warning so I had to add a defined() test before defining it.
It wasn't meant to be a final solution. I only really cared enough about it actually letting me install.
Quote
Also... Plenty of other little bugs. Like, in rev 1710 I committed an unfortunate change to the ban groups table structure -- by renaming id_ban_group to id_ban_id_group. Probably a failed search & replace...!
I did notice it threw an error but I wasn't overly bothered, knowing that the plan is to remove those anyway in the end.
Quote
BTW would it be possible to have you write a small plugin for wedge.org...? I'd just like to move the rev.txt and Facebook code to a plugin so that it doesn't end up by mistake in our final files...
Sure, just trying to work out how best to do that. What occurs to me is me is that while it's possible to insert the SVN revision, just by munging $txt['copyright'] easily enough - inserting the Facebook bit is not quite so easy. What occurs to me as a consequence is to build an array in $context for the items that appear in the footer, which can be extended easily from a plugin.

There are only so many things that can be done in a plugin - either creating a template within some kind of template layer, or replacing the template in its entirety, or we have some structure that can be manipulated inside the template. It might be nice to have a $context variable that can be updated, though, in case people want to have custom copyrights in the footer (even if we think it's generally unnecessary when having the credits page)

I am also inclined to make the revision number available from the admin panel rather than being a file, just seems like it might be easier (and faster) - but I'm happy to make it either way.
Quote
Any ideas how to fix that one..?

8: Undefined index: latestRealName
File: /Sources/Subs.php
Line: 1534
(And more.)

It's the common_stats code. Very likely a bug caused by updateSettings being disabled during the install process..? But it should be enabled at that point, shouldn't it...?
It's completely that. The final step - DeleteInstall - is the step that calls updateStats which calls updateSettings, and is the point of not setting WEDGE_INSTALLER on every single install step.
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2012, 11:31 AM
Quote from Arantor on October 3rd, 2012, 11:56 PM
It wasn't meant to be a final solution. I only really cared enough about it actually letting me install.
Well, I'm getting to it personally... As of now, except for the updateSettings problem for stats, everything is okay, and I've overhauled the install screen in a fashion that makes it now look cool. (Well, basically, I've mostly added a large size Wedge logo in the top left corner and added an easy gradient to the progress bar... :lol:)

Oh, there's also a bug with my clean_cache code... It doesn't seem to work, ah ah. At least with folders -- I added code to remove empty folders but it doesn't seem to work, even after force-deleting index.php, hmm...
Quote
I did notice it threw an error but I wasn't overly bothered, knowing that the plan is to remove those anyway in the end.
You should have reported it, still... ;) If only because it was my fault... I hate it when I add bugs.
Quote
Sure, just trying to work out how best to do that. What occurs to me is me is that while it's possible to insert the SVN revision, just by munging $txt['copyright'] easily enough - inserting the Facebook bit is not quite so easy. What occurs to me as a consequence is to build an array in $context for the items that appear in the footer, which can be extended easily from a plugin.
I'm not a big fan of making it easy to remove the copyright text, but I'd like to make it easy to ADD to it, precisely because it encourages people to add instead of removing stuff... Maybe a small template hook at that point?
Quote
There are only so many things that can be done in a plugin - either creating a template within some kind of template layer, or replacing the template in its entirety, or we have some structure that can be manipulated inside the template. It might be nice to have a $context variable that can be updated, though, in case people want to have custom copyrights in the footer (even if we think it's generally unnecessary when having the credits page)
Yes, the credits page would be the best place, but this is a discussion to be saved between plugin authors and plugin users, mostly -- do they feel their theme/plugin/poopoo warrants a footer copyright, or is it okay to have it in the credits page?
Quote
I am also inclined to make the revision number available from the admin panel rather than being a file, just seems like it might be easier (and faster) - but I'm happy to make it either way.
I don't know, I update the file manually when I do my uploads... To me, it's just a way to quickly tell people that I've updated the site. Having to go to the admin panel for that would add an unnecessary step in my upload process, I'd say...
Quote
It's completely that. The final step - DeleteInstall - is the step that calls updateStats which calls updateSettings, and is the point of not setting WEDGE_INSTALLER on every single install step.
Well then, why doesn't it work on my local install...?
Does it work on yours? Did you have the error last time you tried?
Title: Re: New revs - Public comments
Post by: PantsManUK on October 4th, 2012, 01:39 PM
Quote from Nao on October 4th, 2012, 11:31 AM
[Yes, the credits page would be the best place, but this is a discussion to be saved between plugin authors and plugin users, mostly -- do they feel their theme/plugin/poopoo warrants a footer copyright, or is it okay to have it in the credits page?
As a plugins user, for "game changer" plugins (plugins that make massive changes to default Wedge, or effectively take over Wedge, like WedgeDesk) add to the footer, for your average plugin, the credits page. It's about "default view" (if you will); if your default view of the app is WedgeDesk (or WedgePortal (made up name, I assure you...), or whatever, f'rinstance), the footer needs to say WedgeDesk (or whatever), if your default view is Wedge, it needs to say Wedge. This makes the most sense to me...
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2012, 03:15 PM
Quote
I'm not a big fan of making it easy to remove the copyright text, but I'd like to make it easy to ADD to it, precisely because it encourages people to add instead of removing stuff... Maybe a small template hook at that point?
This is why I was thinking about creating a variable with it in, and then allow hooks to add to it (but specifically not able to modify the properties of that variable ;))

I don't really want to put it in the template because that would mean themes could prevent that being applied.
Quote
Yes, the credits page would be the best place, but this is a discussion to be saved between plugin authors and plugin users, mostly -- do they feel their theme/plugin/poopoo warrants a footer copyright, or is it okay to have it in the credits page?
This is one of those really huge debates that won't go away. Themes modify every page by definition, thus having the credit there is totally applicable. But plugins don't generally modify every page, in which case footer changes are bordering on inappropriate. It's almost entirely then about promotion and making money (like vbgamer and Nibogo are so fond of)
Quote
I don't know, I update the file manually when I do my uploads... To me, it's just a way to quickly tell people that I've updated the site. Having to go to the admin panel for that would add an unnecessary step in my upload process, I'd say...
This is why I thought I'd ask before just doing it ;)
Quote
Well then, why doesn't it work on my local install...?
Does it work on yours? Did you have the error last time you tried?
I had the error, figured out why, applied the test to check, and never re-tested it, assuming it would work >_<
Title: Re: New revs - Public comments
Post by: Nao on October 4th, 2012, 05:55 PM
- I'm okay with adding a $context var next to $txt['copyright'] or whatever. :)
- I'm just not confident enough with plugin writing to even be able to do something as simple as hooking into that variable...

- Also, just wanted to say that locally, I'm finished with the install bugs. They're 100% fixed (hopefully), I even fixed a few bugs that weren't visible, and also fixed clean_cache() to work properly on sub-folders (I'm afraid it didn't cut it before then...)
I'm just left with committing the stuff... And it's quite a huge commit, intertwined with many CSS tweaks done over the week (or simply today, ah.) I'm actually tempted to just commit everything in a batch, rather than split files such as index.css which would need to be committed several times for thematic reasons... :-/
Title: Re: New revs - Public comments
Post by: Arantor on October 4th, 2012, 05:59 PM
Quote
- I'm okay with adding a $context var next to $txt['copyright'] or whatever.
Well, I was thinking that wetem could contain two extra methods: one for adding new values to a list and one for outputting those items - that way there's no ability to tamper with the contents because the contents are never pulled into a place they can ever be modified, yay for classes with proper variable scoping.

Doing it this way means it cannot be tampered with - putting it in $context means it can be tampered with.
Quote
- I'm just not confident enough with plugin writing to even be able to do something as simple as hooking into that variable...
I can understand that. What I think I'll do then is not only write the plugin but also go through and explain how all of it works, in the hopes that it helps.

Eh, just commit it and let the deities of computing sort it out :lol:
Title: Re: New revs - Public comments
Post by: live627 on October 5th, 2012, 12:53 AM
CSS still ends up in 404 errors... will see what's up.

(JS seems fine)
Posted: October 5th, 2012, 12:31 AM

I only see the installer cache CSS folders.
Posted: October 5th, 2012, 12:34 AM

Had to update Settings.php. Problem fixed.
Title: Re: New revs - Public comments
Post by: Sara on October 5th, 2012, 02:41 AM
Quote from Arantor on October 4th, 2012, 03:15 PM
This is one of those really huge debates that won't go away. Themes modify every page by definition, thus having the credit there is totally applicable. But plugins don't generally modify every page, in which case footer changes are bordering on inappropriate. It's almost entirely then about promotion and making money (like vbgamer and Nibogo are so fond of)
I agree, the credits page is sufficient.  The credits page can be long without tackiness.  Putting it in the footer of every page will add on extra bytes and might be extra cruft to a theme in general.  In fact, I prefer the credits page because it's well presented, and people are more apt to click and find out more about a plugin. </2 cents>
Title: Re: New revs - Public comments
Post by: Nao on October 5th, 2012, 08:57 AM
@live> Generally speaking, you might want to be careful with your current local installs everytime you see a commit that modifies the other/ folder, especially the install.* and Settings files ;)

So, guys, what do you think about the new installer tweaks...?

Apart from the design, I'm also considering doing something smart: launching the Ajax test automatically instead of upon a click, and showing the results directly in the current window, i.e. a good opportunity to use $().load()... :P

@Pete & Sara> Hmm... So, let's sort it out: instead of trusting modders not to add links carelessly in the footer, we should prevent them from doing so at all. This goes through the use of private vars. We could possibly even test for the length of outputted strings, and if it's too long or its base64 version or whatever doesn't have a specific bit of string in it we can reset it, blah blah blah... (I'm trying to stick to trusting people, but I guess we can go either way eh..? :^^;:)
Title: Re: New revs - Public comments
Post by: Arantor on October 5th, 2012, 03:25 PM
I like the new tweaks, it looks nice :)

Yes, I agree that the installer test should be done like that - but let's go one better. If it doesn't pass for whatever reason, automatically disable the option.
Quote
So, let's sort it out: instead of trusting modders not to add links carelessly in the footer, we should prevent them from doing so at all. This goes through the use of private vars. We could possibly even test for the length of outputted strings, and if it's too long or its base64 version or whatever doesn't have a specific bit of string in it we can reset it, blah blah blah... (I'm trying to stick to trusting people, but I guess we can go either way eh..? :^^;:)
Well, doing this is easy enough; wetem can have control over it. The one thing that it would mean is that it would be... difficult to inject the SVN version number the way you currently have it in the footer, though in theory if you can get to $txt['copyright'] before it gets inserted into wetem (or wherever, but principally wetem), you can fudge it by inserting something on the end.

This is essentially the problem: whatever method we leave in for ourselves to use here will be exploitable elsewhere. But I think that's a compromise we can live with ;)
Title: Re: New revs - Public comments
Post by: Nao on October 6th, 2012, 03:10 PM
Quote from Arantor on October 5th, 2012, 03:25 PM
I like the new tweaks, it looks nice :)
(And I'm probably going to keep that logo... It looks good at large sizes, and for small sizes I can always use whatever we have these days, as it's the same logo, only what's around it changes.)
Quote
Yes, I agree that the installer test should be done like that - but let's go one better. If it doesn't pass for whatever reason, automatically disable the option.
It seems like a given to me :P
But the problem is that as soon as I'm starting work on that, I'll get the idea to do the same for pretty URL support discovery (i.e. call for /whatever/ through Ajax and see if $.load() get something in return...), and I have a feeling I'll be spending a week on all of this... :^^;:
My personal goal is to have a 'releasable' alpha version by next week. (Which we'll release in private first anyway, but you get my point...)
Quote
Well, doing this is easy enough; wetem can have control over it. The one thing that it would mean is that it would be... difficult to inject the SVN version number the way you currently have it in the footer,
I don't mind changing the way it's shown... I just want to have it somewhere, preferably in the footer, and injected through a plugin.
Quote
This is essentially the problem: whatever method we leave in for ourselves to use here will be exploitable elsewhere. But I think that's a compromise we can live with ;)
Anyone's free to change $txt['copyright'] but we can always test for its contents in wetem...
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 05:00 PM
Okay... Just had a couple of ideas I need to get opinions about.

- Loading settings: currently, we're getting strings, and for some we need to unserialize them, so we do that... I was thinking, if a plugin wants to save some settings, maybe we should recommend that they save them into a single variable because it's 'cleaner' that way, i.e. into an array... But because people might not want to do the serialize work, here's what we could do: we load $settings, and then iterate through it, searching for '{' in strings, if found, $arr = @unserialize($string), and if $arr !== false, then use $arr instead of the serialized string. Then, at updateSettings time, we can simply do an is_array() test, and if true, serialize the string, but still return the array instead of the serialized string of course.

What do you think...?
The only place where this would slow down performance is the strpos() on every single variable, or we could just directly try to unserialize them without a test, it warrants a test anyway... Other than that, it'd make life easier for everyone, I think.

- The sidebar... I've been postponing for a couple of weeks a skin change to Weaving that actually pushes the linktree inside the content area, because I figured that it's easier to get it outside of the content area with CSS (a negative margin, basically), than inside it. I've been trying to have Wuthering be the example of putting the linktree outside of the content area, but it doesn't work as well as I thought because the table-cell status of divs makes it impossible to adjust the sidebar without cancelling its table-cell status (which allows it to extend to the bottom of the page.)
So, basically, I have a few choices left...
- Give up on table-cell for the sidebar, like I suggested earlier, and use other tricks instead,
- Use a <skeleton> to move the linktree around in Wuthering, rather than a CSS change (this is probably what makes the most sense, but I wanted to show that it was possible to do with CSS...)
- Or just give up on putting the linktree above the sidebar & content, just have it sit above content and beside the sidebar as per usual.

What do you think...? (If anything.)

PS: I posted that to the wrong topic, but at least it reminds me that I have a couple of comments to make on the loadLanguage and capitalization changes...
Title: Re: New revs - Public comments
Post by: Arantor on October 8th, 2012, 05:08 PM
It doesn't make life any easier, on the contrary it makes plugin code more complicated because unless they're using a simple page (where we can hide the real complexity away from them), they have to do fudge things themselves. There are already examples in SMF and Wedge of doing crap like this (cf the warning settings, post moderation settings) only without being serialised, just comma-separated and that's messy enough.

All it does is keep things marginally smaller in the database, it doesn't make anything easier per se. I'd honestly rather leave it alone because the extra complexity, the extra performance hit for a marginal (at best) saving of space with no improvement in convenience for anyone, and the potential to introduce new bugs unnecessarily puts me off. It is an interesting idea but it's got way more downsides than upsides.


As far as the sidebar, I'm not fussed either way, just whatever is most flexible for theme designers.
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 05:59 PM
Quote from Arantor on October 8th, 2012, 05:08 PM
It doesn't make life any easier, on the contrary it makes plugin code more complicated because unless they're using a simple page (where we can hide the real complexity away from them), they have to do fudge things themselves. There are already examples in SMF and Wedge of doing crap like this (cf the warning settings, post moderation settings) only without being serialised, just comma-separated and that's messy enough.
I don't understand... Why can't we simply change these variables to use arrays instead, and have them go through the code I suggested?
I personally had a few times where I was going to store an array into $settings, and then thought to myself, "oh wait, I can't, I'm supposed to send a string instead..."
And if you're writing a plugin that accesses a serialized array in the settings, you don't want to have to unserialize it yourself, because when are you supposed to do that..? As a plugin author I'd expect Wedge to do it for me. (But then again that's just me...)
Imagine if you're accessing your $settings var in multiple places. Do you have to do an unserialize test on it everytime you use it..?
Quote
All it does is keep things marginally smaller in the database, it doesn't make anything easier per se. I'd honestly rather leave it alone because the extra complexity, the extra performance hit for a marginal (at best) saving of space with no improvement in convenience for anyone, and the potential to introduce new bugs unnecessarily puts me off. It is an interesting idea but it's got way more downsides than upsides.
I don't see how it could add any bugs. @unserialize will simply return false if it can't turn the string into an array. Meaning that it isn't an array at all.
Quote
As far as the sidebar, I'm not fussed either way, just whatever is most flexible for theme designers.
Hmm... That's exactly where I'm not too sure ;)
Posted: October 8th, 2012, 05:54 PM

Just did a quick test...

Code: [Select]
global $settings;
$t = microtime(true);
foreach ($settings as $truc)
if (strpos($truc, '{') !== false)
$truc = @unserialize($truc);
echo microtime(true)-$t;

Returns in around 1 millisecond on my local setup. About 2 if I remove the strpos() test, meaning it's best to avoid calling unserialize for nothing.

Is that worth the delay then..?

:edit: At this point in the code, they're already unserialized. I should test for another...
Title: Re: New revs - Public comments
Post by: Arantor on October 8th, 2012, 06:06 PM
Quote
I don't understand... Why can't we simply change these variables to use arrays instead, and have them go through the code I suggested?
So we go through the few hundred variables, testing for { and unserialize every page load. Sounds nice and efficient. How many rows is that actually applied to? You need to consider around 400-500 rows for a typical install.

But more than that, I guarantee it WILL introduce issues because it's not just the loading code that needs to be fixed, all of the saving code also all needs to be fixed. Which means potentially affecting everywhere in the admin panel that uses the generic saving code, because that won't cause bugs or anything.
Quote
And if you're writing a plugin that accesses a serialized array in the settings, you don't want to have to unserialize it yourself, because when are you supposed to do that..? As a plugin author I'd expect Wedge to do it for me. (But then again that's just me...)
Topic Solved doesn't seem to worry about it too much, seeing how certain types of setting can themselves be arrays, which are already serialised, such as multi-select or boards settings.

Do it if you really want but I'm really not keen on it because I'm not convinced it actually saves anything. The problem isn't loading, it's saving. That, and all the fun code related to editing settings in the admin panel, which was crappy enough to write the first time.
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 06:10 PM
Another test...
- Disabled caching for $settings
- Added unserialize directly to the $settings[$row[0]] = $row[1] line
- Result is about 40% slower, i.e. normally the array would be filled in about 1 millisecond (as well), and the extra code adds between 0.3 and 0.8 milliseconds, on average 0.4ms.

Also of note: because the entire thing is cached to begin with, *we don't need to unserialize data on every page load*... As it's already unserialized through the cache. It's already the case in the current codebase.

That means, it only adds half a millisecond to performance *before* the cache enters into account. When caching is enabled (even at the default level, which is on by default), there is absolutely no difference in performance when retrieving arrays instead of variables.

I would thus strongly recommend adding support for arrays into updateSettings!
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 06:13 PM
Quote from Arantor on October 8th, 2012, 06:06 PM
So we go through the few hundred variables, testing for { and unserialize every page load. Sounds nice and efficient.
(See above... Sometimes, just doing some performance tests is faster than discussing performance issues ;))
Quote
How many rows is that actually applied to? You need to consider around 400-500 rows for a typical install.
It's on my local install. Which dates back to last year or so... So, I only added data to it, not removed any.
Quote
But more than that, I guarantee it WILL introduce issues because it's not just the loading code that needs to be fixed, all of the saving code also all needs to be fixed.
If you supply a string, which is always the case right now, it won't make a difference whether you add support for arrays or not... Whether it be at saving time, or at loading time...
Quote
Topic Solved doesn't seem to worry about it too much, seeing how certain types of setting can themselves be arrays, which are already serialised, such as multi-select or boards settings.
And AFAIK, serializing a serialized string will simply generate an escaped serialized string, won't it...? So you can keep using your custom decoding code on it later.
Quote
Do it if you really want but I'm really not keen on it because I'm not convinced it actually saves anything. The problem isn't loading, it's saving. That, and all the fun code related to editing settings in the admin panel, which was crappy enough to write the first time.
:^^;:
Title: Re: New revs - Public comments
Post by: Arantor on October 8th, 2012, 06:16 PM
Firstly, serializing a serialized string gives you a doubly serialized string. Yes, no kidding, there was a bug in earlier releases of Project Tools where this was happening. So you have to unserialise it before unserialising it.

Secondly, the point I have been making is that certain things in prepareDBSettingsContext already have arrays, and it serialises them before sending to updateSettings.

If you want to add it, you go add it. I just want nothing to do with the debugging that I know will result. (You'll need to update Topic Solved and possibly other plugins too)
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 06:44 PM
Okay, before I forget...
Regarding the setlocale thingy.
I hadn't looked into it before, but your change made me realize that my local install capitalizes month names in French, unlike what should be done. It works here on wedge.org, but not on my local install.
Where should I start looking to fix that...?
Quote from Arantor on October 8th, 2012, 06:16 PM
Firstly, serializing a serialized string gives you a doubly serialized string. Yes, no kidding, there was a bug in earlier releases of Project Tools where this was happening. So you have to unserialise it before unserialising it.
That's exactly as expected...

array(1,2,3,4,5,6,7,8,9,10)
Serializes to
a:10:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:4;i:4;i:5;i:5;i:6;i:6;i:7;i:7;i:8;i:8;i:9;i:9;i:10;}
Which serializes to
s:88:"a:10:{i:0;i:1;i:1;i:2;i:2;i:3;i:3;i:4;i:4;i:5;i:5;i:6;i:6;i:7;i:7;i:8;i:8;i:9;i:9;i:10;}";
Which unserializes to the a:10 string, which then unserializes to the proper array.
Meaning that you can store serialized arrays in an array, and it won't screw them up.
I guess you'd only need to be careful not to send a serialized array to updateSettings, or maybe I should simply check at updateSettings time whether the variable is (1) an array (in which case, serialize it and store it serialized), (2) or a string, in which case, test whether it has { in it, in which case try to unserialize it, and if it works, then serialize it again so that the $settings loader will correctly unserialize that and store the serialized array (rather than its unserialized version) into the variable.

Do you know what I mean...? :^^;:
Quote from Arantor on October 8th, 2012, 06:16 PM
Secondly, the point I have been making is that certain things in prepareDBSettingsContext already have arrays, and it serialises them before sending to updateSettings.
In which case these arrays will be serialized twice, and then unserialized back into a serialized array, which should ensure that you don't even have to fix your code... (You can, of course.)
Quote
If you want to add it, you go add it. I just want nothing to do with the debugging that I know will result. (You'll need to update Topic Solved and possibly other plugins too)
Possibly not. :)
Posted: October 8th, 2012, 06:34 PM

Looked into my setlocale problem...

If I do this: (as suggested by http://www.php.net/manual/en/function.setlocale.php)

setlocale(LC_TIME, '');

It correctly uses French & lowercase on names. If I don't, it will actually return dates in capitalized English...?! (Using strftime.)
I'm not exactly sure where this needs fixing...
Title: Re: New revs - Public comments
Post by: Arantor on October 8th, 2012, 07:48 PM
Quote
I hadn't looked into it before, but your change made me realize that my local install capitalizes month names in French, unlike what should be done. It works here on wedge.org, but not on my local install.
Then either the locale database is wrong or it's using the strings in the language file which are also capitalised.
Quote
In which case these arrays will be serialized twice, and then unserialized back into a serialized array, which should ensure that you don't even have to fix your code... (You can, of course.)
Why? Why serialize it twice? That's just overly complicating the matter (and is why I want nothing the hell to do with it) It's an array, not an array inside an array.
Quote
It correctly uses French & lowercase on names. If I don't, it will actually return dates in capitalized English...?! (Using strftime.)
I'm not exactly sure where this needs fixing...
Well, I tested it locally and it worked as expected for me :/

Refer back to http://wedge.org/pub/bugs/7158/smf-bug-4870-incorrectly-capitalised-month-names/
Title: Re: New revs - Public comments
Post by: Nao on October 8th, 2012, 09:54 PM
Quote from Arantor on October 8th, 2012, 07:48 PM
Quote
I hadn't looked into it before, but your change made me realize that my local install capitalizes month names in French, unlike what should be done. It works here on wedge.org, but not on my local install.
Then either the locale database is wrong or it's using the strings in the language file which are also capitalised.
Oh yeah, it's probably that... :-/
Problem is, I thought that these months were stored in there to be used in things like the calendar, where you show JUST the month, right..? And a lowercase month name looks silly, I guess, as a title...
Quote
Why? Why serialize it twice? That's just overly complicating the matter (and is why I want nothing the hell to do with it) It's an array, not an array inside an array.
We're really not serializing things twice, except if the submitted string is serialized, which means that the caller code is expecting to get a serialized string back when stuff is retrieved from the database. It's just a 'protection' against bugs... Other than that, everything's serialized just once. (Or never -- in the case of a non-array.)

The more I think about it, the less reasons I can think for this to fail... The only issue right now is with empty arrays. If they're not initialized, it's impossible for Wedge to tell that we should return an empty array. For instance, if 'js_lang' is not initialized, it's an empty string. Thus we're not turning it back into an empty array. Thus $settings['js_lang'] is an empty string, rather than an empty array, when js_lang hasn't been set yet. It might create some confusion/errors. The logical solution would be to either store ALL array-types variables in install.sql (with a default set to "a:0:{}" or whatever the content is to represent an empty array), or have fallback code for every occurrence...

Maybe I could/should simply do a quick commit at some point -- the bare minimum required to make it work, and if it fails to work correctly, then we can easily revert it.



In other news, I've just finished implementing block variables.
e.g. in the main skeleton, we have a <linktree> block, right? And it's called *again* but manually if in a topic page. I already worked with this before and gave up on it because I can't define two blocks with the same name. Then it occurred to me today that I could simply store the variable list inside the block name... Eh, why not? Then it works. I just need to extract the variable list at render time.

So, we have something like this...

<linktree />
<content />
<linktree:1 />

The second one calls template_linktree with the first parameter set to '1'. I've invertedt the two variables so that $on_bottom is set to 1 in that second call. It works perfectly... :)
Now people are finally going to be able to call a single block multiple times, either with multiple variables or simply entering dummy variables like:

<my-block:to-the-left />
<my-block:to-the-right />

If you have several variables to pass, just separate them with commas (<linktree:1,2,3 />)
There's just one weakness: you can't pass strings between quotes or anything with spaces in them. I decided against it because it would slow down the code for nothing IMHO. Really, if you're declaring a variable inside a skeleton, you're only telling the block what behavior to use in that position... No?
Of course it would be cool to have something like <title:"Hello, world!" /> and create a block that is a title saying that. But it doesn't sound too realistic to me.
This isn't something that's impossible to implement. It's just that it makes the regex longer, more complex, and I don't really trust long regexes, at least not too many... ;)

So, what do you think...?
Title: Re: New revs - Public comments
Post by: Nao on October 9th, 2012, 06:10 PM
Okay... I'm a bit lost in my work right now.

I'm working on several things at a time, and can't seem to make any progress.

1/ Moving linktrees into the container: this has proven to work well thanks to the post above, but I just realized that Wine causes a problem... (And Wuthering too, probably.) Namely, because the sidebar is a very stylish one and its style is applied to the containing table cell, I can not apply a margin-top above the sidebar to compensate for the absence of a linktree. Table cells only accept padding-top, and obviously the only effect is to make the sidebar's insides bigger rather than add padding above the sidebar.

Solutions:
a- Move the sidebar to a contained div, and give up on having it fill the entire height,
b- Move the sidebar to a contained div, apply an equal-height CSS hacks (basically: padding-bottom: 10000px and margin-bottom: -10000px or something like that), and give up on having the bottom of the sidebar rounded (instead, it will disappear behind the footer.) I can apply this solution to Weaving and Warm easily, BTW, this way I could even get rid of the table macros for IE6/7...
c- Move Warm to be a child of Weaving, and have Wine and Wuthering use solution (b),
d- Add margins above the sidebar's container's container, but this also adds space above the content area, and I can't apply a negative margin to it either, unless I do some positioning magic, which is sure to cause problems later in the process...
e- Maybe something else...?

2/ I'm working on an alternative way of modifying a skeleton through skin.xml, but I can't seem to get the hang of it... (Mostly in terms of writing standards...) Would it make sense or not? I'm thinking about doing something like this...

<move block="linktree:bottom" to="main" where="before" />

Which would allow blocks to be moved around without having to reproduce the original skeleton, essentially making it more solid when the skin is moved below another new default skin.
Posted: October 9th, 2012, 05:30 PM

I know I'm annoying, but a small bump is really needed here :P
Because the message is primarily for Pete and I'd rather have a 'I don't know, let me think about it' than nothing... :whistle:
Title: Re: New revs - Public comments
Post by: Arantor on October 9th, 2012, 06:15 PM
Well, it might be primarily for me but it's not even a case of 'I don't know, let me think about it', but simply a 'I have no idea which is the best course of action'. There's simply so much stuff that it relates to, potentially, that I can't tell you which would be best.

What I will say is that I dislike a, either the sidebar should be full height or not at all. I will note that I am personally not averse to using tables to fulfil this, but that's because I don't give two hoots about good design :lol:

As far as 2 goes, that sounds very nice and flexible.
Title: Re: New revs - Public comments
Post by: Nao on October 10th, 2012, 12:08 PM
Quote from Arantor on October 9th, 2012, 06:15 PM
Well, it might be primarily for me but it's not even a case of 'I don't know, let me think about it', but simply a 'I have no idea which is the best course of action'. There's simply so much stuff that it relates to, potentially, that I can't tell you which would be best.
Hmm, so this is what I'm currently thinking of doing...

- Weaving: div system, linktree inside content, with margins and stuff. Sidebar is positioned through negative margin hacks.
-     Wine: table system, linktree above content, solves the margin problem because the sidebar is no longer stuck to the menu
-          Wuthering: inherits Wine
-          Warm: TBD (inherits Wine or Weaving?), because it changes the skeleton anyway...
Quote
What I will say is that I dislike a, either the sidebar should be full height or not at all.
If they're in a table, they're full height. If they're not, they're not full height. There's no alternative. Unless you mean the fact that the bottom can't have rounded corners in non-table mode..?
Quote
I will note that I am personally not averse to using tables to fulfil this, but that's because I don't give two hoots about good design :lol:
And it's a perfectly valid solution, of course, and one I'll keep using. After all, I wrote macros for a reason! And precisely for that one...
No, the fact is that I really want to have a 'simple' skin as default, and introduce more complex stuff in sub-skins and the likes. The main issue for me is to determine whether the table workaround is a simple or complex addition.
Quote
As far as 2 goes, that sounds very nice and flexible.
I've finished a first implementation, worked on that this morning... It's barely working. Well, it's already a good thing that it's working.

However, err... I've been thinking about something. Something silly really...
Currently, wetem takes the skeleton tags, turns them into a multi-dimensional array, and then we are allowed to apply various operations to it before it's rendered.
I was thinking, why exactly didn't I think of something simpler...? Or, at the very least, if I think of it, why did I give up on it? I don't remember...
The 'simpler' solution would be to apply all operations on the skeleton tags, and THEN at render time, build an array out of them...
Currently, because we're working on an array, doing simple changes to it can be quite hard. I'd even venture into saying, although I wrote the whole damn thing and I actually understand what the code is about (damn, I even commented a LOT of it!), I had a short WTF moment in front of one of the functions. Ever since, I've been wondering if it wouldn't be better to simply do the work on the tags themselves... It can't be much slower than working on the array...?! It's probably even faster, if I may say...

The only drawback of this approach, is that, ahem.... I actually have to rewrite all of the main manipulation functions.
Yeah. Well, I'd be ready to do just that... I'm sure it'll be no more than a few hours of work. (I'm not kidding.)
Title: Re: New revs - Public comments
Post by: Nao on October 19th, 2012, 03:28 PM
Okay, re: the above...

- I'm not in the mood to rewrite wetem, at least not for now. It's something that can be done much later anyway...

- I'm thinking of adding some skin.xml commands to add/delete a layer or block. Is this a good idea...? Delete is nearly a given, but add is more problematic -- a layer or block would logically be associated with a function... And there's no way to define a custom function in a skin. But I don't see myself adding the 'delete' command without an 'add' somewhere..?!

- Also, I've resumed work on the sidebar thing... The longer I think about it, the stronger my feelings are for simplifying the display:table thing for IE6/7. That is, I'd rather have an unfinished sidebar column for them, than having the sidebar stuck to the side when the window is too small to show it. So, I want to go for divs everywhere.
However, there is still this minor problem: the negative margin hack requires for an intermediate div (or whatever) to be added between <div id="main"> and the main content. What should it be called? Should it be added for all browsers, or just for old IEs? Maybe designers will be glad I added that div if they want to do something special, but OTOH that's already what <div id="main"> was there for... Should it be a special unused tag, like <article>..? Hmm, too bad Ian Hickson said 'no' to a <content> tag... (See article in the latest .Net issue for his rebuttal.)

- Oh, and while I'm at it... The sidebar is the only element in all Wedge that uses the <aside> tag. I don't know if it's worth applying an ID to it..? Why not simply style the <aside> tag? (It's probably faster for the browser to target an ID, but whatever...)
Title: Re: New revs - Public comments
Post by: Nao on October 22nd, 2012, 03:19 PM
Shameless bump!

With that and my link tree issues, I have a success rate of 0% today. Sucks...
Posted: October 19th, 2012, 09:03 PM

And now for a totally deserved bump... :P
(Good thing I got the link tree thing covered. Except for multi-line versions.)
Title: Re: New revs - Public comments
Post by: godboko71 on October 22nd, 2012, 05:42 PM
Personally I think you should do what you think is best. I enjoy both the simple link tree and the rounded one on withering ( blame apple tired of trying to fix haha )
Title: Re: New revs - Public comments
Post by: Nao on October 22nd, 2012, 11:34 PM
I'm mostly interested in comments about what I posted above, though... :P

Ah my. IE7 is real messy when it comes to this media query. After a lot of work I managed to make it work in Weaving, but then Wine comes in and breaks everything... I've also fixed Wine, but it adds even more lines of code. If I'm going to have to 'watch' my css everytime I change it, and apply similar changes to the IE code, I fear it's not going to be very fruitful... Hmm.
When does IE7 fall out of fashion, already..?
Title: Re: New revs - Public comments
Post by: godboko71 on October 23rd, 2012, 04:40 AM
IE 8 and 9 are all that matter forget 7 :p
Title: Re: New revs - Public comments
Post by: Norodo on October 23rd, 2012, 11:11 AM
I wouldn't discount IE7 completely yet if I were to follow my GA stats. The amount of people using IE7 is non neglible, at least 1% right now. Now this might change before Wedge is released completely, but as it is right now IE7 matters.

IE6 sees little use on the pages I oversee, with around 2‰ usage from the last couple of months. Dead at last!
Title: Re: New revs - Public comments
Post by: Pandos on October 23rd, 2012, 11:22 AM
To get more accurate:


last month 7283 unique visitors with IE7 and 1061 unique with IE6....

Title: Re: New revs - Public comments
Post by: Nao on October 23rd, 2012, 08:43 PM
I don't know how you can reach these numbers, perhaps your site is geek-oriented, I don't know...
Market usage numbers for IE6 and IE7:
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2&qpcustomd=0

2.51% for IE7, and 7.22% for IE6... If you click the browser names, you can see the evolution over the last year. IE7 numbers have been reduced by 50% which is good, but IE6 numbers have actually been stable.

Now, if you take ie6countdown.com into account, they claim similar numbers (6% for IE6, with a stagnation over the last few months), but their per-country data shows that most of that traffic is from IE6. This is apparently mostly due to the fact that the vast majority of China's Windows XP copies are pirated, and thus can't use Windows Update for anything else than 'critical updates'[1], and IE has never been flagged as a critical update -- until recently, and only in a limited number of countries. I suspect China has yet to have it flagged as critical, though...

Anyway, so in conclusion -- Wedge doesn't care much about China, so I'd consider the IE6 share to be about 2.5%, which is enough to justify dropping it (even though it's still higher than the Opera usage share, but I'm okay with preserving support for an excellent browser that barely has any quirks, eh!). IE7, in comparison, is the default browser in Vista only, and its shares probably mostly reflect the pirated Vista copies. Or something, I don't know. Let's say that the entire share (2.51%) is legit, and unlikely to update soon... So, that's still 5% to account for.
Would would be ready to refuse entry to your forum to one person out of twenty...? That's the main question.

I'm sure there are at least 5% of future Wedge users who'll be complaining that we don't support IE... So, I'm not dropping support.

An alternative, though, could be this: I could very well drop support for IE6/7 in the main skins, and create an IE6/7 compatible skin with the very bare minimum, similar to the Wireless skin. The only issue is that I don't see myself creating a 'shitty_browser' entry in the members table (there are currently two different entries for desktop and mobile browsers.) That is, if the user switches from IE6 to Firefox, they won't suddenly find themselves with the 'nicer' skins. Or, I could force the IE skin on IE6/7 users, disregarding their skin choices in other browsers... I don't know.
 1. Unless you're using an Enterprise version of XP, or something called like that.
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on October 23rd, 2012, 09:59 PM
Isn't Wedge for real men and women? Well, they don't use IE 6/7. :whistle:
Title: Re: New revs - Public comments
Post by: Pandos on October 23rd, 2012, 10:04 PM
With over half a million unique users this is an very small percentage of user with IE6/7.


Your Idea of creating an extra skin for those users sounds good, but when it comes to layout questions and deploying layouts for all users this would be very complicated. You always have to touch two themes..
Title: Re: New revs - Public comments
Post by: Nao on October 23rd, 2012, 10:58 PM
It wouldn't be a clone of Weaving. It would be a crude version like the smf wireless style. Something that makes it usable but still an incentive to use a real browser...
Title: Re: New revs - Public comments
Post by: Norodo on October 24th, 2012, 08:21 AM
My webpages are somewhat geek-focused. Developers and gamers of nerdy games. Neither site has many users from the third world. My biggest focus in developing has been FF3.6 and IE8. Fortunately FF3.6 is on its last legs now.
Title: Re: New revs - Public comments
Post by: Nao on October 24th, 2012, 12:15 PM
And now we're gonna have fun developing for mobile compatibility as well... Since the rendering engines for Chrome Mobile or Firefox Mobile are probably a bit buggy/different from their desktop counterparts, just like Safari Mobile is... :P
Title: Re: New revs - Public comments
Post by: live627 on November 10th, 2012, 07:04 PM
Quote
! Fixed line breaks being turned to HTML tags in album descriptions. Well, that was an unexpected bug... And the fix is even less expectable. Please test. (Aeva-Gallery.php)
Hells yeah it's been fixed!! :yahoo:
Title: Re: New revs - Public comments
Post by: Nao on November 10th, 2012, 07:06 PM
It's just something I never got around to fixing before...
Fact is, it's a bit odd that item descriptions don't show this bug, even though they were handled in a similar fashion... :-/
Title: Re: New revs - Public comments
Post by: godboko71 on January 4th, 2013, 01:19 AM
Bumping this for nao though it might be to late for that haha
Title: Re: New revs - Public comments
Post by: Nao on January 4th, 2013, 05:03 PM
Thanks for diggin' it out, though! ;)
And it's never too late...
Title: Re: New revs - Public comments
Post by: Arantor on January 5th, 2013, 02:32 AM
Just to summarise where the add plugin is so far, it's able to accept the upload to the system temp folder, validate that it is a zip file, validate that it contains a plugin-info.xml file and validate the basic contents/requirements (PHP, MySQL versions plus required functions), and present a choice to the user in the event that it matches a currently enabled plugin.

There's so much still to do but getting to this point has been enough for me for now.
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2013, 03:27 AM
So, here are my other points... Most of them are not very interesting, but these are things that came to mind while reading the latest commit logs.

- Are you absolutely sure that fclose(fopen()) is better than touch()? Faster? More efficient?

- Since you removed the reserved words feature, well, rewrote it as part of the ban system, are you positive that you removed all occurrences of it that aren't needed in your rewrite? Doing a search on 'reserved' in the project sends me back a lot of results, some of which SEEM like remnants of the previous system to me... Can't say for sure, though.

- Also, is the code block at the beginning of isReservedName() the replacement for the extra code that prevented the use of jokers in a user name? I think it is, just want confirmation.

- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask... :whistle:

- I'm afraid I'm the one who tends to add empty newlines at the end of files... Is there something wrong with that? More odd HTML parsing? I tend to forget. One could also say, "just get rid of the closer tag"... No? (It was done that way in Class-FTP.php until you added it back, as far as I can see.)

- In Subs-Members.php, $replaceEntities uses $messages[2]... Couldn't it just use $messages[1], and we skip the surrounding brackets in $entity_name..? There's also a similar function, $fixchar in Dlattach.php, which could need your attention in a similar fashion ;) Oh, and $entity_replace in ManageMaintenance.php. And another $fixchar in Subs-Post.php... And two functions in Subs-PrettyUrls.php (entity_replace and fix_accents).

Makes me think it would be better to use existing functions for that, eh. I think westr has one... If not, we could make one. It would at least be faster than always redefining these with create_function(). Maybe just do a wide search for "& 63", that could be enough.

- We should do, for good, a template-wide replace of $scripturl with <URL>... It's so much cleaner, and it's no slower (probably a bit faster at this point.)

- Suggesting we remove $context['user'] entirely. Can do it if you want. It's about 215 matches, most of which should be done manually.

- If we rename allowedTo() to we::can(), I'd suggest renaming isAllowedTo() to we::enforce(), a name that makes more sense to me...

- Is manage_bans an existing permission, or one you added? I like that...

- From my changelog: "if we regularly update jQuery and jQuery UI, it'd probably be smarter to allow for plugin authors to link to an alias of these libraries, i.e. jquery.js and jquery-ui.js, which would then be redirected to the latest...? Or just rename the files."

- Noticed this in a few places...

+            wesql::query('
+               UPDATE {db_prefix}membergroups
+               SET ' . implode(', ', $clauses) . '
+               WHERE id_group = {int:id_group}',
+               $array);

Aren't we used to putting the final ")" on the next line, at the same level at 'wesql::query'...? I think that's how SMF does it.

- Sometimes, we define very long functions inside a string, and I was wondering if, for readability's sake, it wouldn't be more logical to use the heredoc syntax on these?
Title: Re: New revs - Public comments
Post by: Arantor on January 5th, 2013, 04:10 AM
Quote
- Are you absolutely sure that fclose(fopen()) is better than touch()? Faster? More efficient?
It might not be if all I wanted to do were update the timestamp. But touch can't guarantee the file is also empty, and I'd sort of like cache.lock to remain empty.
Quote
- Since you removed the reserved words feature, well, rewrote it as part of the ban system, are you positive that you removed all occurrences of it that aren't needed in your rewrite? Doing a search on 'reserved' in the project sends me back a lot of results, some of which SEEM like remnants of the previous system to me... Can't say for sure, though.
Pretty sure. Not all the function calls need to be removed, e.g. isReservedName() is still in use, and that's cool, I just rewrote what it checked.

The key thing was to nail reserveName, IIRC it was called, which is gone along with reserveWord. I didn't see a need to go back and rename every little function that happens to share a word with the old feature name.
Quote
- Also, is the code block at the beginning of isReservedName() the replacement for the extra code that prevented the use of jokers in a user name? I think it is, just want confirmation.
Yes it is to replace the old code to prevent * in user names.
Quote
- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask...
You do what you have to do. As long as it doesn't break anything I'm working on, that's cool.
Quote
- I'm afraid I'm the one who tends to add empty newlines at the end of files... Is there something wrong with that? More odd HTML parsing? I tend to forget. One could also say, "just get rid of the closer tag"... No? (It was done that way in Class-FTP.php until you added it back, as far as I can see.)
Aside from the fact it's bytes that don't need to be there, there are times it will actually damage the content of the file being sent, potentially with attachments and CAPTCHAs and most of the time that one or other of these fail, that's the reason.
Quote
- In Subs-Members.php, $replaceEntities uses $messages[2]... Couldn't it just use $messages[1], and we skip the surrounding brackets in $entity_name..?
That's pretty much taken just from SMF. There was doubtless a reason it was done that way but I was never privy to it. If you're going to change it, be sure that it works exactly as before.
Quote
Makes me think it would be better to use existing functions for that, eh. I think westr has one... If not, we could make one. It would at least be faster than always redefining these with create_function(). Maybe just do a wide search for "& 63", that could be enough.
Again, such refactoring is cool, but only if we're absolutely sure it doesn't break anything. I'm still not entirely happy about the dropping of ENT_QUOTES on subject titles 'because it made it shorter' with the caveat that we have to go and put it back again in some places as opposed to just leaving it alone.
Quote
- If we rename allowedTo() to we::can(), I'd suggest renaming isAllowedTo() to we::enforce(), a name that makes more sense to me...
That's just names. Makes no difference to me what it's called. It's logical, it works.
Quote
- Is manage_bans an existing permission, or one you added? I like that...
It's been there since 1.0.
Quote
- From my changelog: "if we regularly update jQuery and jQuery UI, it'd probably be smarter to allow for plugin authors to link to an alias of these libraries, i.e. jquery.js and jquery-ui.js, which would then be redirected to the latest...? Or just rename the files."
That's primarily your department ;) As long as I can call it, I don't much mind how I can call it as long as if I do call it, it works.
Quote
Aren't we used to putting the final ")" on the next line, at the same level at 'wesql::query'...? I think that's how SMF does it.
When you have a proper nested array there, it looks natural. But when you have an array like that, doing it without looks more natural to me. Whatever works, I guess.
Quote
- Sometimes, we define very long functions inside a string, and I was wondering if, for readability's sake, it wouldn't be more logical to use the heredoc syntax on these?
Firstly, heredocs or nowdocs? heredocs support 5.2+ while nowdocs are 5.3+ only. The key difference is in variable use - heredocs support parsing of variables like double quoted strings do, and just for fun, they're also at least as slow as double quoted strings, if not even slower. And it breaks indentation because the ending of the heredoc must be the first thing on the line, without any exception.

I'm not a huge fan of heredocs, personally and would rather they have never been added to the language. Note that some variables can be declared with heredocs, some cannot (e.g. certain static things) while anything can with a nowdoc.
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2013, 05:00 PM
Quote from Arantor on January 5th, 2013, 04:10 AM
It might not be if all I wanted to do were update the timestamp. But touch can't guarantee the file is also empty, and I'd sort of like cache.lock to remain empty.
I mean, once it's created (through the first fopen/fclose call), why not just touch it..? Who's going to edit it and add stuff to it anyway..?
Quote
The key thing was to nail reserveName, IIRC it was called, which is gone along with reserveWord. I didn't see a need to go back and rename every little function that happens to share a word with the old feature name.
I double-checked, and it seems to be all fine in the end. :)
Quote
Quote
- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask...
You do what you have to do. As long as it doesn't break anything I'm working on, that's cool.
After some testing (sigh), .wmenu() and .dome() pretty much use the same amount of bytes in gzipped mode... It depends on other factors, but it's not worth doing it I guess.
Quote
Aside from the fact it's bytes that don't need to be there, there are times it will actually damage the content of the file being sent, potentially with attachments and CAPTCHAs and most of the time that one or other of these fail, that's the reason.
So, how about removing the ?> altogether..?
Quote
That's pretty much taken just from SMF. There was doubtless a reason it was done that way but I was never privy to it. If you're going to change it, be sure that it works exactly as before.
SMF had plenty of lame regexes that I fixed over the years, so this particular one was probably built by someone who didn't know about (?:) (non-capturing parenthesis)...
Quote
Again, such refactoring is cool, but only if we're absolutely sure it doesn't break anything. I'm still not entirely happy about the dropping of ENT_QUOTES on subject titles 'because it made it shorter' with the caveat that we have to go and put it back again in some places as opposed to just leaving it alone.
I don't remember that :P
But isn't entity fixing a feature of westr? So why not just rely on westr to call our thingies...? It's easy enough to set a method as a callback for preg_replace, after all.
Quote
That's just names. Makes no difference to me what it's called. It's logical, it works.
Then thus shall they be named... :P
Quote
When you have a proper nested array there, it looks natural. But when you have an array like that, doing it without looks more natural to me. Whatever works, I guess.
It's not about what looks natural here, it's mostly about following the SMF guidelines.
There was a hickup in the SMF 2.0 query conversion in that they committed a 'bad' copy with lots of bad automatic replacements, and had to modify them manually, one by one, for weeks... I remember that. I also remember that's pretty much when they started taking a lot of space for any single query (like, 3 lines of PHP for a single line query...)

So, anyway, I've gotten used to SMF's way, but have no qualms with yours either. What do we call? "Anything goes for the query call indenting format"...?
Quote
Firstly, heredocs or nowdocs?
I said heredocs :P
Quote
heredocs support 5.2+ while nowdocs are 5.3+ only. The key difference is in variable use - heredocs support parsing of variables like double quoted strings do, and just for fun, they're also at least as slow as double quoted strings, if not even slower. And it breaks indentation because the ending of the heredoc must be the first thing on the line, without any exception.
Okay, then dropping the idea! I only got it after re-reading through the commits... Some areas were a bit unreadable due to the string effect.
Title: Re: New revs - Public comments
Post by: Dragooon on January 5th, 2013, 06:34 PM
$("#menu").dome();

Oh..hell no.
Title: Re: New revs - Public comments
Post by: Arantor on January 5th, 2013, 06:44 PM
Quote
I mean, once it's created (through the first fopen/fclose call), why not just touch it..? Who's going to edit it and add stuff to it anyway..?
The main reason is that it's a file in the cache folder that is not currently being excluded from the htaccess file. If I were to add it to the htaccess file as an exclusion (I need to add *.zip anyway), I would have no problem reverting it to a touch, but interestingly touch is actually 'buggy' under Windows - it won't change the modification time until PHP 5.3.0, while the fopen/fclose will force the file to be updated.

A certain amount of this is security by design; if I'm creating a file, I feel responsible for the content of that file, and it's my duty to make sure that file doesn't have anything in it that it shouldn't have.
Quote
So, how about removing the ?> altogether..?
I have no objections to that.
Quote
But isn't entity fixing a feature of westr? So why not just rely on westr to call our thingies...? It's easy enough to set a method as a callback for preg_replace, after all.
It is, but I don't think it does exactly the same fixing.
Quote
It's not about what looks natural here, it's mostly about following the SMF guidelines.
We can always make our guidelines. We HAZ TEH POWAR!
Quote
o, anyway, I've gotten used to SMF's way, but have no qualms with yours either. What do we call? "Anything goes for the query call indenting format"...?
I tend to go with whatever looks right. But I'm really not that fussed.
Quote
I said heredocs
I know you did but I wanted to be absolutely clear as a lot of people seem to conflate the two a lot.
Quote from Dragooon on January 5th, 2013, 06:34 PM
$("#menu").dome();

Oh..hell no.
Why not?
Title: Re: New revs - Public comments
Post by: Dragooon on January 5th, 2013, 06:46 PM
&("#menu").dome();
Title: Re: New revs - Public comments
Post by: live627 on January 6th, 2013, 12:28 AM
menu do me?
Title: Re: New revs - Public comments
Post by: Arantor on January 6th, 2013, 12:31 AM
men u do me?

Sounds like something a lady of the night might wonder.
Title: Re: New revs - Public comments
Post by: live627 on January 6th, 2013, 12:36 AM
Quote from Arantor on January 6th, 2013, 12:31 AM
men u do me?
ewww
Title: Re: New revs - Public comments
Post by: Arantor on January 6th, 2013, 12:54 AM
If it hadn't been me that said it, it would have been someone else.
Title: Re: New revs - Public comments
Post by: Oracle on January 6th, 2013, 02:09 AM
Yeah, what he said!
Title: Re: New revs - Public comments
Post by: godboko71 on January 6th, 2013, 03:44 AM
Haha
Title: Re: New revs - Public comments
Post by: Dragooon on January 6th, 2013, 08:50 PM
Quote from Arantor on January 6th, 2013, 12:31 AM
men u do me?

Sounds like something a lady of the night might wonder.
Pretty much where I was getting at :P...
Title: Re: New revs - Public comments
Post by: Nao on January 7th, 2013, 08:03 PM
Quote from Nao on February 15th, 2012, 05:25 PM
- Used bindEvents at one point, instead of reproducing the function. I just modified bindEvents to allow passing specific DOM elements to it.
So, this is an old change of mine... I liked the idea, still like it, but I just noticed that it's only being used twice in the entire project: once in the index template, for obvious reasons, and once in an admin page.
I tried removing it from both, replacing the admin one with a copy of the original bindEvents (it's not THAT long, and it's on only one page... admin one, on top of that), and instead of calling it at the end of the index template, I'm now doing a DOMContentLoaded call for it, which works just the same because basically these events are executed once the HTML is loaded, and after the script.js file is loaded anyway (so we already have everything under the hand at that point).
As a result, I'm saving about 10 gzipped bytes in script.js by moving the call to my DOMContentLoaded function[1], as well as about 6-7 gzipped bytes in all HTML pages.
I also moved $('select').sb() to that function, for the same reasons. This saves another few bytes in both sbox.js (part of script.js) and all HTML pages (because the call was also hardcoded in there, except when creating a new session under a browser other than IE 6-8, IIRC.)

So, all in all, I saved over 20 gzipped bytes from script.js and about 10-20 (hard to count) from all HTML pages.
Pretty happy with that, but there are two remaining issues:
- is it okay, or at least acceptable, to place that DCL function within an unrelated function...?
- can anyone think of any situation where powering up the menus, or the select boxes, or building the event list would better be placed where they used to be, rather than in a DCL function...?

Really dunno about all of this...
 1. Which, I'm afraid, and it's the only thing that bugs me a bug, is executed from within the menu building function... It's totally out of place, but this allows me to avoid building a $.fn.wmenu plugin to begin with. I don't know if I'll keep it that way...
Title: Re: New revs - Public comments
Post by: Arantor on January 7th, 2013, 08:11 PM
I'm not really fussed where it is, provided that it works and doesn't break anything.
Title: Re: New revs - Public comments
Post by: Nao on January 7th, 2013, 08:30 PM
Okay good ;)
As for whether it works or not -- I guess we'll have to wait until we get some user feedback on these... (?)
I'm at least hoping it'll help fix an issue in the Android stock browser I got with select boxes. Dunno.

Oh, and I forgot to ask whether it was okay to get rid of bindEvents' parameter, since it was only used in one function and I don't see many situations where we would need to create new HTML elements on the fly with events attached to them, and without actually directly using .bind() or similar functions to attach these events. (Which is faster, considering that bindEvents() eventually calls .bind() for all events it can find...)
Title: Re: New revs - Public comments
Post by: Arantor on January 7th, 2013, 08:32 PM
I can't imagine many cases, no. I think it's rare enough that it's probably OK not to worry too much about it.
Title: Re: New revs - Public comments
Post by: Nao on January 7th, 2013, 08:34 PM
Yup.

Oh, and it's a bit scary to have Wedge define eves = {} at some point in the HTML code and have script.js rely on this without testing, but that's the beauty of DCL... :lol:
Title: Re: New revs - Public comments
Post by: Arantor on January 7th, 2013, 08:37 PM
Scary for you - as long as I can add events inline and add deferred JS with add_js(), I'm happy.
Title: Re: New revs - Public comments
Post by: Nao on January 7th, 2013, 11:29 PM
That's the idea. :eheh:
Title: Re: New revs - Public comments
Post by: Arantor on January 7th, 2013, 11:30 PM
Then it's fine :)

I'm looking at it in terms of the modder approach; I want to be able to just build stuff and rely on it working, I don't want to have to debug a ton of stuff to write a simple plugin - it sort of defeats the purpose ;)
Title: Re: New revs - Public comments
Post by: Nao on January 9th, 2013, 10:02 AM
Well, I'll always be here to fix bugs in case they arise... I'm pretty much responsible for the frontend and all of the visual tricks.
That's what I did yesterday... Fixed a bug introduced by IE+Safari misbehaving with jQuery and conflicting with my ask() function. (Oh, and in case you don't follow the jQuery bug report I linked to, which is likely, I posted a request to fix it... Which they won't do. Nice. I've posted more arguments but I'm sure they'll be ignored as well... Maybe it's time to fork jQuery :lol:)
Title: Re: New revs - Public comments
Post by: Nao on January 19th, 2013, 02:31 PM
So, I'm looking at Pete's latest commits and I found something funny... Another of those 'coincidences' I noticed earlier ;)

Last night I was fixing a bug (which I have yet to commit), related to Wedge cutting off the starting and ending linebreaks inside a quote when switching to Wysiwyg mode. (I told you, I never use Wysiwyg, except when I'm told it needs fixing...) I noticed that it didn't break any other linebreaks, so I looked into parse_bbc() and quickly remembered that I'd added a special regex just to get rid of extra whitespace. Disabling it fixed it. Then I figured, oh yeah it's because the Wysiwyg conversion shouldn't go through the same parsing steps as when actually showing the posts...
So I added a parameter to parse_bbc(), called $converting, which was set to true by the converter, and false otherwise, and it would then skip the line.
Then I thought, oh my that's a lot of parameters to deal with... And shouldn't it make more sense to ensure that it isn't called anytime there's non-standard parsing being done...? So I decided to instead go for an empty($parse_tags) test. It probably isn't perfect, but it should catch most of the occurrences, including the Wysiwyg one. So I did it that way.

Then I'm seeing the new commit, which adds an author ID parameter[1] to parse_bbc(), and really that made me smile.

So, thanks Pete for the coincidence and the smile ;)

I'm thinking, however, that we might want to instead provide a single extra parameter in the form of an array, where we could add our extra params like 'id_cache' and 'id_member' or whatever... Thus, no limits to what can be stored in the parser params, and they can in turn be transmitted to hooks so that plugins may intercept something that they target in particular.
What do you think...? Or is it too ugly of a solution?
Posted: January 19th, 2013, 02:25 PM

Code: [Select]
(empty($_POST['pin']) == empty($topic_info['is_pinned'])

I've always loved this kind of smart, elegant little trick ;)
 1. Also for the record, I think we both considered adding that parameter at least a couple of times in Wedge's lifetime, for various reasons!
Title: Re: New revs - Public comments
Post by: Arantor on January 19th, 2013, 02:45 PM
Great minds think alike :)

Actually, yeah, it would be better to pass things in through an array - in fact you could pass in everything other than message that way if you really wanted.
Title: Re: New revs - Public comments
Post by: Nao on January 19th, 2013, 02:55 PM
Quote from Arantor on January 19th, 2013, 02:45 PM
Great minds think alike :)
But, on the same night? 8)
Quote
Actually, yeah, it would be better to pass things in through an array
It may not seem very 'clean', but it's certainly something that plugins might appreciate being able to do. Provided there are even hooks in parse_bbc() to deal with it, of course...
Quote
in fact you could pass in everything other than message that way if you really wanted.
What do you mean? (Or, to avoid having people think I can't speak English, "What did you have in mind?" :P)
Title: Re: New revs - Public comments
Post by: Arantor on January 19th, 2013, 02:57 PM
Well, right now we pass in message, whether to parse smileys[1], cache id, what tags to parse and lastly owner id.

We could convert all those other options into a single array, since there's places we don't use cache id, places we use cache id to denote signature and stuff like that - and not all places need an owner id, nor do all places need tags-to-parse lists.

Giving it a series of options does seem a bit cleaner.
 1. And I still want to remove print page from that!
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 12:44 PM
That's the thing, $cache_id has always been used in a strange way... (Even re: original Aeva.)

So, the only thing that could stop us is performance. But I don't think passing an array has any impact whatsoever on performance... Does it?

Also, can I assume you're planning to remove everything related to packages, now? Your latest commit looks like it. I'm working on it right now and would like to know for instance if you want me to keep the package server code, or if you want to reuse it for plugins, or something like that...
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 02:04 PM
Passing an array should not be significantly more expensive than passing a scalar variable.

And yes, stuff I haven't removed yet may still have some small use.
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 02:12 PM
Okay, then... At least may I remove anything related to the one DB table you left, log_packages?
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 02:14 PM
No because there is still code referencing it, and not just in the upgrader.

It will all be going soon enough!
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 02:18 PM
Re: parse_bbc, ideally we'd get rid of everything but smileys (because these are pretty much in every function call), but I don't know what structure would work best for the cache ID... For instance, array('cache' => $id_msg, 'member' => $id_member) would be odd in a Display message parser, because that should most likely be array('id_msg' => $id_msg, ...) and parse_bbc should determine what elements are in the array and build the cache id from that... But it's slower, I guess.

So.. I don't really have any ideas to make it better right now. :-/

Re: log_packages, I can assure you I removed everything and it didn't take long... I'll double check.
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 02:22 PM
Yup... loadInstalledPackages() in Subs-Package uses it, and that's pretty much all. I just commented out the line in PackageGet() that makes use of it. As a reminder to write that part as well...

If I were you, I'd just make a backup somewhere of the package-related files, then remove EVERYTHING, and re-use that code on the side to build the plugin server stuff, and then commit it later. Right now, having all those 'package' references just sounds a bit odd.
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 02:25 PM
Almost nothing gets cached anyway.

I can't just blindly remove everything because other parts still use it! Do a search on read_tgz and see what you find...
Posted: January 23rd, 2013, 02:25 PM

Yes even Aeva uses it...
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 02:41 PM
Quote from Arantor on January 23rd, 2013, 02:25 PM
Almost nothing gets cached anyway.
Oh... Are you sure?
Quote
I can't just blindly remove everything because other parts still use it! Do a search on read_tgz and see what you find...
I didn't mean to remove these functions anyway... I was mostly talking about anything directly related to packages.
For instance, do we really need to keep functions like parsePackageInfo (never called anywhere), parse_path (only used in parsePackageInfo..), packageRequireFTP (never used), package_crypt (only used in packageRequireFTP and create_chmod_control, which I'm not sure we need at all?), or listtree (never used)?
These are the functions I noted as 'deletable' in Subs-Package, in addition to listInstalledPackages...
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 02:54 PM
I'm getting there!
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 03:01 PM
Well I did the search work for you... :P Didn't actually remove anything but listInstalled, so I'll just commit 'as is' and will trust you with the rest.
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 03:27 PM
Don't you mean "byte me" in reference to Android icon? :lol: I shouldn't try to be funny after only just having breakfast.

Also, yes, it will all go, I did think of removing the log table last night but saw it had at least two references and couldn't be arsed chasing them down last night.
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 04:12 PM
Quote from Arantor on January 23rd, 2013, 03:27 PM
Don't you mean "byte me" in reference to Android icon? :lol: I shouldn't try to be funny after only just having breakfast.
Well I thought the pun was obvious to begin with........ :whistle:
Oh, and when zipped (dunno about gzipped), it's "only" 3 extra bytes.
Quote
Also, yes, it will all go, I did think of removing the log table last night but saw it had at least two references and couldn't be arsed chasing them down last night.
I just finished reviewing your latest commit, and didn't realize you'd already removed that much ;)
I can understand you'd be tired at some point!
Title: Re: New revs - Public comments
Post by: Arantor on January 23rd, 2013, 04:56 PM
It is a pretty big change, and I was trying to prune language strings as I went...
Title: Re: New revs - Public comments
Post by: Nao on January 23rd, 2013, 05:54 PM
Yup, I can see that, and in French too ;)

Re: parse_bbc(), I'll leave it as it is for now... Feel free to change it by yourself if you feel inspired!
Title: Re: New revs - Public comments
Post by: Nao on January 29th, 2013, 10:42 AM
So, I'm looking at the latest commit, plenty of good stuff, and a couple of things that required my attention:

- error.lock (cool thing BTW) is never created. Why doesn't it go through the same logic as the other lock file..? :geek:

- It's amusing that I never understood the logic in that Subs-Login block, and with your rewrite it's even fuzzier in my mind... :lol:

- The ob_end_clean() function is often called in SMF/Wedge, but never the same way. Sometimes it's just it, other times it's done with a while() on ob_get_level(), and finally my method: a single-line while (@ob_end_clean()); that will delete all buffers and stop at the last (because when none are left, PHP returns false.)
I modified all of the calls that seemed to require deleting all buffers, to do that single-line while() instead. Hopefully everything'll be okay.

- ob_end_clean() is called multiple times in the anti-prefetch code. I'm bothered with that one. First of all, having the same code repeated all over Wedge is a bit ugly, so I moved it to Subs.php in a preventPrefetch() function.
I need opinions on two things here:

- I added a $always parameter to it specifically for the call in MessageIndex, because it also sends a 403 when trying to load a board while the action is attempting to load an attachment. So this becomes basically preventPrefetch($and_also_if_loading_attachment), where $always will bypass the prefetcher test. That seems ugly to me... Isn't it?

- If MessageIndex prevents loading topics to ensure they're not 'read', why not do the same on topic pages..? Prefetching the next page means that if you're on a topic with 10 unread pages, next time you click on the topic from the MessageIndex list, you'll have skipped an entire page because it was marked as read... Instead of preventing prefetching, we could also just check whether the prefetcher is loading the current page, and if yes, skip updating the topic read/page read tables... But that means when we get to reading the actual page, it's loaded from the cache, and thus the tables aren't updated either. It would make more sense if prefetchers also sent an asynchronous extra request to that page to tell it that it's actually been read... But it's unrealistic to expect them to do it.
- At this point, do we want prefetchers at all on Wedge?! If not, then... robots.txt... Disallow Fasterfox. There may be other prefetchers to prevent, too. Or just add a rule to the htaccess file, I dunno.

Woohoo, Opera has just changed my textarea's font to a serif font... WHILE TYPING.?
Good job! And then it crashed on me. At least that serif problem was a good warning. Then I launched Chrome, and it crashed on me before I had time to send this.

It's interesting that back in my Windows XP + 2GB RAM days, I was able to run Opera with up to 900 tabs, albeit very slowly...
Now with Windows 7 + 8GB RAM, I've never been able to get above 200 tabs in Opera without it making my life hell, and Chrome is actually behaving better but after 400 tabs it's also much harder to work with...
Anyway!
Title: Re: New revs - Public comments
Post by: Arantor on January 29th, 2013, 01:50 PM
Quote from Nao on January 29th, 2013, 10:42 AM
So, I'm looking at the latest commit, plenty of good stuff, and a couple of things that required my attention:

- error.lock (cool thing BTW) is never created. Why doesn't it go through the same logic as the other lock file..? :geek:
Because while cache.lock should be present at all times, error.lock probably won't be for a good number of people. The @touch should create it.
Quote from Nao on January 29th, 2013, 10:42 AM
- It's amusing that I never understood the logic in that Subs-Login block, and with your rewrite it's even fuzzier in my mind... :lol:
Don't worry, it took me a few goes to make sense of it.
Quote from Nao on January 29th, 2013, 10:42 AM
- The ob_end_clean() function is often called in SMF/Wedge, but never the same way. Sometimes it's just it, other times it's done with a while() on ob_get_level(), and finally my method: a single-line while (@ob_end_clean()); that will delete all buffers and stop at the last (because when none are left, PHP returns false.)
I modified all of the calls that seemed to require deleting all buffers, to do that single-line while() instead. Hopefully everything'll be okay.
That should be fine. Most of the original uses of it predate being able to rely on ob_get_level which only became available in PHP 4.2 (SMF used to support PHP 4.1)

It always seemed to me to be clearer to indicate what you're doing and the one-liner, while efficient and compact, is not exactly conducive to its meaning. I'm cool with it, until I forget what it does and have to mentally shift to make sense of it ;)
Quote from Nao on January 29th, 2013, 10:42 AM
- ob_end_clean() is called multiple times in the anti-prefetch code. I'm bothered with that one. First of all, having the same code repeated all over Wedge is a bit ugly, so I moved it to Subs.php in a preventPrefetch() function.
I need opinions on two things here:
I don't remember that in the anti-prefetch code. I thought it just caused things to die if it was trying to process a prefetch.
Quote from Nao on January 29th, 2013, 10:42 AM
- I added a $always parameter to it specifically for the call in MessageIndex, because it also sends a 403 when trying to load a board while the action is attempting to load an attachment. So this becomes basically preventPrefetch($and_also_if_loading_attachment), where $always will bypass the prefetcher test. That seems ugly to me... Isn't it?
I'm not sure I follow how we get from messageindex to attachment :/ But I've only just got up.
Quote from Nao on January 29th, 2013, 10:42 AM
- If MessageIndex prevents loading topics to ensure they're not 'read', why not do the same on topic pages..? Prefetching the next page means that if you're on a topic with 10 unread pages, next time you click on the topic from the MessageIndex list, you'll have skipped an entire page because it was marked as read... Instead of preventing prefetching, we could also just check whether the prefetcher is loading the current page, and if yes, skip updating the topic read/page read tables... But that means when we get to reading the actual page, it's loaded from the cache, and thus the tables aren't updated either. It would make more sense if prefetchers also sent an asynchronous extra request to that page to tell it that it's actually been read... But it's unrealistic to expect them to do it.
Doesn't the display code have a prevent prefetch on it as well? Could have sworn it did.
Quote from Nao on January 29th, 2013, 10:42 AM
- At this point, do we want prefetchers at all on Wedge?! If not, then... robots.txt... Disallow Fasterfox. There may be other prefetchers to prevent, too. Or just add a rule to the htaccess file, I dunno.
The thing about prefetchers is that most of the time it's done purely with headers which can't always be sifted out so easily. Remember, not everyone uses Apache and not everyone has htaccess files even if using Apache.
Quote from Nao on January 29th, 2013, 10:42 AM
Woohoo, Opera has just changed my textarea's font to a serif font... WHILE TYPING.?
Good job! And then it crashed on me. At least that serif problem was a good warning. Then I launched Chrome, and it crashed on me before I had time to send this.

It's interesting that back in my Windows XP + 2GB RAM days, I was able to run Opera with up to 900 tabs, albeit very slowly...
Now with Windows 7 + 8GB RAM, I've never been able to get above 200 tabs in Opera without it making my life hell, and Chrome is actually behaving better but after 400 tabs it's also much harder to work with...
Anyway!
You should use a real browser like Chrome instead of this hipster Opera :P :P :lol:
Title: Re: New revs - Public comments
Post by: Nao on January 29th, 2013, 06:08 PM
Quote from Arantor on January 29th, 2013, 01:50 PM
Don't worry, it took me a few goes to make sense of it.
Everything related to logging in escapes me, actually.
Guess what is the latest thing my girlfriend asked me..? She wants me to build her a small testcase where I'll supply a form for her to log into a site, and generate a session cookie. I'm okay with the form, but... Oh my, I know the basics of cookies and session communication, but it suddenly seems like I can't do anything about this! Argh.
Quote
It always seemed to me to be clearer to indicate what you're doing and the one-liner, while efficient and compact, is not exactly conducive to its meaning. I'm cool with it, until I forget what it does and have to mentally shift to make sense of it ;)
Oh, I'm sure you'll at least remember this conversation....
Quote
I don't remember that in the anti-prefetch code. I thought it just caused things to die if it was trying to process a prefetch.
Yep, but before dying it deletes the buffers. I guess the idea is that there's no reason to waste time calling gzipping and sessrewrite just for an error message that's here to save bandwidth...
Quote
I'm not sure I follow how we get from messageindex to attachment :/ But I've only just got up.
The 'particular' piece of code was in Load.php, IIRC, not MessageIndex, sorry about that.
But MI still has a preventPrefetch() call. And Display doesn't, to answer your question.
Quote
The thing about prefetchers is that most of the time it's done purely with headers which can't always be sifted out so easily. Remember, not everyone uses Apache and not everyone has htaccess files even if using Apache.
I don't even know if people still use prefetchers these days... And whether or not Fasterfox is still the only one around!
Also, robots.txt isn't an Apache tech, so it should work on every server. (Provided the file is uploaded at the root of the domain name, if available.......)
Title: Re: New revs - Public comments
Post by: Arantor on January 29th, 2013, 06:55 PM
Quote
Everything related to logging in escapes me, actually.
Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.
Quote
Guess what is the latest thing my girlfriend asked me..? She wants me to build her a small testcase where I'll supply a form for her to log into a site, and generate a session cookie. I'm okay with the form, but... Oh my, I know the basics of cookies and session communication, but it suddenly seems like I can't do anything about this! Argh.
The complexity of the testcase is the key thing here. If it's just about setting a session on validation then logging in, that's about as easy as it gets. Anything more than that really depends on how hardened it has to be against brute forcing.
Quote
Oh, I'm sure you'll at least remember this conversation....
Probably. Or more likely I'll find it, think WTF, remember that we discussed it, then swear at the search facility for a moment until I find this conversation.
Quote
The 'particular' piece of code was in Load.php, IIRC, not MessageIndex, sorry about that.
But MI still has a preventPrefetch() call. And Display doesn't, to answer your question.
Display.php, lines 86-92...?
Quote
I don't even know if people still use prefetchers these days... And whether or not Fasterfox is still the only one around!
Also, robots.txt isn't an Apache tech, so it should work on every server. (Provided the file is uploaded at the root of the domain name, if available.......)
robots.txt isn't an Apache tech, no. But not all prefetchers respect it, which brings me back to things in the headers (i.e. like FF used to do, hence the test for the X-Moz header) which can't be sifted out in robots.txt, but can in htaccess - if you're using Apache.
Title: Re: New revs - Public comments
Post by: Nao on January 29th, 2013, 11:31 PM
Quote from Arantor on January 29th, 2013, 06:55 PM
Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.
I understand the basic idea, just not the execution... ;)
Quote
The complexity of the testcase is the key thing here. If it's just about setting a session on validation then logging in, that's about as easy as it gets. Anything more than that really depends on how hardened it has to be against brute forcing.
I don't think security is an important matter here, it's mostly about an intranet thingy...
I don't even get what she needs exactly. Apparently it's some complicated tech and they need to have a cookie in their browser that already contains the ID and password info, and transmit it to the remote server to get access without having to actually do the logging in... Except that AFAIK, it's not possible to locally create a cookie that's "visible" to a remote server without actually being on it first... (?) Maybe it could be done via the stuff we discussed the other day about a remote server for serving downloads... But I don't even know if that's what her team wants.
I'm telling you, it's complicated...
Quote
Probably. Or more likely I'll find it, think WTF, remember that we discussed it, then swear at the search facility for a moment until I find this conversation.
Oh, reminds me, how about implementing that select box for search scoping?
Or do you want me to copy-paste it directly from my noisen code? No problem really... I just tend to forget it ;)
Quote
Display.php, lines 86-92...?
Yes indeed, the problem was that I unchecked that file when committing (because of a partial commit I didn't wanna do), and then only based my assumption on the changelog list of files, ah ah.
Only problem, once I committed... I forgot to remove said partial commit from the file :P
So it has a paragraph now, that should be gone... And I think I'll also remove it locally. I wanted to add an e-mail icon in the mini-menu, but it isn't worth the effort -- it can be found in the profile area, and for guests the mini-menu doesn't show up anyway and it's replaced by said e-mail icon... Anyway! I removed the paragraph locally, it'll be in my next commit.
Quote
robots.txt isn't an Apache tech, no. But not all prefetchers respect it, which brings me back to things in the headers (i.e. like FF used to do, hence the test for the X-Moz header) which can't be sifted out in robots.txt, but can in htaccess - if you're using Apache.
But if Display prevents prefetching, WHERE the hell is it actually USEFUL to have prefetching...? Lol. Might as well prevent it entirely...
At worst, we should actually do that test right at the beginning, e.g. in index.php, instead of while in the action array.
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on February 3rd, 2013, 08:53 PM
Nao, test also this(http://cdnjs.cloudflare.com) CDN:
http://cdnjs.cloudflare.com/ajax/libs/jquery/1.9.0/jquery.min.js

I use it and seems reliable and fast!

Uptime and speed:
http://stats.pingdom.com/4jg86a2wqei0/687131
Title: Re: New revs - Public comments
Post by: Nao on February 3rd, 2013, 10:16 PM
Bump for my post above. I think that doing that robots.txt thing or htaccess or whatever should be discussed.

@Lorenzo> I'm surprised a CDN not advertised on jquery.com would offer it..? Anyway, isn't this only for cloudflare customers?
I wouldn't be fussed over whether we should add it or not, but I just don't know if they're going to keep up with jQuery's releases, precisely because they're not officially sanctioned. It'd be a disaster if I started having to check whether all CDNs provide the version I'm targeting... Right now I'm only doing a special test for beta versions -- forcing the CDN to code.jquery.com (which is the only one to host beta versions), in case a beta or RC tag is found in the filename. (I think that one's a good idea. :cool:)
Quote from Arantor on February 3rd, 2013, 04:29 AM
! Did I mention that I love the @language embedding into script files?
I'm not sure, but that's the idea :)

I've had a look at your code, and you're too kind with suggest.js, you shouldn't have kept the opt.sTextDeletItem stuff at all I'd say... ;) Who's going to change it anyway..? A plugin? Bad semantics, bad karma!

Also, I was thinking we could rename pm.js to member.js and instead include in that file all of the small functions that aren't targeted to guests... e.g. the draft auto-save, things like that. But if it forces members to load the PM JS code on every page where draft auto-saving is required (for instance), it might not be that helpful.
Haven't looked at all the functions that could benefit from being moved there.
Quote
Set a default string from index, set it once and never have to explicitly set it again in any of the multiple places it is called (unless you *really* want to).
Yup, definitely the idea ;)
Quote
All this for the 'delete item' help text on the auto suggest... it's the same everywhere, so just embed it in to the suggester as a default! It bugged me, mkay? (all files)
Yep yep yep, my you're scaring me! :lol:
Quote
@ And since it's now embedded in the suggest file, it will not only be gzipped and cached, it no longer has to be inlined into all the pages it's in, or declared in those pages where used. I would imagine that's actually a tidy little saving everywhere that uses the auto suggester, all in all. Every little helps.
Okay, seriously... Have I started tainting you with my madness? I'm so sorry... :^^;:

Anyway, I did a few @language stunts when I implemented the thing, then I pretty much stopped because of a bug which I only fixed recently, and then I was too busy with other things to think of it.

I looked into the code and found some more...

- txt.done in spellcheck.js -- however, I'd advise against adding it for one reason: if you're not using the default language, you'll get another instance of your language name in the spellcheck JS URL, while the txt.done string seems to be initialized only in the spellcheck popup. Actually, I'd be interested in knowing why spellcheck.js is loaded at all in the editor, when all of the operations are done from the popup (which can load the JS file by itself...)

- your very own draft auto-save code :) I don't think there's anything preventing that one from being passed on.

- the YUI uploader -- we need to rewrite it to use HTML5, by the way... :-/

- the upshrink description for toggles could be a 'default' instead of being explicitly set (it's the only text string that's actually sent to them, except from a few "-" here and there.) Either with something like altExpanded: 'default', or not setting it at all in the HTML -- although we'd have to ensure that it 'works' on all toggles that don't specify an alt. It's important to check on this one -- it's on every single page! :)

- message_txt_delete in wedgeAttachSelect is a given :)

- register.js always uses the same regTextStrings, with the Register page adding a few strings compared to the Reminder page. We could, instead of sending the text strings, send a boolean determining whether register.js will use one set of strings or the other.

That's all I could find for now... (Okay, "forever", since I'm unlikely to do that again!)
I searched through "JavaScriptEscape($txt", by the way, in case you know of a few places where we don't sanitize the strings when passing them to JS. I don't think there are any ;)

Do you want to do them all, or split the job, or let me do them?
Whichever you prefer. Right now I'm busy at work on splitting skeleton stuff anyway.
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on February 3rd, 2013, 10:27 PM
Quote from Nao on February 3rd, 2013, 10:16 PM
@Lorenzo> I'm surprised a CDN not advertised on jquery.com would offer it..? Anyway, isn't this only for cloudflare customers?
I wouldn't be fussed over whether we should add it or not, but I just don't know if they're going to keep up with jQuery's releases, precisely because they're not officially sanctioned. It'd be a disaster if I started having to check whether all CDNs provide the version I'm targeting... Right now I'm only doing a special test for beta versions -- forcing the CDN to code.jquery.com (which is the only one to host beta versions), in case a beta or RC tag is found in the filename. (I think that one's a good idea. :cool:)
It should be worth a look:
http://blog.cloudflare.com/cdnjs-the-fastest-javascript-repo-on-the-web

It supports IPv6, SSL, SPDY and it's available to all. :)
Title: Re: New revs - Public comments
Post by: Arantor on February 3rd, 2013, 11:00 PM
Quote
@Lorenzo> I'm surprised a CDN not advertised on jquery.com would offer it..? Anyway, isn't this only for cloudflare customers?
How could they enforce it? I'd rather not tie into CF to be honest.
Quote
Who's going to change it anyway..? A plugin? Bad semantics, bad karma!
I did wonder about that, but I thought since it was configurable, there was really no reason for me to make it unconfigurable as such. But yeah, realistically I don't see anyone looking to remove it any time soon.
Quote
e.g. the draft auto-save, things like that.
I'd rather the draft autosave be attached to the editor to be honest. In practical respects it makes little difference; there aren't many cases where guests will be able to post (so we won't be loading the editor anyway)
Quote
Haven't looked at all the functions that could benefit from being moved there.
Hmm. I'm not entirely convinced it's necessarily that big a deal. I think I'd rather keep code tied to the function which uses it, personally.
Quote
Yep yep yep, my you're scaring me! :lol:
Truth be told, it was just in the midst of the ban code that I've been working on and it just hit me that this is being done - and I realised that there was no reason to keep doing it. I thought it was a good use of about 15 minutes.
Quote
- txt.done in spellcheck.js -- however, I'd advise against adding it for one reason: if you're not using the default language, you'll get another instance of your language name in the spellcheck JS URL,
Well, this strikes me as a reason not to do it there - if we keep the spell check, and I'm not entirely sold on that yet. For my money we need to support enchant if we're keeping it going forward (and I can't seem to get enchant to play nicely), and browsers often do a better job anyway.
Quote
I don't think there's anything preventing that one from being passed on.
Yeah, works for me.
Quote
- the YUI uploader -- we need to rewrite it to use HTML5, by the way...
That'll get done when the rewrite gets done. I spy a plugin that has related code ;)
Quote
- the upshrink description for toggles could be a 'default' instead of being explicitly set (it's the only text string that's actually sent to them, except from a few "-" here and there.) Either with something like altExpanded: 'default', or not setting it at all in the HTML -- although we'd have to ensure that it 'works' on all toggles that don't specify an alt. It's important to check on this one -- it's on every single page! :)
I have to be honest I always found the entire toggle code something of a strange one, it always seemed more complicated than it had to be. But yes, getting it 'right' would be important.
Quote
- message_txt_delete in wedgeAttachSelect is a given :)
Yup.
Quote
- register.js always uses the same regTextStrings, with the Register page adding a few strings compared to the Reminder page. We could, instead of sending the text strings, send a boolean determining whether register.js will use one set of strings or the other.
Hmm. Need to look at that and figure out exactly what's needed there. I don't remember the code off the top of my head. Maybe there's a more elegant solution.
Quote
Do you want to do them all, or split the job, or let me do them?
Whichever you prefer. Right now I'm busy at work on splitting skeleton stuff anyway.
I'm still tying up the ban stuff before moving onto the profile, but I'm sure I can sneak the odd one in, in between wrangling with the insanities of the old ban system.
Posted: February 3rd, 2013, 10:44 PM
Quote
* Naoism: comment typos. Also, Pete, you must have a 4K screen if you're able to read that MessageIndex comment without scrolling... ;) (MessageIndex.php, Pin.php)
Or not. MBP 17" = 1920x1200. Just see the attached.
Title: Re: New revs - Public comments
Post by: Nao on February 21st, 2013, 11:28 PM
Woohoo, long post above... Forgot to reply blah blah... :(

Will try to do tomorrow.

In the meantime -- just looking at a commit... Did we discuss the changing of message bodies to mediumtext?
It's not that I mind -- I'm all for dropping the 64KB text size limit and all, but... It adds at least a byte to every single post, maybe two, whatever, and it probably has a (small) impact on performance as well...

Does it only need to be discussed..?
Title: Re: New revs - Public comments
Post by: Arantor on February 21st, 2013, 11:32 PM
Quote
In the meantime -- just looking at a commit... Did we discuss the changing of message bodies to mediumtext?
We did discuss it ages ago and with the same questions.

I could not find any evidence to support that it made any difference on performance other than the extra byte in the table. A byte is a byte after all, but even on a multi-million post forum you're talking an MB or two out of multiple GBs of data.

The bigger issue was the forcing of dropping of fulltext but realistically it would have required significant extra reworking (for little benefit) - because in later MySQL versions it's available for InnoDB (something not supported in the code anyway) and the only time it ever saved you performance was when you were so small that even unindexed searching wasn't a problem anyway.
Title: Re: New revs - Public comments
Post by: Nao on February 22nd, 2013, 10:13 AM
Oh... So, the removal of fulltext is what was pre-required to switch bodies to mediumtext...?
So, one bird with two stones? :)
Title: Re: New revs - Public comments
Post by: Arantor on March 15th, 2013, 04:05 PM
r1996 - "Because the quick URLs ended with a '='"

Yeah, anything that encodes content to base64 to put it in the URL (search results, skin selection) and it's the last parameter has somewhere between 1/3 and 2/3 chance of being broken by this. But it's an optimisation that isn't really necessary to perform.
Posted: March 15th, 2013, 04:21 AM

r1997 - I thought I'd said not to touch Class-SFTP because I was going to replace it with an updated version shortly? In fact, I'm scared of doing that because I don't really want to keep simplifying it over and over and over and just want to keep it easily maintainable next time around, so I was going to just include it as-is... formatting etc. as is, white-space as is, multitude of files as-is.
Title: Re: New revs - Public comments
Post by: Nao on March 15th, 2013, 04:27 PM
Quote from Arantor on March 15th, 2013, 04:05 PM
r1996 - "Because the quick URLs ended with a '='"

Yeah, anything that encodes content to base64 to put it in the URL (search results, skin selection) and it's the last parameter has somewhere between 1/3 and 2/3 chance of being broken by this.
I just never noticed anything breaking.. Otherwise I'd have looked into it, like I did yesterday. Were you aware of this..?
Regarding base64, the filler ='s mystified me for quite a while, when I discovered web programming. Not so much, now, but still ;)
Quote
But it's an optimisation that isn't really necessary to perform.
Which one..?
Quote
r1997 - I thought I'd said not to touch Class-SFTP because I was going to replace it with an updated version shortly?
Yes, but you didn't :P
Pete, here's how things go in my deranged mind.
"Don't touch the file. It'll hurt you.
- Okay."
"Hmmmmmmmm..... It'll be too hard for me. I'll just ignore the file. Like, forever."
Then I met the unpack() crash in the captcha code, and decided, as I often do, to do a thorough check of the codebase to remove any similar calls, but I also looked at unpack(), dunno why, and found a ton of them in Class-SFTP... And the first one I looked at, was in the middle of an odd broken line. It hurt me immediately, and I endeavored to fix it. Then I found another one... And another one... And realized it could mostly be fixed by a regex... But it still took me an hour to fix most of it all. Needless to say, had I know how long it'd take to fix, I'd have left the file alone... Forever! But you know, well, that's me... It's like a drug.

To give you an idea, currently I'm thinking of harmonizing all $_REQUEST['sa'] calls to always have the variable set, and maybe replace $context['action'] with a never-empty $_REQUEST['action'], so I can avoid globaling $context if not needed... (Although I don't think it would save a lot of globals... If any!)

But honestly, I also know it'd be best that I work on some actually INTERESTING feature, like rewriting the PM template to use Msg, or making thought-likes Ajax-friendly, or adding the mini-menu to thought contexts... Or doing mass-upload or spectrum analyzer in JS... And it's always, "oh my, too much work, and I only have this much time left..."
Quote
In fact, I'm scared of doing that because I don't really want to keep simplifying it over and over and over and just want to keep it easily maintainable next time around, so I was going to just include it as-is... formatting etc. as is, white-space as is, multitude of files as-is.
"multitude"..? There's only one file...?
Oh, you mean taking the guy's next version..?
Well, if it's like get-id3 or exifixer... I stopped insisting after a while ;)
Title: Re: New revs - Public comments
Post by: Arantor on March 15th, 2013, 04:32 PM
Quote
I just never noticed anything breaking.. Otherwise I'd have looked into it, like I did yesterday. Were you aware of this..?
I wasn't aware that pretty URLs did that, but on my local site I never, ever use PURLs anyway.
Quote
Which one..?
Stripping trailing =.
Quote
It's like a drug.
I understand this, only too well.
Quote
like rewriting the PM template to use Msg
Doesn't it already?
Quote
"multitude"..? There's only one file...?
Oh, you mean taking the guy's next version..?
There's only one file because I spent two days combining it into one file and making his syntax nicer for us to read. But I won't do that next time for the simple reason that it was two days trudging through a lot of files for fairly little benefit. It's not like I can just magically drop all the dependencies if I want to use SSH to upload stuff, since pretty much everything is cross-dependent.
Title: Re: New revs - Public comments
Post by: Nao on March 15th, 2013, 11:30 PM
Quote from Arantor on March 15th, 2013, 04:32 PM
I wasn't aware that pretty URLs did that, but on my local site I never, ever use PURLs anyway.
Oh, that's right, you never do. Well, I guess there aren't a lot of URLs here that end in a base64-encoded fashion... Perhaps in the admin area..?
Quote
Quote
Which one..?
Stripping trailing =.
Indeed, I never really bothered with that, I simply left the Pretty URLs code 'as is', AFAIK, although I *may* have written that part back when I was helping with the mod, I don't know, it's years back...
And generally, I tend to leave things alone, for fear of breaking something I didn't consider.
Quote
Quote
like rewriting the PM template to use Msg
Doesn't it already?
Nope... Msg is only used in topics. My goal with mini-skeletons really was to be able to easily use Msg in Recent Posts, it's always been an issue for me. (Recently, I started getting upset over the fact that recent posts don't show attached files, too.)
Quote
There's only one file because I spent two days combining it into one file and making his syntax nicer for us to read. But I won't do that next time for the simple reason that it was two days trudging through a lot of files for fairly little benefit. It's not like I can just magically drop all the dependencies if I want to use SSH to upload stuff, since pretty much everything is cross-dependent.
Yup, then it's just like Subs-Exif and getid3, i.e. "at first I did my best to fix the code, but then I didn't want to bother re-adapting it every time I updated it, so..."

Oh, next commit will be rev 2000...!
If you're committing something tonight, please consider references to Symphony X's "V: The New Mythology Suite" and Princess Arete's soundtrack, more precisely this(http://www.animelyrics.com/anime/princessarete/krasnosontse.htm)... The former is my favorite symphonic metal album (it's an absolute masterpiece to my ears, and I'm sure you love it too...??!!), the latter is my favorite fairy tale movie (and a lot of 'favorite (fill in the blanks)' whatever you want, really.)
I watched it tons of times and even talked with the director a couple of years ago. With my broken Japanese, it must have been funny. ;) In fact, that's what the very last post at nao.noisen.com was about. (Yeah, rusty French, I know... :^^;:)

Anyway!! I wanted to commit a Warm rewrite I had in the works for some time, but I discovered a few issues that the current version doesn't have, so it'll wait for another moment. I'm also about to commit a Media template overhaul, but it's not that fascinating. Finally, I'd like to ask... How interesting would it be to force the loading of common.css on every CSS file, including non-index/sections ones, without having to specify the file in our list...? I'm saying this because I noticed that media.css does a bad trick to apply display: inline-block to something, and I'd rather use the common.css mixin for that, but I'm a bit wary of adding more processing time to Wess just for that reason...
Title: Re: New revs - Public comments
Post by: Arantor on March 15th, 2013, 11:38 PM
Quote
Oh, that's right, you never do. Well, I guess there aren't a lot of URLs here that end in a base64-encoded fashion... Perhaps in the admin area..?
Not even in the admin area. It's primarily search results and the skin selector.
Quote
Nope... Msg is only used in topics. My goal with mini-skeletons really was to be able to easily use Msg in Recent Posts, it's always been an issue for me. (Recently, I started getting upset over the fact that recent posts don't show attached files, too.)
It might not use the msg skeleton but it uses the template.
Quote
If you're committing something tonight
I'm not. I've been poking around with various things I'm not happy with in the admin area (language editor, smiley stuff, message icons) and not really making any headway with any of it in a way I like. No-one seemed interested in my wanting a 3DS icon :/ (Wedge actually works reasonably well on a 3DS, btw, save for the numbers in note/notewarn/notenice type classes)
Quote
How interesting would it be to force the loading of common.css on every CSS file, including non-index/sections ones, without having to specify the file in our list...?
Makes sense, provided there's not a huge bandwidth hit I guess.
Title: Re: New revs - Public comments
Post by: Arantor on March 19th, 2013, 02:19 PM
r2008 - I suspect the main reason for legalise_bbc was Karl ;)

Also, given the changes to the languages to de-Britishise things, I'm tempted to get my own back(!) by adding English (UK) to the SVN. Thoughts? There's some practical advantages, it will helpfully mean I won't be tempted to keep Britishisms in the trunk, and more than that, it will give me proper testing for the whole language caching thing where it stores other languages in the cache too.
Title: Re: New revs - Public comments
Post by: Nao on March 19th, 2013, 02:33 PM
Quote from Arantor on March 19th, 2013, 02:19 PM
r2008 - I suspect the main reason for legalise_bbc was Karl ;)

Also, given the changes to the languages to de-Britishise things, I'm tempted to get my own back(!) by adding English (UK) to the SVN. Thoughts? There's some practical advantages, it will helpfully mean I won't be tempted to keep Britishisms in the trunk, and more than that, it will give me proper testing for the whole language caching thing where it stores other languages in the cache too.
I'm all for having a UK language file in there, of course! British are cool. (Matt Smith voice.)
Hell, it's long overdue. And I knew you planned to have one anyway. And it'd be easy to maintain -- just keep the lines that change, once the English fallback is restored...
Or you could have a 'patch' system that tells Wedge to change this or that word on the fly. But I can hardly see that one as working for anything else than British English... Brazilian, maybe..? Don't remember... And local variations, of course. Well, maybe it's not that bad an idea.
Oh, I used that page to do the final conversions:
http://www.lukemastin.com/testing/spelling/cgi-bin/database.cgi?action=rules
I knew most of the rules, but not all. Also, not all US '-ise' words are listed, but I trusted my instincts whenever I wasn't sure. I also converted -ising and -ised.
Title: Re: New revs - Public comments
Post by: Arantor on March 19th, 2013, 02:40 PM
Quote
I'm all for having a UK language file in there, of course! British are cool. (Matt Smith voice.)
:lol:

Yeah, that's the plan. I'm working on the fallback right now. I'm not sure how Brazilian is going to work, whether I need to figure out some 'language invoking another language' but I can't see any way that can meaningfully work all that well.

English UK falling back to English US works well enough, and I'm fine with English US being a master fallback, but other than that, I don't see a way that isn't horrific and troublesome. I'll finish up the loading of English US as a fallback.

Also, EmailTemplates.french.php doesn't work properly; the accented characters are encoded in ANSI, not UTF-8. I've fixed it locally and will commit it with my next commit.
Title: Re: New revs - Public comments
Post by: Nao on March 19th, 2013, 04:03 PM
Oh, I hope you don't mind, but I hijacked your 'pop-culture references' part ;)
I don't mind that you get to commit a few things and thus choose something for the corresponding year, but I felt that not having anything at all was a sad waste of mindfuck :P
Quote from Arantor on March 19th, 2013, 02:40 PM
Yeah, that's the plan. I'm working on the fallback right now. I'm not sure how Brazilian is going to work, whether I need to figure out some 'language invoking another language' but I can't see any way that can meaningfully work all that well.
Me neither... :-/
Quote from Arantor on March 19th, 2013, 02:40 PM
English UK falling back to English US works well enough, and I'm fine with English US being a master fallback,
Even though these damn Americans came second, we know!! :P
Quote from Arantor on March 19th, 2013, 02:40 PM
Also, EmailTemplates.french.php doesn't work properly; the accented characters are encoded in ANSI, not UTF-8. I've fixed it locally and will commit it with my next commit.
I'm surprised I didn't catch that... :-/
I may forget it for new files, because it's ISO by default IIRC, but it's an old file, I thought I'd converted them all...
Or maybe I left it aside because e-mails weren't sent (or aren't sent??) using UTF...?
Title: Re: New revs - Public comments
Post by: Arantor on March 19th, 2013, 04:13 PM
Well, it was the 'desc' translations rather than the actual bodies, but I never understood the pressing need for entities. To my mind, UTF-8 content is going to be UTF-8 content in the database anyway, and it's not going to have every non ASCII character entity-encoded. Since there are plenty of cases of non-preset content being injected, there are always going to be cases where UTF-8 content will be transposed into emails, and that must by definition be working - because if it wasn't, there would be a ton of complaints - but there aren't.

So it's a non-issue from my perspective.
Quote
I'm surprised I didn't catch that...
I didn't catch it when reviewing the diff because WinMerge doesn't get uppity about that - it does show the encoding in the footer but I don't really take notice of that because it's something I don't normally need to look at.
Title: Re: New revs - Public comments
Post by: Nao on March 19th, 2013, 04:27 PM
Oh, now I know... I think EmailTemplates was ISO earlier, because it didn't have any accents in it. I added accents when I translated your 'desc' strings... :^^;:

Also...

- Although I'm not enchanted with the idea (when it comes to updating website files via FTP, it's two or three extra folders to check out), I guess it'd make sense to put all languages into their own folders, for simplicity. If you don't want that, then good; if you do, then I won't oppose it.
Quote from Arantor on February 3rd, 2013, 11:00 PM
I did wonder about that, but I thought since it was configurable, there was really no reason for me to make it unconfigurable as such.
Well, there are many settings we never hesitated to remove to make room for others or just breathing space... ^^
Quote from Arantor on February 3rd, 2013, 11:00 PM
But yeah, realistically I don't see anyone looking to remove it any time soon.
I'd rather the draft autosave be attached to the editor to be honest. In practical respects it makes little difference; there aren't many cases where guests will be able to post (so we won't be loading the editor anyway)
Speaking of which. Isn't it feasible (ah, finally got the spelling right!) to just keep the editor out of topic pages, and when clicking 'Full editor', load it through Ajax instead...? I'm not afraid of these Ajax calls anymore. :P And it would save quite many bytes to topic page.
Quote from Arantor on February 3rd, 2013, 11:00 PM
Quote
- txt.done in spellcheck.js -- however, I'd advise against adding it for one reason: if you're not using the default language, you'll get another instance of your language name in the spellcheck JS URL,
Well, this strikes me as a reason not to do it there - if we keep the spell check, and I'm not entirely sold on that yet. For my money we need to support enchant if we're keeping it going forward (and I can't seem to get enchant to play nicely), and browsers often do a better job anyway.
Speaking of spellcheck, I'd like to point out, the buttons/spell.png file is still in SVN... Shouldn't we remove it? It's not used anywhere right now...
Quote from Arantor on February 3rd, 2013, 11:00 PM
I have to be honest I always found the entire toggle code something of a strange one, it always seemed more complicated than it had to be.
In SMF, definitely. Nearly 4900 bytes of crap! Wedge reduces the (uncompressed) code to about 2300. It's still useless, but at least it's the size it should be!

Regarding JS, I have more issues on my side with the reqWin rewrite. Well, just one really. Before committing it, I'd like to ask: is it really worth having a flexible first parameter..? 99% of all calls are "reqWin(this)". This then takes the href param in the owner anchor. Then there are, IIRC, four other calls:
- say/ask both pass an empty string as the first parameter, because they don't want to provide a title anyway; doing $('') shouldn't cause any trouble, so no need for the extra test;
- there's an occurrence in Active Topics (from John) and one in one of your plugins (I think it's WedgeDesk, I'm not sure though), where it sends reqWin('url string'). I've fixed Active Topics to do it the 'proper' way, i.e. put the URL into the href (so that it actually gets prettified and optimized by Wedge... I think??!!), and do reqWin(this) instead.
- I didn't fix yours, because it's more complicated... It's in your attachment code, have a look, in WedgeDesk-Display.php. Do you think it's fixable, if anything..?

The only thing I can say is, while it's a good thing to say "reqWin can open a custom URL if you provide it in the first parameter", I don't know if it's worth the extra 3 bytes of code to account for this when it's actually used nowhere at all in Wedge...?

(And please, please please say "yes it's worth it, now bugger off with your three petty bytes".. I'll feel better about it!)
Quote from Arantor on February 3rd, 2013, 11:00 PM
Quote
* Naoism: comment typos. Also, Pete, you must have a 4K screen if you're able to read that MessageIndex comment without scrolling... ;) (MessageIndex.php, Pin.php)
Or not. MBP 17" = 1920x1200. Just see the attached.
Now that's pretty crazy... ;)
I still prefer for // comments at the end of a line of code to be either very short (a few words at most), or moved to their own line (or move, if needed). That's pretty much a 'SMF/Wedge coding guideline' to me... Do you think you could do that in the future..?
Title: Re: New revs - Public comments
Post by: Arantor on March 21st, 2013, 06:53 PM
Quote
Oh, now I know... I think EmailTemplates was ISO earlier, because it didn't have any accents in it. I added accents when I translated your 'desc' strings...
Nothing wrong with that. It's now UTF-8, and I glanced through the first half a dozen French files and they all seemed to be UTF-8, so it's probably OK.
Quote
- Although I'm not enchanted with the idea (when it comes to updating website files via FTP, it's two or three extra folders to check out), I guess it'd make sense to put all languages into their own folders, for simplicity. If you don't want that, then good; if you do, then I won't oppose it.
The only real issue with doing it vs not doing it is that we already have about 40 files per language, multiplied by the number of languages installed by Shitastico and friends when translations are available (remember, SMF has around 70 language packs) and that can start to cause other issues.
Quote
Well, there are many settings we never hesitated to remove to make room for others or just breathing space... ^^
True, but it seemed like such an easy thing to keep compatibility for.
Quote
Speaking of which. Isn't it feasible (ah, finally got the spelling right!) to just keep the editor out of topic pages, and when clicking 'Full editor', load it through Ajax instead...? I'm not afraid of these Ajax calls anymore. :P And it would save quite many bytes to topic page.
Yes, if you want to load the JS files and code dynamically, followed by all the requisite event handling. It's doable but it's really not pretty.
Quote
- there's an occurrence in Active Topics (from John) and one in one of your plugins (I think it's WedgeDesk, I'm not sure though), where it sends reqWin('url string'). I've fixed Active Topics to do it the 'proper' way, i.e. put the URL into the href (so that it actually gets prettified and optimized by Wedge... I think??!!), and do reqWin(this) instead.
WedgeDesk has a bunch of reqWin(this), reqWin(this.href) and a couple of weird reqWin instances. I have a vague memory of those being related to showing attachments in a popup window, but Zoomedia would be infinitely better in this case.

WedgeDesk is also one of the issues around attachments/media items, to ensure permissions remain tied to the helpdesk and not anything else.
Quote
I still prefer for // comments at the end of a line of code to be either very short (a few words at most), or moved to their own line (or move, if needed). That's pretty much a 'SMF/Wedge coding guideline' to me... Do you think you could do that in the future..?
I'll try :)
Posted: March 19th, 2013, 04:43 PM

OK, upcoming change I'm not entirely happy about.

The 'correct' behaviour is for loadLanguage to complain bitterly if a given language file doesn't exist - even if there will be a suitable fallback, it is still going to complain about the missing file. The only problem is that a small percentage of the language files for English UK will be identical to English US (e.g. so far the Home language file is in that category), so I need to include a placeholder for those so that I don't write exceptions directly into loadLanguage for a fringe language case. I don't like it either but it's the least worst alternative.
Title: Re: New revs - Public comments
Post by: Nao on March 24th, 2013, 05:32 PM
Was just wondering... When you did your add_linktree conversions, did you check whether $context was being used elsewhere in the functions..? It's likely they are of course (we've been putting so many things in that one :P), but I'm asking so I can know whether I should bother checking myself, or not ;)
Quote from Arantor on March 21st, 2013, 06:53 PM
The only real issue with doing it vs not doing it is that we already have about 40 files per language, multiplied by the number of languages installed by Shitastico and friends when translations are available (remember, SMF has around 70 language packs) and that can start to cause other issues.
Yeah, that's true...
Considering I'm the only one who'd be annoyed by the change (i.e. having to move my FTP updates to one extra folder), it's probably best to just ignore me and move them to their own folders. :)
Quote
Yes, if you want to load the JS files and code dynamically, followed by all the requisite event handling. It's doable but it's really not pretty.
How pretty it is depends on what you're ready to give up on, eh eh.
Personally, I'd say that the less Display is crowded, the prettier it is overall.
As always, my main concern is with reactivity. But as long as the main editor is there, and Ajax is called only when going for 'full editor', I don't really see any issues with it.
i.e., loading smileys and buttons through Ajax seems like a given to me, but the wysiwyg and non-wysiwyg editors, along with their shortcuts etc, should always be loaded.

Also... I've been considering the recent discussion on shift+enter. As I said, I allowed touch devices to run the function automatically on Enter (since it doesn't have shift), and it's a life-changer when trying to quote stuff. (Not likely to push me into doing it more regularly, but at least it makes my life less miserable, should I ever want to do it on mobile!)

I was wondering whether we shouldn't be inverting the process on desktop..? Enter splits quotes by default, and Shift+Enter prevents it. It's very tempting. But I think I won't do it, because of one main issue: imagine you're typing something, then doing [b], then typing more, and pressing Enter... Oh! You didn't want to close the tag, did you..? I don't see how to avoid that. Maybe, hmm... Maybe keeping a copy of the original post and checking whether the line we just split was present in the original post. If it was, smart-split. Otherwise, ignore the split.
I can't think of a cleaner way, hm...
Quote
WedgeDesk has a bunch of reqWin(this), reqWin(this.href) and a couple of weird reqWin instances.
reqWin(this.href) is wrong code. Perhaps inherited from an old version of Wedge..? Can't remember how I used to do it. (I fixed it manually. I have tons of compatibility-related updates I'll commit at some point for plugins... 29 files, half of which are from WedgeDesk.)
Quote
I have a vague memory of those being related to showing attachments in a popup window, but Zoomedia would be infinitely better in this case.
Probably, yeah...
I'd still like for you to look into your code for WD and tell me if you can think of a better way of doing it. The onclick stuff, I mean.
Quote
I'll try :)
:thanks:
Quote
The 'correct' behaviour is for loadLanguage to complain bitterly if a given language file doesn't exist - even if there will be a suitable fallback, it is still going to complain about the missing file. The only problem is that a small percentage of the language files for English UK will be identical to English US (e.g. so far the Home language file is in that category), so I need to include a placeholder for those so that I don't write exceptions directly into loadLanguage for a fringe language case. I don't like it either but it's the least worst alternative.
I can understand you don't like the idea... And, I'll just say, I agree I'd rather not do it that way.

I'm thinking, *maybe* we could have a 'special setting', such as $txt['parent_language'] = 'english' or something, that says Wedge shouldn't worry about missing files, and instead look for the file inside the 'english' folder. What do you think..?

And yes. I know US English isn't UK English's parent, it's the other way around. Now get off my lawn :P
Title: Re: New revs - Public comments
Post by: Arantor on March 27th, 2013, 01:54 PM
Quote
did you check whether $context was being used elsewhere in the functions..?
No, I didn't. But any place with a linktree is also going to be setting the title, which is a context variable.
Quote
Considering I'm the only one who'd be annoyed by the change (i.e. having to move my FTP updates to one extra folder), it's probably best to just ignore me and move them to their own folders.
I'm not overly looking forward to the changes in the language editor, or for that matter, themes[1] with their own language files.
Quote
How pretty it is depends on what you're ready to give up on, eh eh.
Personally, I'd say that the less Display is crowded, the prettier it is overall.
As always, my main concern is with reactivity. But as long as the main editor is there, and Ajax is called only when going for 'full editor', I don't really see any issues with it.
Generally, that's fine.
Quote
i.e., loading smileys and buttons through Ajax seems like a given to me, but the wysiwyg and non-wysiwyg editors, along with their shortcuts etc, should always be loaded.
Ah... that's where you and I differ. WYSIWYG pretty much demands the buttons from a usability perspective and realistically the buttons are more important to me than the shortcuts are.
Quote
I was wondering whether we shouldn't be inverting the process on desktop..?
I don't know. I just know I hate crazy and inconsistent interfaces - you know my thoughts about Enter vs Ctrl Enter on Facebook for example ;)
Quote
reqWin(this.href) is wrong code. Perhaps inherited from an old version of Wedge..? Can't remember how I used to do it. (I fixed it manually. I have tons of compatibility-related updates I'll commit at some point for plugins... 29 files, half of which are from WedgeDesk.)
Actually, it's probably from SMF originally.
Quote
Probably, yeah...
I'd still like for you to look into your code for WD and tell me if you can think of a better way of doing it. The onclick stuff, I mean.
I don't remember much of WD, mostly it was brute-force conversion of SD original to whatever was current in Wedge at the time.
Quote
I can understand you don't like the idea... And, I'll just say, I agree I'd rather not do it that way.

I'm thinking, *maybe* we could have a 'special setting', such as $txt['language_parent'] = 'english' or something, that says Wedge shouldn't worry about missing files, and instead look for the file inside the 'english' folder. What do you think..?
The problem with a language indicating its parent like that means you implicitly have to load the file twice - load index once, learn that you need to have a parent, load the parent, reload the index to reinstate changes from that. Though once you've done that, you can avoid it further.

I dunno. I don't really like what's in SVN but I think it's best for now since it does actually enforce that you know you have all the files you should.
Posted: March 24th, 2013, 05:47 PM
Quote
* Because the registration agreement is a special language string that's explicitly parse_bbc'd
Which means now what's in the database is explicitly different to what's used for actual users, but heigh ho and all that. Reason: preparsecode will convert out all the line breaks.
Quote
This also makes them easier to use them as base for your own registration agreement.
Please tell me why a user would do this. Translators are the only people who should be looking at raw language files.
Quote
Missing file. Note that Home files are not supposed to be in the final distro, and that I'm sure I'll forget all about it soon enough, but whatever...
So users who get the final distro are going to be expected to hand code stuff? Might as well write off Wedge now then because most users do NOT want to hand code ANYTHING. If anything, not only does it need to stay but it needs an admin UI as well.
 1. Assuming we still have *themes* as things that can replace entire template files
Title: Re: New revs - Public comments
Post by: Nao on March 28th, 2013, 10:37 AM
Code: [Select]
<?php
- if (empty($group['name']) || empty($group['type']) || empty($group['classic']) || empty($group['simple']))
+
if (empty($group['name']) || empty($group['type']) || empty($group['name']))
Your removal of simple permissions seems to have been done, to a point, on auto-pilot. Just look at the line above, with a test repeated twice...
At some point you renamed 'simple' and 'classic' to 'name', at other points to 'group'. I suspect the one above should say 'group' instead of 'name', but I'm not sure, I haven't tested anything. I'm just trying to update all the plugins to use the new permissions, and I'm stuck with that.
Quote from Arantor on March 27th, 2013, 01:54 PM
No, I didn't. But any place with a linktree is also going to be setting the title, which is a context variable.
True enough. Although not always done... (e.g. notification action.)
Quote
I'm not overly looking forward to the changes in the language editor, or for that matter, themes[1] with their own language files.
 1. Assuming we still have *themes* as things that can replace entire template files
(It is so tempting for me to remove themes as a feature entirely, because skins can do so much more... The only thing they have for themselves, is the ability to replace a template file. But it should be possible to simply put these files into our skin files... Why not?! I'm so familiar with my skin code, and so unsure about theme code... Heck, I've never tried to install an additional theme in Wedge. Everything can be done with skins so...)
Quote
Ah... that's where you and I differ. WYSIWYG pretty much demands the buttons from a usability perspective and realistically the buttons are more important to me than the shortcuts are.
By shortcuts, I mean keyboard shortcuts themselves, not the text that mentions the list of keyboard shortcuts.
Thanks to shortcuts (which are dealt by a cached JavaScript file, and thus always available), even in Wysiwyg mode you can easily bold a text by pressing Ctrl+B, if you're used to Word or Wordpad or Write or whatever... Of course, the browser has to cooperate, too -- there are some that use this shortcut for a bookmark popup, like Sleipnir (my current default) or IE IIRC. Still. I don't see a need for buttons in most cases.
Quote
Quote
I was wondering whether we shouldn't be inverting the process on desktop..?
I don't know. I just know I hate crazy and inconsistent interfaces - you know my thoughts about Enter vs Ctrl Enter on Facebook for example ;)
Yes, absolutely, but in this case it'd be more consistent because it'd be enabled everywhere.
I'll tell you my preference -- the way it's done right now. But the sane and consistent choice? Probably the other way around, I guess...
Quote
Actually, it's probably from SMF originally.
Ah, yes indeed!
And it was unneeded. No need to waste HTML for 'this.href' when we can pass 'this' and then get the href in the cached JavaScript.
Apparently, the SMF team thought it was still too short though, so they renamed the whole thing to reqOverlayDiv(this.href) :lol:

To think that I've always considered renaming reqWin() to just popup()... :^^;: (I don't know why I'm not doing it.)
Quote
I don't remember much of WD, mostly it was brute-force conversion of SD original to whatever was current in Wedge at the time.
So, I take it it's untested, right..?
Quote
The problem with a language indicating its parent like that means you implicitly have to load the file twice - load index once, learn that you need to have a parent, load the parent, reload the index to reinstate changes from that. Though once you've done that, you can avoid it further.
Hmm...

- load default index.english.php
- load language (English UK, French...) index
- do nothing.
- cache results.

Then, later:
- load default specificfile.english.php
- if $txt['lang_parent'] != 'english', load specificfile.$txt['lang_parent'].php, if not there, ERROR.
- attempt to load specificfile.language.php -- if not there, if empty($txt['lang_parent']) ERROR (because we ARE supposed to have a full file in this case), else ignore.
- cache results.

And that's the worst case scenario, to me...?
Quote
Quote
* Because the registration agreement is a special language string that's explicitly parse_bbc'd
Which means now what's in the database is explicitly different to what's used for actual users, but heigh ho and all that. Reason: preparsecode will convert out all the line breaks.
I don't know, Pete.
All I know is that SMF has this:

Code: [Select]
$context['agreement'] = parse_bbc(file_get_contents($boarddir . '/agreement.' . $user_info['language'] . '.txt'), true, 'agreement_' . $user_info['language']);

And you have a similar one, except you're using $txt instead of file_get_contents.
The rest is the same, i.e. you parse_bbc it. If you didn't want it to be parsable, you should remove the parse_bbc call and revert the $txt strings to use HTML instead.
Quote
Quote
This also makes them easier to use them as base for your own registration agreement.
Please tell me why a user would do this. Translators are the only people who should be looking at raw language files.
Well, exactly... I was talking about translators, in this case.
In which case, having a long line of text will be annoying to translate for them, unless they enable wrap mode, but not everybody thinks of that. (Heck, I pretty much never enable wrap mode, except when I have to read a TXT file that was built that way...)
Quote
Quote
Missing file. Note that Home files are not supposed to be in the final distro, and that I'm sure I'll forget all about it soon enough, but whatever...
So users who get the final distro are going to be expected to hand code stuff? Might as well write off Wedge now then because most users do NOT want to hand code ANYTHING. If anything, not only does it need to stay but it needs an admin UI as well.
What do you mean, Pete? They get the Welcome template by default. Which is geared towards a 'starting' forum. Heck, I can't bother to write the UI for the default homepage target, allowing for users to choose whether they want to target a specific page, or action, or board list, or specific board (or even topic, why not...)

The purpose of the differentiation between Home and Welcome is that in the case of Home, I could distribute it separately from the package, but the entire package itself is suppose to be comprised only of files that should NOT be modified. Well, Welcome is here to say, "create your own homepage now... And name it differently!", it doesn't do that yet, but that's the idea.
I know that as a forum admin hobbyist, back in the day, I wanted to change the homepage but was wary of having my changes overwritten by new forum updates. In the end, I had to create patches and other horrible things.

One of my goals with Wedge (and yours, see plugin system!) is to allow users to update their forum files without any influence over their modifications (as long as they follow the guidelines to modify things.) First thing for that is to allow for the homepage (most often modified page) to be overridden and redirected to another page of yours.

Your post wasn't very... lively... Any problems..?
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 04:00 PM
Quote
At some point you renamed 'simple' and 'classic' to 'name', at other points to 'group'. I suspect the one above should say 'group' instead of 'name', but I'm not sure
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.
Quote
True enough. Although not always done... (e.g. notification action.)
Fairly sure I gave the notification action a title some days ago.
Quote
(It is so tempting for me to remove themes as a feature entirely, because skins can do so much more... The only thing they have for themselves, is the ability to replace a template file. But it should be possible to simply put these files into our skin files... Why not?! I'm so familiar with my skin code, and so unsure about theme code... Heck, I've never tried to install an additional theme in Wedge. Everything can be done with skins so...)
Can a skin replace part of index.template.php?
Quote
So, I take it it's untested, right..?
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.
Quote
I don't know, Pete.
All I know is that SMF has this:
And I see no reason off hand why this should even work. preparsecode has always converted line breaks out - always.
Quote
And you have a similar one, except you're using $txt instead of file_get_contents.
The rest is the same, i.e. you parse_bbc it. If you didn't want it to be parsable, you should remove the parse_bbc call and revert the $txt strings to use HTML instead
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.
Quote
Well, exactly... I was talking about translators, in this case.
In which case, having a long line of text will be annoying to translate for them, unless they enable wrap mode, but not everybody thinks of that. (Heck, I pretty much never enable wrap mode, except when I have to read a TXT file that was built that way...)
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)
Quote
What do you mean, Pete? They get the Welcome template by default. Which is geared towards a 'starting' forum. Heck, I can't bother to write the UI for the default homepage target, allowing for users to choose whether they want to target a specific page, or action, or board list, or specific board (or even topic, why not...)
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.
Quote
First thing for that is to allow for the homepage (most often modified page) to be overridden and redirected to another page of yours.
So instead of giving them the barest bones tools for the job, we need to give them more powerful tools.
Title: Re: New revs - Public comments
Post by: Nao on March 28th, 2013, 06:30 PM
Quote from Arantor on March 28th, 2013, 04:00 PM
: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.
So may I leave everything to you on this..? It was quite a large patch, so I know it's not going to be fun...

Hmm, a bug with the auto splitter... Sometimes it inserts two blank lines after opening the quote again. Uh.
Quote from Arantor on March 28th, 2013, 04:00 PM
Fairly sure I gave the notification action a title some days ago.
Yup, yup, you probably did. I'm talking about the original commit.
Quote from Arantor on March 28th, 2013, 04:00 PM
Can a skin replace part of index.template.php?
Nope. It's the mission of Custom.template.php, where you can declare template_whatever_override() to replace a function.
We discussed it at length back in the day. Having template files inside skin folders is very doable, but it's not 'clean'. I'm always torn between the two sides of the problem, eh...
Quote from Arantor on March 28th, 2013, 04:00 PM
And I see no reason off hand why this should even work. preparsecode has always converted line breaks out - always.
And parse_bbc() has this near the beginning:

$message strtr($message, array("\n" => '<br>'));
Meaning what it means... ;)
(And you noticed that too, now that I'm reading the rest of your post.)
Quote from Arantor on March 28th, 2013, 04:00 PM
I'm not being funny but did you even look at the UI in the admin panel for this?
I remember looking at it when you committed it. I think I asked a few questions about it, even... But at the time, I don't think it was even possible to change an entry. It had these 'master' things, but that's all... I think.
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
I didn't. I just noticed that adding line breaks manually in the string would add more physical line breaks to the thing. So I checked the code, and noticed the parse_bbc call. Which is why I decided to go for a 100% BBCode version. (Not that there's ANY BBCode in these strings, but... I mean the line breaks...)
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
I don't know either, I'll have to say.
Maybe we could simply remove that line (and fix anything it breaks), remove the parse_bbc call from agreements, and use HTML to break lines. (And still keep line breaks to make the strings breathe. i.e.,

$txt['...'] = 'Hello,
<br><br>
World.';

Would work for me...
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
Yeah but that's no reason to throw a hadōken at me in your previous post, buddy... :lol:
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
Considering the amount of work we still have to finish, I don't see this happen in a realistic time frame. I'd rather we focus on more urgent matters -- translators can work on existing language files, if they're in such a hurry to have it done ;)
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
Perhaps it is. But it's a stock file. It's what I'm doing by default. I'm saying, "now that your Wedge copy is installed, download this separate file, Home.php and its related files, copy them to their respective folders, and point the homepage to Home, so you can have the Wedge.org homepage code on your site. Now you can modify it all you want (if you want!), because a Wedge upgrade will never overwrite it.
Quote from Arantor on March 28th, 2013, 04:00 PM
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.
There's always room to improve all of that, yeah. But it's not something I'm willing to do for now... There are many complex features I want to add to Wedge, and by now I think that it's more reasonable to postpone them to a 1.1 or 2.0 version. v1.0 is only the beginning... Hopefully..?!
Quote from Arantor on March 28th, 2013, 04:00 PM
So instead of giving them the barest bones tools for the job, we need to give them more powerful tools.
And working on these tools will deprive Wedge of other features that could be added to it, and that could be used by more people... :-/
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 06:38 PM
Quote
So may I leave everything to you on this..? It was quite a large patch, so I know it's not going to be fun...
Eh, it's a one line fix (and even tested)
Quote
Nope. It's the mission of Custom.template.php, where you can declare template_whatever_override() to replace a function.
We discussed it at length back in the day. Having template files inside skin folders is very doable, but it's not 'clean'. I'm always torn between the two sides of the problem, eh...
If you can replace a given template somewhere, that's cool. Though I can see one horrible situation.

master skin
  sub skin 1
    sub skin 2

If both sub skins declare a Custom template, in theory both would have to be included since sub skin 2 is inheriting from sub skin 1 - but if they replace the same things, you're going to get a function collision.
Quote
I didn't. I just noticed that adding line breaks manually in the string would add more physical line breaks to the thing. So I checked the code, and noticed the parse_bbc call. Which is why I decided to go for a 100% BBCode version. (Not that there's ANY BBCode in these strings, but... I mean the line breaks...)
But that's the thing... it's *not the same* as any other bbcode. Any other bbcode in the system will be a long one line string. This is the only area that's different.
Quote
Yeah but that's no reason to throw a hadōken at me in your previous post, buddy...
I'm sorry, I'm operating on something of a frustration level because I seem to be doing the rounds at the moment of explaining my point several times over and no-one's listening :(
Quote
Considering the amount of work we still have to finish, I don't see this happen in a realistic time frame. I'd rather we focus on more urgent matters -- translators can work on existing language files, if they're in such a hurry to have it done ;)
And they can even do what I did: edit it in the editor, the DB will give them a shiny preparsecode'd version of the content. I didn't manually translate anything - I just copied the original agreement.txt into a post and saved it, then grabbed it straight out the DB.
Quote
now that your Wedge copy is installed, download this separate file, Home.php and its related files, copy them to their respective folders, and point the homepage to Home, so you can have the Wedge.org homepage code on your site. Now you can modify it all you want (if you want!), because a Wedge upgrade will never overwrite it.
Then it's still a usability write-off. Only hardcore users are going to want to do that. The rest will just want a nice UI to play with and expect it to remain in place anyway (i.e. stored in the DB)
Quote
And working on these tools will deprive Wedge of other features that could be added to it, and that could be used by more people...
Having content management in the core will encourage more people to use it than not, IMHO.
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on March 28th, 2013, 08:24 PM
I can't see avatars after the site got updated. :)
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 08:31 PM
Also, after clicking on the Notifications option (now it's at the top), it's wrapped under the language icons rather than next to them where it currently is, plus there's no background.

/mecan provide screenshots if needed.
Title: Re: New revs - Public comments
Post by: Nao on March 28th, 2013, 08:36 PM
No need for a screenshot -- as I said in my thoughts, I broke the site™™™™.
I don't know why avatars are invisible, but it's certainly due to loadMemberAvatar(). I'll look into it.

Notifs... Meh!! This is mostly due to the fact that I had to 'backtrack' my CSS code because I was starting to tear everything apart to load as little HTML as possible, and I wasn't sure where exactly I should stop backtracking... I guess I stopped at the wrong place! :^^;:
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 08:41 PM
I know that feeling, heh :)

I'm currently attacking the polls template, separating the elements so I can make a fun plugin ;)
Title: Re: New revs - Public comments
Post by: Nao on March 28th, 2013, 08:53 PM
Avatars fixed...

As for notifications -- I have about 5 minutes left to fix them... So I guess it'll be hard for tonight. I'll just focus on the missing background ;)
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 08:54 PM
/mehas happy thoughts in Nao's direction ;)
Title: Re: New revs - Public comments
Post by: Nao on March 28th, 2013, 09:03 PM
All fixed. :)
Title: Re: New revs - Public comments
Post by: Arantor on March 28th, 2013, 09:28 PM
See... I figured you might ;)

Now, if only I could figure out why wetem::replace isn't working :/
Posted: March 28th, 2013, 09:09 PM

Never mind, I was misinterpreting what it was supposed to do... though whether it's behaving is another question entirely.

If you tell it to replace a layer, it'll work - the layer's content will be replaced. But if you tell it to replace a block on its own, it will do nothing. I'm not sure if this is intended behaviour or not.
Title: Re: New revs - Public comments
Post by: Dragooon on March 29th, 2013, 06:13 AM
So it's now supposed to show all the notifications whether read or unread?
Title: Re: New revs - Public comments
Post by: Dragooon on March 29th, 2013, 10:34 AM
@Nao: It seems notification polling is keeping you permanently online. Perhaps updating last activity should be ignored when notifications are being polled? Or remove polling all together?
Title: Re: New revs - Public comments
Post by: icari on March 29th, 2013, 03:27 PM
when you have no notifications and go to (edited out) it is basically a blank page, maybe there should be some text to say you have no notifications?
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2013, 04:22 PM
This page is in the process of being rewritten anyway...
Posted: March 29th, 2013, 04:17 PM

@Dragooon, polling should be kept, I like it. Maybe add an option to disable it for either admins (low-quality hosting) or users (e.g. "I'm on a data connection, I have limited bandwidth...")

What I'm working on, right now, is to reduce the size of the response to basically just hold the number of unread messages. And maybe also a boolean saying whether another Ajax request should be made to load notifications when you click the box.
It's all, so very complicated... But interesting, too.
Posted: March 29th, 2013, 04:19 PM
Quote from Arantor on March 28th, 2013, 09:28 PM
If you tell it to replace a layer, it'll work - the layer's content will be replaced. But if you tell it to replace a block on its own, it will do nothing. I'm not sure if this is intended behaviour or not.
What you should do in that context is use wetem::rename.

wetem::replace will take the contents of the layer, and empty it.
wetem::rename will change the name of the layer or block, thus effectively emptying a layer, too. It will also obviously change what template functions are called.

Please tell me if it doesn't work as advertised..? I haven't been checking on it for a long time. Additionally, I'm not sure I even tested replace() at all. (I did test rename, though... Had some fun with it back in the day.)
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2013, 04:24 PM
replace works as advertised, it replaces the contents of the layer, it just doesn't replace a given block. I didn't realise I was using the wrong function in that case.

The PiePolls plugin uses this to replace the poll template, which is how I discovered it since it needs to drop topic_poll_results and puts its own block in.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2013, 09:13 PM
Apologies, I was mistaken: rename() is a layer-only function...
There is no equivalent for blocks.
Should I add support for them...?
Title: Re: New revs - Public comments
Post by: live627 on March 29th, 2013, 09:22 PM
Quote from Nao on March 29th, 2013, 09:13 PM
Apologies, I was mistaken: rename() is a layer-only function...
There is no equivalent for blocks.
Should I add support for them...?
Yes, please.
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2013, 09:33 PM
Yup, this is the issue; the pie polls plugin, for example, needs to replace a single block, not an entire layer.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2013, 09:41 PM
Done. :)

It was almost too easy... The hardest part was actually finding block names to test the thing :P
Title: Re: New revs - Public comments
Post by: Arantor on March 29th, 2013, 11:07 PM
Quote
- Hmm... I think Pete forgot to remove a code block after rewriting $context['error_new_replies'] to use number_context(). At least, it generated an error for me, and the variable wasn't used anywhere... (Post.php)
It's used in Post2.php. This particular piece of code is a bit of a clusterfuck but ultimately is the result of the fact that the post code can come from different places and go different places depending on what it has.

See Post2.php for $context['new_replies']. lines 277-295 being the most prominent use.
Title: Re: New revs - Public comments
Post by: Nao on March 29th, 2013, 11:38 PM
I meant $txt['error_new_replies'], not $context. And if you'll do a search on error_new_repl, only Post.php has it... Also WedgeDesk, but I'm not going to fix it, it's your 'game' ;)
Anyway, I double-checked before committing. Please revert if you find anything suspicious.
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2013, 12:26 AM
Eh, I'll revert it and apply the proper fix (because now it's totally broken) next time I commit.

error_new_repl* isn't used... but error_new_replies IS. It's even pulled in just a few lines lower:

Code: [Select]
if ($context['new_replies'] == 1)
$txt['error_new_reply'] = isset($_GET['last']) ? $txt['error_new_reply_reading'] : $txt['error_new_reply'];
else
$txt['error_new_replies'] = sprintf(isset($_GET['last']) ? $txt['error_new_replies_reading'] : $txt['error_new_replies'], $context['new_replies']);

// If they've come from the display page then we treat the error differently....
if (isset($_GET['last']))
$newRepliesError = $context['new_replies'];
else
$post_errors[] = 'new_replies';

$post_errors all get the error_ prefix later. The correct fix would not have been to remove the code (since now it's guaranteed to be broken) as error_new_replies cannot ever be declared properly, but to have replaced error_new_reply with error_new_replies in the $txt declaration.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2013, 01:54 AM
I was technically going to modify the language files, but I figured you'd forgotten to clean this up...
My bad ;)

So you're saying I couldn't catch it before the only actual use doesn't specify the error_ prefix, right..?

Time for bed!
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2013, 05:19 AM
Quote
So you're saying I couldn't catch it before the only actual use doesn't specify the error_ prefix, right..?
Yup, unless you knew specifically that the post error handler was weird, you wouldn't be able to find it short of doing a test on new_reply and new_replies.

The language files are actually correct on this one, the whole point was to convert multiple strings into one number_context string but since there are two different strings to be pulled from (depending on whether you were on the posting page or quick reply), it just harmonises it all into one $txt entry that doesn't exist prior to the error handler being invoked.
Posted: March 30th, 2013, 03:04 AM

Also
Quote
! Unread Replies feature didn't actually set the participation icon. YES, we know that it's always set, as the page name implies... But still, not showing it when there's a legend next to the change is awkward. (UnreadReplies.php)
That's actually intentional. SMF never did it either. Though in SMF's case there's sort of more of a reason. (SMF didn't separate unread and unread replies into a separate file. One big ass function to do it all. I really need to streamline what we have, thinking about it.)
Posted: March 30th, 2013, 03:06 AM

Also also

http://wedge.org/Themes/default/images/icons/quick_poll.gif as referred to in the legend for a board is missing, and I don't see any poll icon anywhere in the test board itself :/
Posted: March 30th, 2013, 03:30 AM

Also, also also, I should have read a little further up, since yes, I did actually replace the commented bit with the one liner. That'll teach me for trying to review code in a bad mood. Not enough rum (haven't had any in ages, bah)
Posted: March 30th, 2013, 03:49 AM

Also also, also also, some debugging code in the rename method, line 172.
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2013, 03:43 PM
Quote
Mind you, I also tried the same on small_delete, but Pete somehow managed to crush the competition here. What tool did you use for that one..?! (small_move.gif)
All I did was take the old quick_delete that got deleted, cropped it to size and dropped it in.
Title: Re: New revs - Public comments
Post by: Nao on March 30th, 2013, 03:51 PM
What software did you use to crop it..?
Title: Re: New revs - Public comments
Post by: Arantor on March 30th, 2013, 03:56 PM
GIMP. I just opened it, cropped it, saved it, committed it.
Title: Re: New revs - Public comments
Post by: Nao on March 31st, 2013, 08:54 PM
I installed the latest Gimp, and it gave me a 78-byte file for your quick_delete.gif, instead of 75... A bit surprising. What's your magic trick, eh..? ;)

Okay, so I'm looking into  that code I removed, looking to see if I was mistaken in flagging it as buggy, but it still strikes me as odd... I can only see problems with it, and I don't think I wanna do any kind of revert. Maybe rewrite the error code to get rid of 'new_reply' and only mention 'new_replies'..?

Here's my reasoning. Please share your thoughts about it.

Code: [Select]
$txt['error_new_replies'] = number_context(isset($_GET['last']) ? 'error_new_reply_reading' : 'error_new_reply', $context['new_replies']);

"error_new_replies, which is a non-existent $txt string to begin with, should be built with the contents of $txt['error_new_reply_reading'] or $txt['error_new_reply'], depending on whether it was triggered after pressing the Reply/Quote button in topic pages, or pressing Submit in the post page. These two $txt items are arrays, thus number_context is there to choose the correct string within these arrays, as well as sprintf them to push the number in place. At this point, we have, for instance, 'Warning - while you were typing, 2 new replies have been posted. You may wish to review your post.' in our variable. So far, so good...

Code: [Select]
if ($context['new_replies'] == 1)
$txt['error_new_reply'] = isset($_GET['last']) ? $txt['error_new_reply_reading'] : $txt['error_new_reply'];

"new_reply should ALSO be set, if there's only one reply. BUT it should have the unedited string array, i.e. $txt['error_new_reply'] is now an ARRAY of unformatted strings... Which doesn't serve any purpose..?!

Code: [Select]
else
$txt['error_new_replies'] = sprintf(isset($_GET['last']) ? $txt['error_new_replies_reading'] : $txt['error_new_replies'], $context['new_replies']);

So, we're resetting the error_new_replies string that we just set a moment ago... :-/
Either with:
1/ A non-existent string, $txt['error_new_replies_reading'] (note the plural), which generates the error that prompted me to remove the code block,
2/ An array of unformatted strings, which we then pass to sprintf, which only accept strings, and not arrays -- another error waiting for us.

Really, I don't see the point.
Title: Re: New revs - Public comments
Post by: Arantor on March 31st, 2013, 08:59 PM
I'm using GIMP 2.6.12 if that's any help.
Quote
So far, so good...
That should be it. As I said, I was wrong. It's the old code that wasn't removed properly, but at first glance looked thoroughly broken because I didn't see the extra line above the removed code that solved the problem, I just saw 'chunk of removed code that sets up variables used later on'.

I've spent a lot of time getting very frustrated lately with a lot of people and a lot of things because I feel like I'm shouting up from inside a well and no-one but me is listening to what I'm saying.

Which is why I'm now working on a new feature and until the feature is done, I'm just going to avoid forums in general, because it's hard to concentrate when I'm in this much of a bad mood.
Title: Re: New revs - Public comments
Post by: Maxx on March 31st, 2013, 11:27 PM
Sorry your feeling bad, Hope it's not me! and sure hope you feel better!

I've been in and out of the hospital the last few days, with head and nerve issues, so please don't mind me!

regards,
Maxx
Title: Re: New revs - Public comments
Post by: Arantor on April 12th, 2013, 08:33 PM
Quote
! The old Profile Notifications page is still there, but it wasn't showing up to do duplicate array entries. (Profile.php)
From r2052... when it was added, it was very deliberately done the way it was so that we would have the thread of where to start when removing the old notifications system because of the new one being added.
Title: Re: New revs - Public comments
Post by: Nao on April 12th, 2013, 09:11 PM
I wanted to rename our new system to 'area=notifications' anyway, so I did that and noticed the other one reappeared, I was the first surprised...
I decided to commit it because at least, it's visible, and we know we have to remove it (or refactor it) at some point...
Title: Re: New revs - Public comments
Post by: Arantor on May 8th, 2013, 12:14 AM
r2094 - JS changes

Well, I just mostly pulled the first stuff out of the templates themselves so they were like that already ;)

As far as functions having ; on the end, wasn't that because Packer needed it?
Title: Re: New revs - Public comments
Post by: Nao on May 13th, 2013, 12:30 PM
Quote from Arantor on May 8th, 2013, 12:14 AM
r2094 - JS changes

Well, I just mostly pulled the first stuff out of the templates themselves so they were like that already ;)
Yep, I only figured out after I changed it ;)
Quote
As far as functions having ; on the end, wasn't that because Packer needed it?
Yes, but as I explained somewhere else, simple function () {} declarations don't require a semicolon, only var func = function () {}; (i.e. anonymous functions, or closures, or whatever) require one. This isn't related to Packer in itself, it's what JavaScript engines expect to see when everything is tightly packed. Either a semicolon, or a linebreak. Packer does semicolons, so we do semicolons. Plus, semicolons are safer in the long run -- there are instances where using linebreaks instead of semicolons will generate bugs (although they're clearly documented.)

Code: [Select]
$fonts = array_filter(array_map('trim', preg_split('~[\s,]+~', $settings['editorSizes'])));

Considering it's stored as linebreak-separated variables, why not just do an explode() on these..? Or even get rid of array_filter and array_map, as I don't see many reasons for this variable to be modified by anything else than Wedge..? And we could do the checking at save time in ModifyPostEditorSettings.

Do you see any uses for disemvowel and scramble functions? Maybe just copying their single-line contents into the main codepath would be enough? I'm not worried about disemvowel(), but scramble() might conflict with other functions with the same name. You never know -- adding an encryption library, or something like that...?

I don't know if it's a bug or something I understood incorrectly, but this infraction point system... When I'm giving someone a sanction, I find myself with having to determine a number of points to give... Why should I, when I can just select a list of pre-defined sanctions, such as hiding the signature...? Or maybe it's admin-only and I should look at how it works for mods?

Done with the checks. Overall, great work! :)
Title: Re: New revs - Public comments
Post by: Arantor on May 13th, 2013, 03:51 PM
Quote
And we could do the checking at save time in ModifyPostEditorSettings.
Sure we could. I'm just doing what I did before with the list of fonts, and that I seem to recall I borrowed from the old reserved names code.
Quote
Do you see any uses for disemvowel and scramble functions? Maybe just copying their single-line contents into the main codepath would be enough? I'm not worried about disemvowel(), but scramble() might conflict with other functions with the same name. You never know -- adding an encryption library, or something like that...?
I suspect there won't be any separate uses so yeah, they could go.
Quote
I find myself with having to determine a number of points to give... Why should I, when I can just select a list of pre-defined sanctions, such as hiding the signature...?
Technically it shouldn't be forcing you to pick some points but there are circumstances where for performance it just assumes 0 points = no current infractions on the account.
Quote
Or maybe it's admin-only and I should look at how it works for mods?
It sort of is. Admins have all the powers, but moderators may or may not depending on what they are given. If a member group is not given ad-hoc infraction powers, the only choices they have are the pre-set ones allocated to their account. The idea is that you set up pre-set ones which cover all the standard cases which makes issuing them little more than a few clicks.

You could always set up a pre-set infraction that doesn't have any points and just removes the signature - then you wouldn't even have to type up the warning text next time, it would be defined ready for you. At least, that's the theory ;)

But I'm more than happy to change it if we find better ways of doing things.
Quote
Done with the checks. Overall, great work!
Thanks :)
Title: Re: New revs - Public comments
Post by: live627 on May 17th, 2013, 12:24 AM
Quote
...! I spent months postponing this because I thought I had to do the query_see_topic implementation as well. Turned out that it was done in late February 2012, over 700 revisions ago
I even made a plugin in April 2012 that plays with topic privacy.
Title: Re: New revs - Public comments
Post by: Nao on May 18th, 2013, 05:23 PM
Lulz.

BTW, it's quite tempting, re: rev 21+21, to go through the codebase and replace all array_intersect() calls with something that's faster...

To be specific, imagine that as a global moderator (but not an admin), you have dozens of permissions applied to you.
If I wanted to know whether you have permission can_do, in_array('can_do', $perms) is very fast. (Not as fast as an isset() test, but whatever.)
Now, if I want to test against can_do and can_eat, array_intersect(array('can_do', 'can_eat'), $perms) can become really, incredibly slow. The more permissions you add to the first or second array, the slower it gets, and exponentially. I've found that doing multiple in_array calls on can_do and can_eat can be much faster. Of course, we're talking minor speed increases, so it's not THAT important... I tested with a request of 3 permissions, all of which being wrong (it's 3 times faster if the first one is true, of course). The $perms array was arbitrarily filled with 110 entries, which is probably twice as many permissions you'll ever need to give someone... Still, array_intersect was approximately 150 times slower than three consecutive in_array tests. I'm not kidding you, guys... Call array_intersect 10.000 times, and we're talking multiple seconds to complete, while it executes in a few milliseconds with in_array().

So, maybe there are other array_intersect() calls to intercept elsewhere, what do you think..?
Title: Re: New revs - Public comments
Post by: Arantor on May 18th, 2013, 07:44 PM
There are probably other array_intersect calls, sure.

As far as permissions, it's long been on my plan to adjust how permissions were loaded and tested (to use isset rather than in_array) but that was part of the permissions overhaul and until I figure out how to make the UI, I won't be touching that.
Title: Re: New revs - Public comments
Post by: Nao on May 18th, 2013, 10:20 PM
Quote from Arantor on May 18th, 2013, 07:44 PM
There are probably other array_intersect calls, sure.
Noticed you added a few, yesterday, actually... ;)
Quote
As far as permissions, it's long been on my plan to adjust how permissions were loaded and tested (to use isset rather than in_array) but that was part of the permissions overhaul and until I figure out how to make the UI, I won't be touching that.
Well, isset() would be good, yes.

My only opinions (not suggestions) about the permission UI, would be that:

- I should be able to get a proper list of permissions, global and per board (and per album), for any given member, with a section in their profile area... (I've been stung with this in SMF; yesterday, I tried giving the same rights to two Noisen mods, and one of them is complaining that he doesn't have the same rights, which seems impossible according to his group list...)

- In the radio box list, I'd personally use dropdowns with an icon on each (green for enabled or enabled_own, red for disabled, another green or some blue for enabled_any). Sure, it's an extra click to change a permission, but then you can add deny permissions, right..? Unless you want to add deny for _own and _any separately, in which case, err... :-/

- I'd like to see the membergroups ajaxified... i.e. when clicking the link to modify their permissions, have it load under the permission name instead, so that you can even load multiple membergroups on one page, and then change them all in a row...

I haven't read the proper topic (yet), though.
Title: Re: New revs - Public comments
Post by: Arantor on May 18th, 2013, 10:26 PM
Quote
I should be able to get a proper list of permissions, global and per board (and per album), for any given member, with a section in their profile area..
SMF has this already, so do we, I just moved it. In SMF, it's Profile > Profile Info > Show Permissions, in Wedge it's Profile > Manage Account > Show Permissions.

It gives you the general permissions and the 'all boards' permissions but lets you select different boards from a dropdown.
Quote
In the radio box list, I'd personally use dropdowns with an icon on each (green for enabled or enabled_own, red for disabled, another green or some blue for enabled_any). Sure, it's an extra click to change a permission, but then you can add deny permissions, right..? Unless you want to add deny for _own and _any separately, in which case, err...
This is what I've been wrestling with. You might want to deny an _any but allow the _own.

If deny permissions weren't an option, I'd do what I did in SimpleDesk which was dropdowns with nice icons.
Quote
- I'd like to see the membergroups ajaxified... i.e. when clicking the link to modify their permissions, have it load under the permission name instead, so that you can even load multiple membergroups on one page, and then change them all in a row...
I'm thinking about it. It gets complex with profiles and stuff, but something along those lines is sot of where I'm going. Still needs more work and I find I need to get a new mouse too >_<
Title: Re: New revs - Public comments
Post by: Nao on June 12th, 2013, 04:25 PM
BTW Pete, are you fine with the tweaks I made to the permissions page..?
I only tried to improve their efficiency, at least for me it's working better that way, I guess...
Title: Re: New revs - Public comments
Post by: Arantor on June 12th, 2013, 05:02 PM
/meis still s bit spaced out, will review in a bit
Title: Re: New revs - Public comments
Post by: Nao on June 12th, 2013, 06:40 PM
I only changed some colors, added title params everywhere (really!), and decided that the gzipped difference is too trivial to care about.
Title: Re: New revs - Public comments
Post by: Nao on June 13th, 2013, 07:35 PM
Okay, I was thinking about this, and decided to discuss it first...

How about, we change the permission page, at load time, to replace the radio buttons with a pseudo-select box?
I'm thinking along the lines of the post icon selector, i.e. a green/black/red icon that you can click, and it shows a small dropdown with all possible choices.

As you probably know, I already did something similar in Noisen with the privacy selector; it's re-using most of the IconList code, and it works very well; in fact, I was even able to add checkboxes to the popup, so it's really comfortable in terms of power, I'd say.

What I'm seeing, in the future, is an IconList that would be entirely configurable; it would rely on some custom JS to turn any kind of item into a dropdown list, along with a callback, to transform it internally back into whatever we want, so that we can apply it to radio buttons, checkboxes, select boxes and so on...

What do you think, guys..? Is it realistic, or even exciting, or just something that's not worth it..?
Title: Re: New revs - Public comments
Post by: Arantor on June 14th, 2013, 01:28 AM
Quote
How about, we change the permission page, at load time, to replace the radio buttons with a pseudo-select box?
I dunno. I did it with SimpleDesk and while I liked it (especially since I folded own/any into it), I don't think it would work for us. Partly because deny wasn't actually an option in the UI. Partly because we can't actually fold own/any into the dropdowns (since there are situations you'd need to give permissions separately and because there are some fubar moments in terms of any overriding own but the UI doesn't cover that aspect)

Though I don't know why we wouldn't just use a standard selectbox and be done with it if we're going to do it. The | option to add text after an item would cover that well enough.

Ultimately I don't think it's the solution to this problem.
Title: Re: New revs - Public comments
Post by: live627 on June 14th, 2013, 09:36 PM
Quote
* PHP 5.2.3+ supports is_callable('class::method') (or even the equivalent function_exists) instead of is_callable(array('class', 'method')), so I figured it's best to use the string format, as it's a bit faster to handle internally.
The same can be applied elsewhere; eg. hooks, schd tasks,, etc.
Title: Re: New revs - Public comments
Post by: Arantor on June 14th, 2013, 09:39 PM
For testing is-callable, sure. But for the actual call, call_user_func / call_user_func_array / the occasions we use variable functions ($function()), I'm not sure whether *they* support class::method or not.
Title: Re: New revs - Public comments
Post by: Sara on November 11th, 2013, 09:16 PM
Quote
* Updated Home template to be more... generic, really. It was tailored for wedge.org, and didn't have a reason to be that way in the repo. While the 'default' is still Welcome, I'd appreciate to get feedback from users -- which one should be the default? (If Home is, then Welcome will be completely removed.) (Home.template.php, Home.language.php)
Forgive my ignorance, regarding the final result, is the Home template the very front page I see when going to wedge.org?  With a blurb about the site, then recent posts, recent thoughts and then the board index?  If that is what you mean in regards to the underlying "Home.template.php" then I would say keep Home instead of Welcome. 
Title: Re: New revs - Public comments
Post by: Nao on November 11th, 2013, 09:31 PM
Yes, that's it.

The Welcome version has "Welcome, hacker!" or something along that line, it's a very limited file. I made Home for Wedge.org, and ended up straightening it out so that it'd remain 'usable' for a default homepage. But then I made a 'fork' of that file, and messed it up in here because I'd renamed it 'Home-Wedge', when I need to have a matching function name in the source files, and dashes aren't accepted in function names. Hence the 5-10 minutes of downtime in here earlier. ;)
Title: Re: New revs - Public comments
Post by: Sara on November 11th, 2013, 09:33 PM
Thanks for the explanation!  I stick with my original conclusion then!  I personally like the Home template better instead of Welcome. :)
Title: Re: New revs - Public comments
Post by: Aaron Smith on November 11th, 2013, 09:46 PM
I agree I like home better too. Makes more sense to me.
Title: Re: New revs - Public comments
Post by: Nao on December 4th, 2013, 12:24 AM
Well, Home is the 'default' one now, and Welcome will only be there as a 'sample', although I could probably get it out of the main repo, and into a 'samples' repo.
Title: Re: New revs - Public comments
Post by: Pandos on December 4th, 2013, 04:15 PM
Translation for new stats is comitted :)
By the way... could you please make the thoughts area "post field" on home a bit larger. Linebreaks (when using german language) are messing up the look&feel.
Title: Re: New revs - Public comments
Post by: Nao on December 4th, 2013, 04:33 PM
Done, but it also means the box is larger for all languages, and may wrap to the next line when replying to a thought, even if the thought isn't too long... :-/
Posted: December 4th, 2013, 04:21 PM

Did you check the $txt['charts'] array, BTW..? Because I *did* make it all up from your original strings, and the addition of 'Alles' and 'Ausses' or something, which I have no idea if they're even grammatically correct...
Posted: December 4th, 2013, 04:23 PM

Also, is there a reason you named your German version 'Deutsch (DE)'...? Why not just 'Deutsch'?
English (US) is only there because British people certainly have a case when it comes to British English being the 'proper one' and US English a derivative (lol). But I've settled on English (UK) because there are more Americans, and non-Americans non-British are probably more used to the US grammar, too, so it needed to be done. But German... It's only spoken *widely* in Germany, right..? So it doesn't need the DE, I'd say.
Title: Re: New revs - Public comments
Post by: Pandos on December 4th, 2013, 04:36 PM
Quote from Nao on December 4th, 2013, 04:23 PM
Done, but it also means the box is larger for all languages, and may wrap to the next line when replying to a thought, even if the thought isn't too long... :-/
Thank you. Looks better now!  8-)
Don't see it as a problem. Do you?
Quote
Did you check the $txt['charts'] array, BTW..? Because I *did* make it all up from your original strings, and the addition of 'Alles' and 'Ausses' or something, which I have no idea if they're even grammatically correct...
It's up to date now.
Title: Re: New revs - Public comments
Post by: Pandos on December 4th, 2013, 04:38 PM
Quote from Nao on December 4th, 2013, 04:33 PM
Also, is there a reason you named your German version 'Deutsch (DE)'...? Why not just 'Deutsch'?
English (US) is only there because British people certainly have a case when it comes to British English being the 'proper one' and US English a derivative (lol). But I've settled on English (UK) because there are more Americans, and non-Americans non-British are probably more used to the US grammar, too, so it needed to be done. But German... It's only spoken *widely* in Germany, right..? So it doesn't need the DE, I'd say.
Yes. Because mainly for the same reasons. We have DE_AT (Austria), DE_CH (Swiss). DE_DE means pure german :)
Title: Re: New revs - Public comments
Post by: Nao on December 4th, 2013, 07:12 PM
PR merged. Phew ;)
We really, really need to find a way to avoid merge issues in the future. How exactly do you update your repo? Is it something done through the BB website, or a manual pull from a different origin from your local repo..? If it's the former, maybe you should try doing the latter. And maybe, hmm... I dunno, rebasing. Ouch. I still don't get why git is so popular. I'm getting around to using some of its intricate arcanes, but it's very, very tough on those who don't know it. You can be an excellent programmer, and suck at handling git.

Anyway.
Austria and Swiss have less German-speaking users than Germany, so I'd really, really push for it to be just called Deutsch. Then, if an Austrian package gets released (probably 'on top' of the German one), it'll just need to be called Deutsch (AT).
Title: Re: New revs - Public comments
Post by: Pandos on December 4th, 2013, 08:26 PM
Update from wedge's original is through BB direct.
Update and Commits through Tortoise.
Perhaps is an idea to have an empty branch. Seems to work. But we'll see after my next commit.


What a switch to the net point :)
I'm OK with changing this to German. But Austrian users speaking native german? :)
That's what I mean with it's the same like US and GB. Therefor the naming is correct. :) But I will change it and we will naming AT and CH otherwise. It's OK for me.
Title: Re: New revs - Public comments
Post by: Nao on December 4th, 2013, 09:03 PM
Quote from Pandos on December 4th, 2013, 08:26 PM
Update from wedge's original is through BB direct.
What's this feature called..?
Quote from Pandos on December 4th, 2013, 08:26 PM
Update and Commits through Tortoise.
Go to Tortoise, settings, Git > Remote, add an 'original' remote, with my repo's URL, then pull changes from there into your local repo, and see if you get a 'merge' in the log or not. If you don't, then maybe you can later push to your repo and be done with it. If you get a merge, try doing a git rebase, then the next time you update, do it through 'git pull --rebase original:master', instead of 'git pull original:master'. I'm sure the latter will do the trick, and will remove any merging artefacts, and thus should allow you to commit your branches without any trouble.
Another alternative might be to 'simply' never update your remote repo with mine, and... well, see if it's working when you attempt to do your pull request. I dunno.

It's important for me to get it right, so that I can direct people to the same method you'll be using. I have no problems with merging on the official repo, as long as it's not too obvious. I'm still on the fence when it comes to my very own, particular situation: I should probably have my own personal remote repo, and do pull requests for my stuff, and then have other people review my commits, or alternatively, push to the official repo only when people say that my own personal repo is working fine for them, etc.
Could, basically, be that the official repo is the stable branch, and my repo is my official dev branch.
Of course, I could also have two branches on the official repo, but... Well, I'm still not into branches. Anything that forces me to stash my work every now and then isn't gonna work for me, at least until I'm really desperate to 'simplify' my workflow. (Ahem!)
Quote from Pandos on December 4th, 2013, 08:26 PM
Perhaps is an idea to have an empty branch. Seems to work. But we'll see after my next commit.
Nope, it's not working... :-/
But don't bother, though. I'd already made the change on my local repo, so the renaming was going to be in the next commit either way.
Quote from Pandos on December 4th, 2013, 08:26 PM
I'm OK with changing this to German. But Austrian users speaking native german? :)
If they have a problem with that, they can always rename their country to Deutschland... Oh, it's already taken? ::)
No, seriously, it's not a matter of nationalities. I just do NOT want to make things complicated to users. Believe me, I've spent enough time wondering whether I should have the main language file called 'English', or 'English (US)'. And I'm still not sure about my decision.
Title: Re: New revs - Public comments
Post by: Pandos on December 4th, 2013, 09:07 PM
Will test it tomorrow when I'm home.
Will test different solutions.

Deutschland is taken? OMG  :niark:

Like I said. I'm fine with renaming it :)
Title: Re: New revs - Public comments
Post by: Nao on December 4th, 2013, 09:56 PM
Keep me posted!
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on January 4th, 2014, 02:12 PM
[master a226178] APC isn't maintained anymore! Should be better to work on Zend Opcache.
Title: Re: New revs - Public comments
Post by: Nao on January 4th, 2014, 10:31 PM
APC is the one installed at alwaysdata so I get to test it firsthand...
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2014, 01:06 AM
Also, regarding the latest commits[1]: follow_me is basically a JS feature I wrote that can be done in pure CSS. Amusingly (or not), I only found out about the CSS version a couple of months after implementing the JS code. It was giving me the exact same result (great minds think alike :P), albeit with a couple of changes to be done in CSS so that it worked interchangeably with or without the CSS support.

Main problem is, the compatibility itself...
- Supported in iOS 6 and above, with no prefix. Can't test myself.
- Supported on Firefox 27 and above, BUT only in Aurora versions. That is, Firefox Beta 27 doesn't show anything. -_-
- Support on current Chrome and Opera versions, desktop and mobile, BUT only behind a flag (and it's not even an 'obvious' flag to enable.)

Let's just say, it's quite a bit early to use 'just' the CSS version, but it's nice to know we can all do it in the future.
 1. I've been revisiting my postponed stuff today. I might as well do my best to get my uncommitted file list down to the smallest possible numbers before I make the codebase public...
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2014, 05:21 PM
Fixed it in Firefox 27. Well, it's not really a bug. It's that Firefox 27+ Aurora has the feature enabled, while Firefox 26 (current stable) doesn't, and Firefox 27 Beta can enable it, but only after enabling a flag.

So, basically, if you'd rather your browser does the UI work rather than its JavaScript engine:
- In current Chrome or Opera, go to about:flags and enable 'Experimental Web platform' (IIRC)
- In Firefox 27 Beta, go to about:config, type sticky in the search and double-click the entry that comes up.
- In other browsers, "stay tuned" until the browser maker gets to wake up. (IE 11, you definitely aren't up to the game.)

The feature can also easily be used in SMF and ElkArte without any JavaScript, but it will only work on the aforementioned browsers, of course. The JS fallback in Wedge will work on old browsers, too, anything that supports position: fixed (i.e. IE7+, Android 4+, iOS 4+ or 5+, can't remember.)
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2014, 05:22 PM
Quote from MultiformeIngegno on January 4th, 2014, 02:12 PM
[master a226178] APC isn't maintained anymore! Should be better to work on Zend Opcache.
Also, I just remembered this: APC is both an opcache and a user data store, while Opcache, AFAIK, is ONLY an opcache, so it only optimizes the PHP file loading, but doesn't allow storing data and replacing the file cache.

Unless I'm mistaken, of course, in which case I'll be happy to implement Zend stuff into Wedge, but really, AFAIK, it's unrelated. Not only that, but APC doesn't work in PHP 5.5 for Windows, so if I wanted a 'fast' system, I'd probably settle on PHP 5.4 + APC, rather than PHP 5.5 alone.

Woot, I'm only 24 posts from the 14k mark... :eheh:
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on January 5th, 2014, 06:18 PM
Yeah it's only an opcache. But APC isn't maintained anyway :P
If you want to test it I can give you access to my VPS with PHP 5.5.6 installed
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2014, 06:38 PM
Quote from MultiformeIngegno on January 5th, 2014, 06:18 PM
Yeah it's only an opcache. But APC isn't maintained anyway :P
But APCu is.
http://windows.php.net/downloads/pecl/releases/apcu/
I installed XAMPP, added the ts-x86-vc11 version of APCu into the ext folder, then enabled both OpCache and APCu in the php.ini file:

Code: [Select]
extension=php_apcu.dll
zend_extension=php_opcache.dll

And it works fine. Actually, it's the first time I ever get APC to work at all on my local install... ;)

Which allowed me to do some more testing, and:
1/ it works, unlike the APC version at alwaysdata,
2/ it's just as slow/fast as the file cache, or memcached. (So, basically: if your cache is on the same file system, it's not worth the hassle, just use the file cache.)

As for OpCache, though, I do notice a slight improvement in performance. About 5% to 10%, perhaps. Again, is it worth the hassle..? Probably not. I'll just say, Wedge is fast enough that the PHP cache is NOT its bottleneck... :P
Still, it's good to be able to test these. I'll keep a copy of XAMPP around.
Quote from MultiformeIngegno on January 5th, 2014, 06:18 PM
If you want to test it I can give you access to my VPS with PHP 5.5.6 installed
Nah, I'm fine now, thanks! Unless you're getting totally different results, of course.
Title: Re: New revs - Public comments
Post by: Nao on January 5th, 2014, 07:48 PM
I redid my PHP 5.5 OpCache tests more seriously.
On a random topic page...
PHP 5.4: 0.14 seconds in average
PHP 5.5: 0.11 seconds in average
PHP 5.5 + OpCache: 0.08 seconds in average.

So, that's definitely worth the hassle, unlike what I said, ah ah.

I also tried multiple levels of file/APCu cache, and all I can say is, I'm getting the exact same numbers whether I'm using APCu, file cache, cache level 1, 2 or 3. It's tempting to remove levels 2 and 3, but... Whatever.

Now, I'm wondering if I should be asking shaitan whether we can use PHP 5.5 on wedge.org... Technically, I have access to the PHP version switch in the admin area, but it doesn't seem to be working, and I don't want to break his forum, which is running SMF and thus probably doesn't support MySQLi, just regular MySQL, which would generate warnings in PHP 5.5. :-/
Title: Re: New revs - Public comments
Post by: Farjo on January 21st, 2014, 09:06 PM
Quote, from New Revs thread: Should I keep posting new revs here, when you can now just access the rev log here..?
https://github.com/Wedge/wedge/commits/

Is there a way to receive notifications of new revs? Personally I like reading them; even though I understand very little it does give an indication of areas that are being changed / added.


Another quote: Apparently, MySQL doesn't like being asked the unsigned keyword on bit fields. It should have been smart enough to ignore them, but whatever... (install.sql)
While I'm at it, minor regex simplifications. (install.php)

So one assumes that one can download those two files only and have the latest version of Wedge? (ie along with the zip I downloaded this morning[1].) And if so is there an easy was to do this as I am on hostel WiFi so downloading a Zip and uploading its contents is unfair.
 1. this afternoon Paris time
Title: Re: New revs - Public comments
Post by: Nao on January 21st, 2014, 10:46 PM
Quote from Farjo on January 21st, 2014, 09:06 PM
Is there a way to receive notifications of new revs?
You can also subscribe to the RSS feed.
https://github.com/Wedge/wedge/commits/master.atom
It doesn't give you the number of line additions and deletions, though, which is a mood killer for me. I like being able to differentiate between "quick fixes" and "large commits".

Other than that, I'm planning to write some kind of script that'll use the RSS feed to get new commit IDs, then use the GitHub API to receive statistics for each of these commits, and then post them to a specific topic. This'll make a perfect candidate for a plugin, but honestly, if someone else could write it for me, I'd be thrilled... :P
Quote from Farjo on January 21st, 2014, 09:06 PM
Personally I like reading them; even though I understand very little it does give an indication of areas that are being changed / added.
And I like that people are reading them ;)
Quote from Farjo on January 21st, 2014, 09:06 PM
So one assumes that one can download those two files only and have the latest version of Wedge?
Yes. But apparently, some servers don't play nice.
I made a test install on my Wamp server, and it worked.
I made a test install on wedge.org, and it worked.
If it doesn't work elsewhere, it'll need fixing, but it's EXACTLY the reason I needed to go public at some point... Because there are more setups out there, and they need to be accounted for.
Title: Re: New revs - Public comments
Post by: Farjo on January 23rd, 2014, 03:19 AM
"If I do one at a time I'll be done in 10 years"
 :lol: Only understood this once I looked at the change in github :)

"is there an easy was to do this (update my installation with the latest rev.s) as I am on hostel WiFi so downloading a Zip and uploading its contents is unfair."
I've found that if I click on Commits it gives a list of commits, and clicking on each of these gives a list of changed files. And so I can download the latest zip and overwrite these files only :) (And I assume I have to clear the cache too.)
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on April 5th, 2014, 03:20 AM
Regarding commit eda89f6: there's a function in Google Analytics I think where you can let googlebot login (you provide credentials).
Title: Re: New revs - Public comments
Post by: live627 on April 5th, 2014, 04:14 AM
Quote
Removing the 'Posterity' link on your thoughts if they're not public.
Am I the only one who used that on a "self" thought?
Title: Re: New revs - Public comments
Post by: madfitz on April 5th, 2014, 07:52 AM
Quote from Farjo on January 23rd, 2014, 03:19 AM
"is there an easy was to do this (update my installation with the latest rev.s) as I am on hostel WiFi so downloading a Zip and uploading its contents is unfair."
I've found that if I click on Commits it gives a list of commits, and clicking on each of these gives a list of changed files. And so I can download the latest zip and overwrite these files only :) (And I assume I have to clear the cache too.)
Or use Github for Windows. Clone the repo then it will only download the latest changed files.
Title: Re: New revs - Public comments
Post by: Farjo on April 5th, 2014, 10:12 AM
Quote from madfitz on April 5th, 2014, 07:52 AM
Quote from Farjo on January 23rd, 2014, 03:19 AM
"is there an easy was to do this (update my installation with the latest rev.s) as I am on hostel WiFi so downloading a Zip and uploading its contents is unfair."
I've found that if I click on Commits it gives a list of commits, and clicking on each of these gives a list of changed files. And so I can download the latest zip and overwrite these files only :) (And I assume I have to clear the cache too.)
Or use Github for Windows. Clone the repo then it will only download the latest changed files.
Thank you - yes that's what I do now, and then an FTP client synchronises what's on my PC to the web space. It's still a way away from a one-click solution but it's easier with less chance of missing changes.
Title: Re: New revs - Public comments
Post by: Nao on April 8th, 2014, 08:13 PM
Quote from Farjo on April 5th, 2014, 10:12 AM
Thank you - yes that's what I do now, and then an FTP client synchronises what's on my PC to the web space. It's still a way away from a one-click solution but it's easier with less chance of missing changes.
Eventually, I'll stick my finger out of my arse, and I'll write a module to automatically update files from github as long as you're using an alpha or beta install.

Then again, it'll probably come *after* I write the code to automatically update files on non-alpha versions. (Which, in this case, will only retrieve official releases.)
Title: Re: New revs - Public comments
Post by: Farjo on April 8th, 2014, 10:11 PM
Coool!
Title: Re: New revs - Public comments
Post by: Nao on April 8th, 2014, 11:17 PM
It'd be practical even for me.... :P

I have so many things to add before I can call it beta material.... :-/
UI for contact lists.
UI for auto-updates.
Web installer.
Soft-deletion of posts...
What else..? I don't remember. So many...

:edit: Also, a quick editor to determine which elements to put onto the homepage.
Title: Re: New revs - Public comments
Post by: Farjo on April 9th, 2014, 09:42 AM
Contact lists needs doing, but perhaps the rest can start the list for version 1.1 of Wedge. What you have now is already so much better than SMF.

If you wait until everything is completed then everyone else will have released their versions, some of Wedge's membership will have gone and you will be fed up / burnt out.

OTOH releasing sooner, once all loose ends are tied up / tidied away will attract users and you may get more offers of help.

[1]
 1. A few months ago you may have thought "He just wants to get his hands on the software" but it is available and is being used live in many locations, so I have no conflict of interest :)
Title: Re: New revs - Public comments
Post by: MultiformeIngegno on May 11th, 2014, 08:38 PM
Are SVG bigger than GIF for flags?
Title: Re: New revs - Public comments
Post by: Nao on May 12th, 2014, 01:12 AM
I don't now. For instance, with the German flag, simplifying it to only use 3 colors would bring the GIF size down to 99 bytes. After embedding and gzipping, it should be between 90 and 110 bytes. With SVG, I'm guessing it would have to be a bit more than 100 bytes just for the code itself, but it might compress much better. Still, SVG isn't supported by IE 6-8, so I don't know if it's worth dropping these to save a few bytes.

The change from PNG to GIF allowed me to save over 300 bytes per flag. Now THAT was worth it!! ;)

(BTW, I don't know if I'll keep the ability to have a PNG version around... I noticed that the board list needed a flag test as well, and it sucks. I'd probably have to store the actual extensions in the database or something, meh.)