-
Feel free to discuss anything interesting you see about the changelog updates!
-
* encodeURIComponent() has been supported as far back as IE 5.5, so there's no reason to use SMF's way of emulating it
* php_strtr uses charAt when it could use [] instead. It's a bit faster, which is good in long loops. (script.js)
I'm letting them be for now because they're testing for %u in the URL, which only happens in escape()'d strings
-
* 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 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.* php_strtr uses charAt when it could use [] instead. It's a bit faster, which is good in long loops. (script.js)
I'm letting them be for now because they're testing for %u in the URL, which only happens in escape()'d strings
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.
-
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
! If a timezone has no slash in it (such as 'UTC'), the timezone retrieval code will generate a warning. (ManageSettings.php)
-
I meant '30 lines instead of 40'. Changelog error, sorry.
-
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.
Which is why it's only used in sha1.js... :)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)
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
-
Is my fix okay for you? Feel free to rewrite it... I only fixed the error, really.
Your number convert function -- isn't he comma_format stuff going to kill performance if used on a larger scale...?
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.
-
Is my fix okay for you? Feel free to rewrite it... I only fixed the error, really.
Your number convert function -- isn't he comma_format stuff going to kill performance if used on a larger scale...?
Posted: August 1st, 2011, 10:21 AM
So, who's going to convert the rest of the plural thingies?
-
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.)
I suppose we could have used it more, though
So, who's going to convert the rest of the plural thingies?
-
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.
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.
So, who's going to convert the rest of the plural thingies?
Note to self: merge aeva_utf2entities() into westr::cut().
-
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
-
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.)
-
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...
-
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...
-
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.
-
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.
-
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...)
-
We could store an id_previous_board for each topic.
-
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.
-
Arent we gonna remove the recycle bin at one point anyway?
-
Yes, when we figure out how we're going to handle deleted-but-not-really-deleted posts.
-
* 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.
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.)
-
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...
-
The only point is to have only two strings for the day list, as opposed to a dozen
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.
-
It's all handled logically if we use post statuses to delete them.
-
We obviously rename that 'delete'.
-
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)
-
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...?
-
I don't really see how it could hurt performance as long as we have a serious index on the status field...?
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.
-
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.
-
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.
-
Oh.
But this means there will be bugs in plenty other areas to come.
Are you sure that's necessary?
-
I love this thread - even if most of it sounds like 'Swahili' to me!
Great minds at work, thinking aloud. You two rock! :cool:
-
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.)
-
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.
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.
-
It's a possibility, but is there any reason for using LC_ALL really?
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 :/
-
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,
(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.)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.
-
Hmm... Only says "some versions of Windows". Never heard of that, really.
(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.)
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.
-
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.
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.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.
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?
-
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.
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.
Here's how I'm considering the approach:
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.
-
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).
-
@ Pete> I'm not sure it's semantically all right to use a theme menu string in a member menu... ^^;
-
Wow, we committed in the same minute! Did you get a conflict? :P
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 :/
-
OK, so this is really, really weird.
Whatever happens, it's forcing a 302 redirect back round to the installer >_<
-
All right all right, I'll just get back to work and reply these... :P
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.
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.
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.
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.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.
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).
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.
I'm the one who got stuck with all of the smf/sm renames, so nahh :PIn 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).
Class-DBPackages.php::32Nope, because I updated before committing and got your changes first, but mine happened to be nowhere near yours.
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 ;)Incidentally, at some point recently we broke the installer somehow, it never gets onto step 2 :/
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 :/
Did you try reverting? That's usually what I do... I revert until it doesn't crash anymore.
-
It had more bugs than that... I remember fixing a few things when I installed v5.3.
Indeed. It's a bit slower probably, though...
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
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...
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.Err... I may have forgotten. What were you trying to say?
Oh that would be such a fuuuun job to do....
Yes we do... I can already say the media tables aren't in it
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.)
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...
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.
-
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)
-
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.
-
Nah, I fixed it by loosening the check in the installer so it doesn't demand the brackets.
-
Me too. Next who commits then!
-
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.
-
Please document your commits.... :whistle:
-
Bah, I forgot to post the change log again :/
-
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()...
-
I looked at your commit... Is it normal that you reverted my change to the MySQL version test...?
-
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!
-
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.
-
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...? :^^;:)
-
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.
-
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?
-
I think that makes sense, so go for it :)
-
Good. Because I could always add a shortcut to that somewhere but i prefer a menu link to begin with. :)
-
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.
-
If it's about an Ajax-driven theme changer in the footer, I already have the idea but too lazy to implement it :P
-
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.
-
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?
-
I don't know what you're talking about...
Oh, that theme picker is a real bitch when it wants...
Where does the error come from? Maybe it's checking into $_GET instead? Can you have a look, Pete?
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 >_<
-
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.
-
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.
-
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.
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)
-
Why don't you try and clean up the mysql/php configuration files from your system and your registry...?
-
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...
-
And work from that... We'd just need to ensure they're in harmony with the corresponding default from each individual function.
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.
-
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. :^^;:
-
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.
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...
See also where it was discussed - http://wedge.org/pub/feats/6846/more-stuff-for-the-removal-of/
-
foreach (explode(',', strtolower($modSettings['disabledBBC'])) as $tag)
Wouldn't that do the explode for every disabled BB code??
-
I thought that foreach evaluated it only the first time to build the array. I smell a benchmark in the wings.
-
I did some research on this and it turns out that, indeed, PHP explodes it once and keeps it in memory.
-
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.
-
// 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?
-
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.
-
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
-
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
-
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:
-
PS: Pete... I know you're not as used to committing as I am (), but could you please think of posting your changelogs...?
-
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.
-
No worries :) It's a big week for me too with the new plugin manager code...
-
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.
-
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.
-
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-)
-
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...
-
- 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
-
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...?
-
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.
-
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.
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...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.
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?
-
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.
-
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 ;)
-
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)
-
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.
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.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.
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?(And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)
-
but is it needed? Didn't Wedge already load the hook list somewhere else..?
And if an add-on is bad, you can just delete or rename its folder and it'll deactivate it safely.
-
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.
-
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.
-
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.
-
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.
-
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.
-
It's a tricky one because there's pros and cons both ways.
In other news, would it be worth writing a post detailing exactly what the add-on manager does and all its overall mechanics? (Most of it, an add-on author shouldn't need to worry about anyway, but just in case, do you think it'd be useful?)
-
In other news, 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...
-
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.
-
Re: cat, I suppose nobody has an opinion on this... Not even us :( Argh.
Re: add-on manager, most likely at the end of the process?
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions. Which made me realize my process is really flawed in that respect... So I changed it and now, all blocks will be refused if their target layer doesn't exist. If a block is vital, then the modder should add a context fallback to it. I'm also adding code to prevent mods from removing said context layer...
Re: I did a lot of tweaking for the menu padding before, and, err... What can I say -- 6px is a bit much for me. 5px is fine however. It's a good compromise :lol:
-
Re: cat, I suppose nobody has an opinion on this... Not even us
Re: add-on manager, most likely at the end of the process?
Re: layers, yes indeed, I forgot to add hidden chromes to the list of exceptions.
Re: I did a lot of tweaking for the menu padding before, and, err... What can I say -- 6px is a bit much for me.
-
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... :(
-
So I turned them into inline-blocks and it works, but then I remembered that inline-blocks take whitespace into account, ah ah... Well, there are hacks to prevent that anyway.
Re: layers, well, do you think I should set $where to a different default depending on the target layer...? $target = context, $where = replace by default. $target != context, $where = add by default. It would allow us to remove the $where param from pretty much all loadBlock calls, but it's really not exactly 'obvious'.
Oh, and I think I have a couple of questions/concerns in the New Revs topic that you didn't comment on. If you don't mind.
@ Need to write a multi-language error for the context layer error... Would you care to write it, Pete? I lack inspiration to do something that can be understood by normal users and not overly dramatic at the same time
Assuming that it's only ever add-ons that will cause that... show this to users.
"Template Skeleton Error
Wedge maintains what's called a template skeleton, to set out the page structure. Unfortunately, it appears that an add-on you have installed has damaged this skeleton, and the page cannot continue. The administrator has been made aware."
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)
-
- Probably, but then it doesn't look as good. Went for inline-block with a negative left margin. It's a fair trade. It would be best to set the parent to font-size:0, line-height: normal but then I'd have to specify the font-size on the menu itself, instead of using the inherited value.
- Maybe I should start by renaming the main layer... Right now it's 'context' because its contents changes according to what page we're in, but technically the sidebar is the same.... What should I use? 'default'? Keep 'context'? Ah, if only I could name it just 'main' like it was... But that would mean I'd have to rename all blocks to 'index' or something. (template_index instead of template_main)
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer. (They may be able to do it through a replace in loadLayer... Would have to check though...) They can only do it with direct manipulation of $context['layers'] or $context['skeleton_array'].
Okay I have this error message, tried to keep it short and usable by both. Tell me if it needs changing:
Wedge won't show you the contents of this page, as its layout was detected to be corrupted, possibly by a skin, a theme or an add-on.<br><br>This has been reported to the administrator.
(And yes, it's logged, as you can see in the SVN ;) I need to put these into language strings though.)
-
- Maybe I should start by renaming the main layer... Right now it's 'context' because its contents changes according to what page we're in, but technically the sidebar is the same.... What should I use? 'default'? Keep 'context'?
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
- we can't "detect" through loadBlock, precisely because the skeleton functions won't let users delete the context layer.
Okay I have this error message, tried to keep it short and usable by both.
Posted: September 20th, 2011, 09:41 AM
Re languages: in theory if the language that a board (or user, for that matter) doesn't exist, it should still be falling back to the forum default.
-
- Removed compactTopicPagesEnable setting
-
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?
-
@John> ?
'default' works, as incidentally does 'context'. I'd avoid main though, for precisely the reason you give.
I'm still not sure about the default behavior for $where. I'd like to have more opinions... Especially from all of our mod developers out there!
Oh, yeah, oops. You know, there is a solution to that: turn it into an object, make the list a private variable of that object so only the object's methods can modify it. You'd have to move a bunch of stuff from Subs-Template into a class but it would effectively nail the problem.
It's fine for users but not a lot of help for an administrator. Much better, then, is if we can provide a separate error for administrators with a little more detail in it.
Re languages: in theory if the language that a board (or user, for that matter) doesn't exist, it should still be falling back to the forum default.
Re r1024: Um, $addon_dir shouldn't ever be empty because it should be set earlier in the file (lines 37-8)... what exactly was the error you were getting?
Although... Come to think of it, $addonsdir is defined in Settings.php, right? Then yeah, my mistake-- I haven't updated my Settings.php files to add them. I'm not in a hurry to do it... Would have to do it for my local install, as well as the demo and the import demo... :^^;:
Feel free to revert that one in your next commit, btw. Or whatever.
-
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Although I'm totally pro-objectifying (?) stuff, including mine, I wouldn't know where to start (i.e. I can maintain an object but convert something to an object is something I can't do with confidence), I'm also not sure whether it's actually worth the hassle... I mean, if a mod removes 'default', their author will notice soon enough...
I'd tend to say that admins are in the same crap as users here -- it's really the themer we should be talking to...
No, that's not what I was saying... If a board has a default language, different than the forum's, *and* the admin disabled the ability to change languages for users, i.e. $modSettings['userLanguages'] or whatever is false, then getLanguages() is not called... And my test code isn't, either.
I haven't written it down, but XDebug basically crashed saying "delimiter is empty", IIRC.
Also, in add-on related news, WedgeDesk is now capable of being installed (and running) cleanly from the add-on manager. The only thing it can't handle right now is attachments, and that's only because it's expecting to use the old attachment handling code which I haven't removed yet.
On that note, actually... I was thinking about how to handle attachment access for things like WedgeDesk that have their own authentication needs and that have different needs to the norm. Galleries, by definition, are accessed at gallery level, but we need to change that to being determined at board level for attachment gallery items. I'm not sure how we'd do *that*, but the solution for handling attachments generally when it's an external source seems fairly clear: have a hook that attempts to make the query that Dlattach.php normally would (or MGalleryItem.php, whatever query would normally be run to identify a file and validate the user can access it), and the hooked functions should return the necessary information, or false - that way, systems can deal with it as necessary.
-
- Removed compactTopicPagesEnable setting
-
The function will be moved to the index template as discusses earlier. ;)
-
That's cool then :D
-
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
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: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.
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()...?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)
It would make sense to actually display the faulty query etc to them...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.
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.
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.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.
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.
-
I'm cool with the template changes :)
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 having functions outside the object, and the object only manipulated through these functions like loadBlock()...?
Yeah, true dat!
It would make sense to actually display the faulty query etc to them...
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.
It's probably my greatest failure of these last few months. Have you noticed how I keep postponing them...?
I keep thinking of situations where the current attachment and avatar systems make more sense than Aeva's
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)*or* may require users to change the way they see things
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 :)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!
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.Yeah, and more than that... Topic level. See what I mean. (If we implement topic privacy. Another of my recent failures.)
I'm not sure I understand.
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.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.
-
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 :)
-
I thought so ;)
Glad to know!
-
loadAddonLanguage: If the file isn't found, an undefined variable error occurs ($found)
-
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.)
-
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.
-
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.
-
Welcome to the AeMe 2.10 nightmare :lol:
-
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
-
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 :)
-
The ENUM issue seems to be gone now. Thanks.
-
Awesome, thanks for testing :)
-
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.
-
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
-
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)
-
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 ;)
-
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.
-
There are 7 instances of plugin in ManageAddons.php :p
-
/mesays a rude word.
-
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.
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.
-
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 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
-
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
-
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)
-
We are talking about renaming to plugins not addons :P
-
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.
-
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.
-
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.
-
- Convert to is_dir, then?
- Okay!
- What does the 'be insert' mean, if it's not a typo....? :unsure:
-
Oh, heh, yeah, 'be insert' is a typo.
-
So, the original sentence is....?
-
"User might insert 5, or 5.3, or 5.3.0" or something to that effect.
-
+ $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)?
call_hook('get_boardindex', array(&$boardIndexOptions, $boardIndexOptions['include_categories'] ? &$categories : &$this_category));
-
Yes, I meant to test for that. No, you can't do what you suggest, I tried it originally and PHP complained bitterly.
-
- 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 :)
-
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.
-
Some interesting things in r1049.
Probably the first one which occurs to me is:Also note that $admin_areas is now a global, so the admin menu hook doesn't need to specify it as a param.
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.
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.Added three icons to the topic moderation menu. Only visible to members with the correct permissions.
Package functions don't need to declare admin.css, since it's already declared by that time. (PackageGet.php, Packages.php)
-
Also note that $admin_areas is now a global, so the admin menu hook doesn't need to specify it as a param.
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.
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 :(
-
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.
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)
-
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...
-
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.
-
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 :/
-
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:
<?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.
-
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...Anything in particular you'd like me to look over in r1049 since you flagged it as wanting feedback?
-
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. :(
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...
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.
-
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.
-
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...
(That is all, further correspondence on the subject can be conducted via PM)
-
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
-
Get bionic knees!!
-
Maybe you'll find it easier to bike instead of jog?
-
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!)
-
Yeah, it should go - subject to a good (better) replacement being added.
-
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...)
-
I'm away from keyboard for a few hours (on iPad) but I will when I get back upstairs.
-
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...?
// 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...
-
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.
-
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
-
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
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'.
-
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.
-
I cannot reproduce the actual error with restoration myself, however I don't have pretty URLs on.
It seems irrelevant, but the only thing I can tie into it is that when successfully proceeding with the restoration 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.
-
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.
-
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...?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.
Again, not really worth much of my attention, as I'd really like to get rid of the bin before we go alpha...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.
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
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.
No error.
-
Suggestion with contiguous pages:
$contiguous_pages = isset($modSettings['contiguous_pages']) ? $mod[..] : 5;
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.
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...
Been procrastinating a bit regarding Wedge lately...
-
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.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.
Then let's figure out how it should work instead of trying to fix issues that will be obsoleted out.
You are allowed to have a break, you know :)
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.
-
We should probably get started on removing the bin right now...
Are we talking about the same thing...? The empty skeleton error?
-
We should probably get started on removing the bin right now...
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
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.
-
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.
-
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...)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.
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'.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.
Posted: October 7th, 2011, 04:28 PM
@ 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.
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...
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?
-
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...
-
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.
-
Will have a look.
Installer -- I rarely run it. I suppose it's linked to the caching error.
-
just a small bug report:
Security.php line 419 starts with:fatal_lang_error('your_ban'], 'user'...
fatal_lang_error('your_ban', 'user'...
Admin Area - side bar:
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...
-
just a small bug report:
Security.php line 419 starts with:
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 :(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...
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?
-
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...?
-
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 :(
-
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 ;)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.
Posted: October 9th, 2011, 12:58 PM
(Bump!)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 ;)
-
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.
-
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.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.
I also merged two strings for the same reason ('not_removed' error string.) Next commit.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.
Still, what do you think of merging them?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.
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.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.
-
As long as it's decoded back into $txt[$error] on the other side of the log viewing code...
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.I don't know either but I'm no specialist.
But I just couldn't find...
-
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.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 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.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.
Kill it. If it isn't being used, get rid of it, pure and simple.
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)
-
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...)
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.I totally forgot that this was recent, indeed...
I don't even know why people would need to translate this, meh.
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.
We could also kill $txt['by']
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
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)
-
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.
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.
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.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'll be working on that...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,
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.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)
Additionally, I haven't tested Wedge in RTL mode for a VERY long time... :-/
-
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.
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.I'd tend to say that it's up to the server to translate that to the current locale
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 team member kicked up a fuss.
Lastly, I wouldn't worry about RTL too much at this time.
-
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.
-
@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...
$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.
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...)
-
@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.
-
@Nao, that's why I suggested doing it with a <we> variable ;) it won't ever be used in posts directly.
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...)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.
-
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...)
-
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.
-
Btw context isn't globaled in the Who code. Error log. Fixed locally.
-
Notice: Undefined index: scripturl in J:\Backups\Linux Drive\www\wedge\trunk\Sources\Subs-BBC.php(133) : regexp code on line 1
-
That's because you didn't update your wedge_bbcode table ;)
-
Just another small bug report (ipv6 related):
install.sql
poster_ip int(10) NOT NULL default '0',
poster_ip varchar(32) NOT NULL default '',
-
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.
-
ok, thanks.. I believe I should have studied the code a little bit more.. :whistle:
/meneeds to fix the importer files..
-
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.
-
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..
-
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...
-
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.
-
Lol... Yes, you do care about this bug ;)
-
I had a busy weekend. I'll look into it today.
-
I already fixed it locally going by the code in the bug report.
-
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.)
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'])
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.
-
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.
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'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.)
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.- $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']...
I personally always type it in lowercase, and actually earlier versions of SMF used am and pm in lowercase, too, in timeformat()...)
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'])
-
Odd, I searched for 'authenticate' and 'auth_method' but I guess I somehow missed those :/
I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?
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...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!
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.
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.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.
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.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)?
Removed in 1116.Crap, I thought I'd nailed all instances, guess I didn't search so thoroughly :/
'am' and 'pm' is probably nicer looking and more consistent with what everyone else seems to use.
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'])
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.
-
Do you want to remove them, or me?
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.
Still, I'd like to know where I'm going to put the post-query hook
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.
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.
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.Awesome.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
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
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.
-
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.
Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.
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.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.
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.
Other opinions on this...?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,
- 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.and making minimal a shade bigger to allow for things like member-group colour (and then making it used consistently!) would help
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.)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.
Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...
-
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.
I have some plans for a universal bridge (webserver authentication, LDAP, external databases), thus I'd need a proper solution for these things...
-
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...
-
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.
-
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.
-
Pete, there's a long post above for you :P
(Okay, okay, I've got one waiting for me, too...)
-
OK, so for the rest of the stuff...
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.
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
An extra query are you sure? I have a feeling everything can be done with a LEFT JOIN on the membergroups table...
Ideally everything should have gone through lMD/lMC for consistency but it's not done that way for performance.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...
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 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)- 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.
* 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.)
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.
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.* Used in Search2 to get authors for found posts. Used in Who.php for the Who's Online list. Another candidate for 'minimal'...
I think there will be some, yeah... It's bound to happen. But I'd rather have too many strings than not enough
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...)
-
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?
-
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.
-
I suspect that no one in their right mind would use Facebook to register/log into a forum they're administrating...
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).Ah, LDAP... I've never understood what this is about ;)
-
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)?
-
Heh, that's really why I wanted your input since it would require converting queries and 'big' queries would need this treatment later.
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.
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... (?)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.
But we could look through the entire anchor tag and reject it if it has bbc_ in it or something...Also, I'm wondering whether it wouldn't be cleaner 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)
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.
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.
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.
Yup, though it's nice having the member's name in the right colour there as it should currently be.
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...
-
That looks familiar... :whistle:
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))...?
-
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)?
-
Well, if you and Dragooon are into it, then you should do it... I don't have the perfect answer to everything
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... (?)
Why? I can't think of an example where adding a class to an anchor would be detrimental to XML functionality...?
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...
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...
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
Definitely a 'custom' candidate then...
It only uses lMD when you're setting PM options in your profile...
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.
I think that's the only place you get it apart from the info center... A real bummer.
It's technically valid only in Linux. It doesn't work in Windows and Mac OS.
You know, you COULD revert this and no one would blame you for that...
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))...?
Also, why would you want to pass in parameters not related to the query itself, exactly?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?
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 suspect that means something you offered before, sorry I can't remember..
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))...?
Also, why would you want to pass in parameters not related to the query itself, exactly?
-
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
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.
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...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.
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.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...
Works for me. Just something I wanted to be careful of, really.
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...It works like any other nesting, and for the most part it's pretty transparent.
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.Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
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?
Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.
I think that's the only place you get it apart from the info center... A real bummer.
You know, you COULD revert this and no one would blame you for that...
(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.)Also, why would you want to pass in parameters not related to the query itself, exactly?
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.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.
-
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
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 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.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.
Sure.......................... Who's up for it?
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)(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!)
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.)
<evil grin> "I don't know, but it's going to be a lot of fun finding out!"
-
I figured we might as well cache the membergroups and their colours generally (including post count groups),
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 " in the language files. Shouldn't we remove them...? I don't think they serve a point these days?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.
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.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.
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 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
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.
And please generally tell me what you think about the overall building of the feature ;)Actually, Dragooon answered that one, and wesqlQuery provides for it.
-
Oh, I forgot about post count groups... I never enable colors for these.
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 " in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
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:
$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.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.
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 just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
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.
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 ;)
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
-
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.We might not but I know sites that do.
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.
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
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.
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...)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.
-
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.)
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.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.
Which is why I added a default color for the highest post group in Wedge...
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
It only matters if you're not going to update the file in the future.
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...
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...)
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
-
ManagePlugins is missing a comma at the end of line 1408 casuing a fatal error.
-
I'll look into it. I shall be committing today anyway.
Oh and I need to answer the post above...
-
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)
-
! Provide a hook for altering the list of posts to be retrieved, as suggested by live627. (ManagePlugins.php, Display.php)
-
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.
-
Go up and go down links are backwards.
-
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.
-
Looks like the two JS functions in topic.js need swapped to fix it.
-
Hmm, my fault apparently! rev 1070. Sorry :^^;: will fix.
-
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:
<?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.
-
* 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)
-
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
...it almost doesn't seem worth invoking the entire buffer operation for that.
(I feel like the librarian in Discworld :lol:)
-
I'm not sure a hook would help though :/
-
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.
-
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... :^^;:
-
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...
-
Only because so much of SMF used selectboxes in interesting and inconsistent ways. It'll be worth fixing them.
-
Actually that feature was broken even before the new select box code. Hmm. Maybe it's broken in SMF as well?
-
Very possibly, I'm not entirely sure how well it works, most don't even know it's there...
-
I used to use it a couple years ago. The feature would benefit from having default labels like {to_answer} etc. No?
-
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.
-
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.
-
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)
-
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?
-
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.
-
I found the issue. $boarddir uses backslashes but dirname($file) has forward slashes.
I don't understand your bumped question. Line numbers and files please?
-
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...?
-
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.)
-
As for $here, does that still mean there's a bug for me to fix...?
Posted: December 28th, 2011, 11:36 PM
I'm counting on you to check this out
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.
-
so...
As for $here, does that still mean there's a bug for me to fix...?
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:
$final .= str_replace('$here', '..' . str_replace($boarddir, '', dirname($file)), file_get_contents($file));
Into something like...
$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...?)Flawless! Actually, I tested only the post area.
My plugin can now use a dynamic string in place of %1$s. :D
-
That would work and fix the issue, but I'd like to fix the *real* problem, which is as I described above.
-
I'm not sure. Pete? Peeete...?
-
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... :^^;:
-
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...
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.
-
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!
-
updated visible copyright dates. Not brave enough to update every file in distribution so left it purely at the publicly visible dates
-
Not brave enough right now. Today's been an... interesting day.
-
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 ;)
-
Yeah, it needs to be done, but there's no hurry...
-
Priority should be on fixing skin_folders for now.
-
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...?
-
$_SERVER['HTTP_HOST'] isn't even set at all...
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)
-
Among other things it's used to re create the current URL... pretty urls etc.
-
What page(s) is that being requested on?
-
As mentioned above...?
-
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...
-
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.
-
- 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)
-
No domian yet but...http://109.236.83.66/
-
It's a fake site, AFAIK... IP was already circulating this morning, with the same stupid content.
-
* 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.)
(Yes, Core Features is NOW GONE FROM SVN :D And note that this is still a WIP so things can and will change.)
-
+ 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)
-
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.
-
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"...?
-
Or, just change the text string to say "starts with regex"...?
-
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...
-
I'll fix it locally, I have other stuff to add yet ;)
-
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
-
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.
-
@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.
-
Feel free to modify the JS any way you see fit - as long as it works afterwards ;)
-
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)
-
- 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"
Used bindEvents at one point, instead of reproducing the function. I just modified bindEvents to allow passing specific DOM elements to it.
-
- A class="hr" doesn't need to declare disabled, it's done by sbox automatically,
- I added a couple of data-hide's
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.
BTW, that UI is really cool :) It's like a conversation between the admin and the website...! Or a wizard, if you like!- Some .show()/.hide() combinations were turned into .toggle()
.toggle(false) = .hide()
.toggle(hello) = {
if (hello)
.show()
else
.hide()
}I always forget whether JS supports this syntax or not :/
I was gonna ask you about that, actually.
-
you don't need to set a blank value either, although it's also the case on anything that's set to disabled
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
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!
.toggle(true) = .show()
.toggle(false) = .hide()
.toggle(hello) = {
if (hello)
.show()
else
.hide()
}
I'd love to be able to do ($something = $param || 0) in PHP
Well, it's just an example. Of course PHP has default values for function parameters, but it'd be nice to have it everywhere.
-
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.
Posted: February 15th, 2012, 10:37 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 :)
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.
I'd love to be able to do ($something = $param || 0) in PHP
$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.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.
-
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.
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.
-
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.
-
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)
-
! Tahoma is not always installed on Linux. (index.css, Wine/index.css)
-
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... :))
-
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...)
-
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.
-
I only noticed that one check against 'moderate', which is a permission that doesn't exist, I didn't see any other checks.
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...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.
-
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*
-
But it's not something you fixed is it?
-
No, all I did was make moderate_forum be the equivalent of the 'any' permission if there were actually such permissions.
-
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 ;)
-
It's OK, I'm too zombified from walking around miles and miles of Brighton trying to take pictures to think too clearly anyway >_>
-
Are you closer to Brighton now than when you used to be in HH?
-
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.
-
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 :)
-
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.
-
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.
-
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 ;)
-
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:
// 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...?
-
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.
-
Are you talking about that bit?
// !!! 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.
-
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.
-
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...
-
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.
-
Doing it off groups is an inference, it's also not possible to infer 'friends' from that either, assuming you wanted to do that,
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.
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)
-
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.)
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.
-
How so...? board_access doesn't support that?
How faster would it be, since you need to join the board_access table anyway..?
-
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,
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...How faster would it be, since you need to join the board_access table anyway..?
-
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)
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.
-
Why the fuck is that string there? I certainly didn't put it there.
It was already in SMF2, if you want to have a look!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.
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?
-
Yes, it will. First thing it does is strtolower the string.
-
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?
-
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.
-
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.
-
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.
-
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.
-
I'm glad to see you guys tackling these internationalisation-related issues, really. :)
-
(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.
-
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...
-
Oh, sorry, yeah, this is a mostly new install of Notepad++ which I forgot to reconfigure for LF only.
Thing is, it's totally related to managing topics, rather than topics in general, hence the name.
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!
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...?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.
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...
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 ;)
-
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...
-
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...
-
Haven't had time to look into things at all, sorry. It's on my to do list ...
-
Eh, you don't have any obligations to Wedge... ;)
-
It's nice to see loadLanguage using arrays :)
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...
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.
-
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. :)
-
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. :/
-
It's nice to see loadLanguage using arrays :)
Is there anything left with a '+' syntax in Wedge...? I don't think so, but...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.
Posted: April 26th, 2012, 05:03 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. :)
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... >_<
-
I didn't think there were any left anyway, I thought the only use was index+Modifications, which I killed a bit back anyway.
I have no idea what you mean, sorry.
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...
_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.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...
-
I didn't think there were any left anyway, I thought the only use was index+Modifications, which I killed a bit back anyway.
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.")
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 + 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.
-
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.
-
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.
-
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 :))
-
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 ;)
-
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
-
Wow guys, you don't leave a detail flying around. :cool:
-
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.
(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...)In that case, check the board's configuration and check you set the default ordering correctly ;)
-
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?
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.
-
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.
(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...)In that case, check the board's configuration and check you set the default ordering correctly ;)
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.
-
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?
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.
-
You gotta be more specific.
-
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.
-
What does it look like when signed in?
-
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.
-
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
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)
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.)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.
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.
-
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.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.
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?
-
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.
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...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.
-
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...
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).
Or perhaps we could add prefixes to the Ajax files? Ajax-QuoteFast, Ajax-JsModify...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.
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!
-
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...
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...
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.)
-
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'.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 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...
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.
-
Now for a good suggestion too... Should likes be disabled if a topic is locked? My gut feeling is 'no'.
I don't use it much, really.
And I suppose you're expecting me to find the names......
Easy to say, cowboy! You read faster than your shadow...
-
Cowboy?? Am I missing something?
-
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.
-
Re: thoughts, indeed $last_thought was an error on my part.
$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...)
-
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.
-
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...
-
@ 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
-
@ 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
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..
-
Every little helps though :)
-
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.)
-
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.
-
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.
-
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...
-
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:
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...
-
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?
-
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...
-
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.
-
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)
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...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.
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.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.
-
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...
One of my goals (which I'm unlikely to achieve though) is to ensure that as many UI elements as possible are harmonized.
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 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...?
-
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.
-
That works, I guess...
-
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
-
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.
-
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 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...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.
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"
-
Btw do you have an idea whether or not I should make dimming the default?
-
Btw do you have an idea whether or not I should make dimming the default?
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?
-
reqWin here opens a new window. (It was DHTML yesterday, though...)
-
With what browser?
-
Firefox 13
-
It's working fine here for me....... :-/
-
* Changed default windowbg colors for Weaving. I like change from time to time... (index.css)
-
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.)
-
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.
-
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)
-
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...)
-
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 "
-
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.
-
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:
-
It's been grand getting back into the swing of things :)
-
It feels overwhelming, which is way better than feeling bored :P
-
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.
-
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.
-
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.
-
Yeah, I knew about that, but I wasn't sure if I could actually pay myself even in the sandbox.
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.
// 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.)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.
What's in your HTML head?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:47 PM
What about this one btw..?
// 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.)
-
I've never had such any problem...?!
What's in your HTML head?
What about this one btw..?
-
I tested my code through a file() call, and it seems to work just fine... (Phew.)
-
Well, I'll do a fresh install and see what happens (which will check both issues at once)
-
So what's the resulting output?
-
I haven't done it yet, had other things to do like eat...
-
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 >_<
-
OK, so I've hacked together something that works for the time being.
So, the contents of my <head> is thus:
<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'
-
Seems that sbox.js is minified into things when jquery_origin is local but not when it isn't - at least for me.
-
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...?
-
I don't have any problems with sbox.js myself. Are you sure you can reproduce this...?
-
Even with your fix..?
-
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.
-
But I thought the problem was introduced with my updateSettings call in the language cache code..?
-
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.
-
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 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.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.
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... :)
-
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.
I don't remember asking you about head, though... Or maybe that was a long time ago?!
-
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...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.
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...)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.
It was last week - http://wedge.org/pub/feats/6803/new-revs-public-comments/msg282124/#msg282124
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.
-
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...)
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)And the HTML had what...?
-
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)
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...?
-
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...!
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...
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.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 wasn't meant to be a final solution. I only really cared enough about it actually letting me install.
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...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.
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.
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.
Does it work on yours? Did you have the error last time you tried?
-
[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?
-
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?
I don't really want to put it in the template because that would mean themes could prevent that being applied.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?
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...
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'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... :-/
-
- I'm okay with adding a $context var next to $txt['copyright'] or whatever.
Doing it this way means it cannot be tampered with - putting it in $context means it can be tampered with.- I'm just not confident enough with plugin writing to even be able to do something as simple as hooking into that variable...
Eh, just commit it and let the deities of computing sort it out :lol:
-
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.
-
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)
-
@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..? :^^;:)
-
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.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..? :^^;:)
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 ;)
-
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.
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...)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,
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 ;)
-
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...
-
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.
-
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 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..?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.
Posted: October 8th, 2012, 05:54 PM
Just did a quick test...
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...
-
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?
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.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...)
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.
-
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!
-
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.
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.
-
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)
-
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...?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.
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...? :^^;: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)
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...
-
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.
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.)
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...
Refer back to http://wedge.org/pub/bugs/7158/smf-bug-4870-incorrectly-capitalised-month-names/
-
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.
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...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.
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...?
-
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:
-
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.
-
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.
- 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...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:
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.As far as 2 goes, that sounds very nice and flexible.
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.)
-
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...)
-
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.)
-
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 )
-
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..?
-
IE 8 and 9 are all that matter forget 7 :p
-
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!
-
To get more accurate:
last month 7283 unique visitors with IE7 and 1061 unique with IE6....
-
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', 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.
-
Isn't Wedge for real men and women? Well, they don't use IE 6/7. :whistle:
-
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..
-
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...
-
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.
-
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
-
! 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)
-
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... :-/
-
Bumping this for nao though it might be to late for that haha
-
Thanks for diggin' it out, though! ;)
And it's never too late...
-
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.
-
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?
-
- 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.
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.- 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...
- 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..?
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.
- 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."
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?
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.
-
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.
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.
- Still against renaming .wmenu() to .dome(), right? :^^;: Well, it doesn't cost anything to ask...
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.
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.
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.
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.That's just names. Makes no difference to me what it's called. It's logical, it works.
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.
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"...?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.
-
$("#menu").dome();
Oh..hell no.
-
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..?
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.So, how about removing the ?> altogether..?
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's not about what looks natural here, it's mostly about following the SMF guidelines.
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"...?
$("#menu").dome();
Oh..hell no.
-
&("#menu").dome();
-
menu do me?
-
men u do me?
Sounds like something a lady of the night might wonder.
-
ewww
-
If it hadn't been me that said it, it would have been someone else.
-
Yeah, what he said!
-
Haha
-
men u do me?
Sounds like something a lady of the night might wonder.
-
- Used bindEvents at one point, instead of reproducing the function. I just modified bindEvents to allow passing specific DOM elements to it.
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, 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...
-
I'm not really fussed where it is, provided that it works and doesn't break anything.
-
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...)
-
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.
-
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:
-
Scary for you - as long as I can add events inline and add deferred JS with add_js(), I'm happy.
-
That's the idea. :eheh:
-
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 ;)
-
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:)
-
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 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
(empty($_POST['pin']) == empty($topic_info['is_pinned'])
I've always loved this kind of smart, elegant little trick ;)
-
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.
-
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.
-
Well, right now we pass in message, whether to parse smileys, 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.
-
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...
-
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.
-
Okay, then... At least may I remove anything related to the one DB table you left, log_packages?
-
No because there is still code referencing it, and not just in the upgrader.
It will all be going soon enough!
-
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.
-
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.
-
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...
-
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...
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...
-
I'm getting there!
-
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.
-
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.
-
Don't you mean "byte me" in reference to Android icon? :lol: I shouldn't try to be funny after only just having breakfast.
Oh, and when zipped (dunno about gzipped), it's "only" 3 extra bytes.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 can understand you'd be tired at some point!
-
It is a pretty big change, and I was trying to prune language strings as I went...
-
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!
-
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!
-
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.
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 ;)- 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!
-
Don't worry, it took me a few goes to make sense of it.
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.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 ;)
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.
I'm not sure I follow how we get from messageindex to attachment :/ But I've only just got up.
But MI still has a preventPrefetch() call. And Display doesn't, to answer your question.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.
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.......)
-
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.
Oh, I'm sure you'll at least remember this conversation....
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.
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.......)
-
Essentially this is about cases where users attempt to log in, fail, and we don't let them log in too many times.
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 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...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.
Or do you want me to copy-paste it directly from my noisen code? No problem really... I just tend to forget it ;)Display.php, lines 86-92...?
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.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.
At worst, we should actually do that test right at the beginning, e.g. in index.php, instead of while in the action array.
-
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
-
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:)! Did I mention that I love the @language embedding into script files?
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.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).
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)
@ 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.
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.
-
@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:)
http://blog.cloudflare.com/cdnjs-the-fastest-javascript-repo-on-the-web
It supports IPv6, SSL, SPDY and it's available to all. :)
-
@Lorenzo> I'm surprised a CDN not advertised on jquery.com would offer it..? Anyway, isn't this only for cloudflare customers?
Who's going to change it anyway..? A plugin? Bad semantics, bad karma!
e.g. the draft auto-save, things like that.
Haven't looked at all the functions that could benefit from being moved there.
Yep yep yep, my you're scaring me! :lol:
- 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,
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.
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.
Posted: February 3rd, 2013, 10:44 PM
* 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)
-
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..?
-
In the meantime -- just looking at a commit... Did we discuss the changing of message bodies to mediumtext?
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.
-
Oh... So, the removal of fulltext is what was pre-required to switch bodies to mediumtext...?
So, one bird with two stones? :)
-
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.
-
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.
Regarding base64, the filler ='s mystified me for quite a while, when I discovered web programming. Not so much, now, but still ;)But it's an optimisation that isn't really necessary to perform.
r1997 - I thought I'd said not to touch Class-SFTP because I was going to replace it with an updated version shortly?
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..."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.
Oh, you mean taking the guy's next version..?
Well, if it's like get-id3 or exifixer... I stopped insisting after a while ;)
-
I just never noticed anything breaking.. Otherwise I'd have looked into it, like I did yesterday. Were you aware of this..?
like rewriting the PM template to use Msg
"multitude"..? There's only one file...?
Oh, you mean taking the guy's next version..?
-
I wasn't aware that pretty URLs did that, but on my local site I never, ever use PURLs anyway.
And generally, I tend to leave things alone, for fear of breaking something I didn't consider.like rewriting the PM template to use Msg
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.
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...
-
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..?
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.)
If you're committing something tonight
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...?
-
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.
-
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.
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.
-
I'm all for having a UK language file in there, of course! British are cool. (Matt Smith voice.)
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.
-
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 :PYeah, 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,
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 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...?
-
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.I'm surprised I didn't catch that...
-
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.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.
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)
- 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,
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.
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!)* 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)
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..?
-
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...
- 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.
Well, there are many settings we never hesitated to remove to make room for others or just breathing space... ^^
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.
- 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 is also one of the issues around attachments/media items, to ensure permissions remain tied to the helpdesk and not anything else.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..?
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.
-
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 ;)
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.
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. :)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.
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...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.
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.:thanks: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'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
-
did you check whether $context was being used elsewhere in the functions..?
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.
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.
I was wondering whether we shouldn't be inverting the process on desktop..?
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.)
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 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..?
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
* Because the registration agreement is a special language string that's explicitly parse_bbc'd
This also makes them easier to use them as base for your own registration agreement.
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...
-
<?php
- if (empty($group['name']) || empty($group['type']) || empty($group['classic']) || empty($group['simple']))
+ if (empty($group['name']) || empty($group['type']) || empty($group['name']))
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.No, I didn't. But any place with a linktree is also going to be setting the title, which is a context variable.
I'm not overly looking forward to the changes in the language editor, or for that matter, themes with their own language files.
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.
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.I was wondering whether we shouldn't be inverting the process on desktop..?
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...Actually, it's probably from SMF originally.
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.)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.
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.
- 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...?* Because the registration agreement is a special language string that's explicitly parse_bbc'd
All I know is that SMF has this:
$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.This also makes them easier to use them as base for your own registration agreement.
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...)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...
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..?
-
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
: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.True enough. Although not always done... (e.g. notification action.)
(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...)
So, I take it it's untested, right..?
I don't know, Pete.
All I know is that SMF has this:
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
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.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...)
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 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.First thing for that is to allow for the homepage (most often modified page) to be overridden and redirected to another page of yours.
-
: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.
Hmm, a bug with the auto splitter... Sometimes it inserts two blank lines after opening the quote again. Uh.Fairly sure I gave the notification action a title some days ago.
Can a skin replace part of index.template.php?
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...And I see no reason off hand why this should even work. preparsecode has always converted line breaks out - always.
$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.)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.
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...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.
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.
The idea of having a template like this is a noble one, but it's also sadly naive of our userbase - it's giving them infinitely more credit than most of them would actually be due.
This is why I've been talking about content management and adding a CMS into the mix for the simple reason that most admins can only manage something if given a nice UI to play with, it's why so many of them jump to Simple Portal and co, so that they can have nice front pages and so on.
So instead of giving them the barest bones tools for the job, we need to give them more powerful tools.
-
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...
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...
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.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...)
Yeah but that's no reason to throw a hadōken at me in your previous post, buddy...
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 ;)
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.
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...
-
I can't see avatars after the site got updated. :)
-
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.
-
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! :^^;:
-
I know that feeling, heh :)
I'm currently attacking the polls template, separating the elements so I can make a fun plugin ;)
-
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 ;)
-
/mehas happy thoughts in Nao's direction ;)
-
All fixed. :)
-
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.
-
So it's now supposed to show all the notifications whether read or unread?
-
@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?
-
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?
-
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
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.
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.)
-
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.
-
Apologies, I was mistaken: rename() is a layer-only function...
There is no equivalent for blocks.
Should I add support for them...?
-
Apologies, I was mistaken: rename() is a layer-only function...
There is no equivalent for blocks.
Should I add support for them...?
-
Yup, this is the issue; the pie polls plugin, for example, needs to replace a single block, not an entire layer.
-
Done. :)
It was almost too easy... The hardest part was actually finding block names to test the thing :P
-
- 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)
See Post2.php for $context['new_replies']. lines 277-295 being the most prominent use.
-
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.
-
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:
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.
-
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!
-
So you're saying I couldn't catch it before the only actual use doesn't specify the error_ prefix, right..?
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! 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)
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.
-
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)
-
What software did you use to crop it..?
-
GIMP. I just opened it, cropped it, saved it, committed it.
-
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.
$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...
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..?!
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.
-
I'm using GIMP 2.6.12 if that's any help.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.
-
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
-
! The old Profile Notifications page is still there, but it wasn't showing up to do duplicate array entries. (Profile.php)
-
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...
-
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?
-
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?
$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! :)
-
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 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?
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.Done with the checks. Overall, great work!
-
...! 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
-
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..?
-
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.
-
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.
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.
-
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..
It gives you the general permissions and the 'all boards' permissions but lets you select different boards from a dropdown.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...
If deny permissions weren't an option, I'd do what I did in SimpleDesk which was dropdowns with nice icons.- 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...
-
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...
-
/meis still s bit spaced out, will review in a bit
-
I only changed some colors, added title params everywhere (really!), and decided that the gzipped difference is too trivial to care about.
-
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..?
-
How about, we change the permission page, at load time, to replace the radio buttons with a pseudo-select box?
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.
-
* 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.
-
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.
-
* 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)
-
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. ;)
-
Thanks for the explanation! I stick with my original conclusion then! I personally like the Home template better instead of Welcome. :)
-
I agree I like home better too. Makes more sense to me.
-
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.
-
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.
-
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.
-
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... :-/
Don't see it as a problem. Do you?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...
-
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.
-
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).
-
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.
-
Update from wedge's original is through BB direct.
Update and Commits through Tortoise.
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!)Perhaps is an idea to have an empty branch. Seems to work. But we'll see after my next commit.
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.I'm OK with changing this to German. But Austrian users speaking native german? :)
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.
-
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 :)
-
Keep me posted!
-
[master a226178] APC isn't maintained anymore! Should be better to work on Zend Opcache.
-
APC is the one installed at alwaysdata so I get to test it firsthand...
-
Also, regarding the latest commits: 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.
-
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.)
-
[master a226178] APC isn't maintained anymore! Should be better to work on Zend Opcache.
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:
-
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
-
Yeah it's only an opcache. But APC isn't maintained anyway :P
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:
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.If you want to test it I can give you access to my VPS with PHP 5.5.6 installed
-
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. :-/
-
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.) 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.
-
Is there a way to receive notifications of new revs?
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... :PPersonally I like reading them; even though I understand very little it does give an indication of areas that are being changed / added.
So one assumes that one can download those two files only and have the latest version of Wedge?
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.
-
"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.)
-
Regarding commit eda89f6: there's a function in Google Analytics I think where you can let googlebot login (you provide credentials).
-
Removing the 'Posterity' link on your thoughts if they're not public.
-
"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.)
-
"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.)
-
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.
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.)
-
Coool!
-
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.
-
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.
-
Are SVG bigger than GIF for flags?
-
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.)