Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
6121
Features / Re: New revs
« on October 5th, 2011, 12:27 AM »
Revision: 1057
Author: arantor
Date: 23:26:53, 04 October 2011
Message:
! Legacy variable being used in cache-cleaner. (Subs-Cache.php)
! Make sure the right area is used when a cross-selector is defined in a menu. (Subs-Menu.php)
----
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Menu.php
6122
Features / Re: New revs - Public comments
« on October 5th, 2011, 12:26 AM »
OK, so I see the suggest JS is fixed. I've also fixed a side issue that I noticed from editing boards, in the clean_cache function.

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

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

Meh, just rejigged the code in Subs-Menu to not only update the current_area but also to force it to be detected as such later.
6123
Features / Re: New revs - Public comments
« on October 4th, 2011, 11:47 PM »
I cannot reproduce the actual error with restoration myself, however I don't have pretty URLs on.[1]

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

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

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

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


I can certainly fix up suggest in the meantime since that would imply it's broken elsewhere too.
 1. Frankly, every time I do enable it, something usually breaks, so I never touch it, but maybe I am doing something wrong!
 2. In other news, it seems strange that RestoreTopic is in RemoveTopic.php, but then again we did the same in SimpleDesk...
6124
Features / Re: New revs - Public comments
« on October 4th, 2011, 11:27 PM »
Quote
I don't think the logic is broken... It just needs special treatment at the top level, just like you gave to AdminSearch. Although at this point I think it'd make more sense to do generic handling of all 'select'-type entries.
Why does it need special treatment? Doesn't it call a function and issue a normal template?
Quote
Also, I *think* there's supposed to be a confirmation request for deleting boards.... I only get one for deleting categories. Can you...confirm? Anyone?
Fairly sure there's supposed to be... there's a JS error in suggest.js (which is called for the board moderator selector) which causes the rest of the page JS to get upset, which prevents the confirm() being called.
Quote
Re: restore posts, I couldn't find the origin of the skeleton error. Argh. If you could look into it as well... I have no time to actually go and try to restore posts for now
I'll look into it right now I'm back on the PC.
Quote
Loosely related: when deleting a post, Wedge should update its 'children' posts to use the deleted post's parent ID. Should be easy enough, but we then have to update their own children, too... I'm not sure how to do this with minimal impact on the DB performance.
It's tricky - and that's before you get into the realms of split/merging. However, if you have any given tree of x->y->z, and it's y you're deleting, you only have to update all the cases for z where the parent is y. It's a single-direction graph, we're only recording the parent, not the children, nor the latter descendants, so if post y is deleted, UPDATE wedge_messages SET id_parent = x WHERE id_parent = y, and that'll match all the z cases because we're only recording the immediate parent...
Quote
And-- I guess 'parent' shouldn't be touched when removing through the recycle bin... Or maybe yes. What's certain is that it shouldn't be deleted when a post is 'unapproved'.
This is *really* where it gets fun. What might be better is if the actual hierarchy remains untouched in a physical sense but a simple "This post has been removed" placeholder is shown to the user. That would not only solve the whole issue of how to handle it (because you don't move it, you leave it totally in place) and prevent logical disjoint where the post is removed and the flow of conversation seems broken: it's still going to be broken if part of the conversation is missing, but at least you have context for it.
6125
Features / Re: New revs - Public comments
« on October 4th, 2011, 10:33 PM »
Not security related, but logic related; the point is that the front page should exist and be a valid fallback for requested pages (i.e. ones that don't exist/aren't accessible), while the index shouldn't exist as far as the menu is concerned.

Seems to suggest the repair boards logic is broken in some other interesting way. I'll take a look later on.
6126
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:50 PM »
Nope. It's all pure PHP. Lots of big numbers expressed in 0x0000 format, but that's about it. Though, I suspect I'd rather not mess about to keep reminifying if possible.
6127
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:39 PM »
Though removing the calendar to a plugin would help ;)
6128
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:24 PM »
When packed as a .zip (less efficient than .tar.gz), this weighs in at 169KB.
6129
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 09:19 PM »
I can't speak for getID3, but a script that's 600KB (including comments) that will all be loaded at once, because that 600KB is all interdependent. That, and the fact that I'm not too thrilled about the size increase that will necessarily result from it (but that, at the same time, I can't really make it a plugin either)
6130
Features / Re: The calendar
« on October 4th, 2011, 09:14 PM »
I deliberately tried to accommodate not only current but future ones, and also to accommodate the crazy sort of things I always wished I could do in SMF.

Plugins that have dependencies was something I always wanted to support after I did it in SimpleDesk, and it makes sense to provide the general facility of plugins being able to indicate their needs and own skills - because it's the only way that I could come up with of automating the dependency management.
6131
Features / Re: New revs - Public comments
« on October 4th, 2011, 07:39 PM »
I'm away from keyboard for a few hours (on iPad) but I will when I get back upstairs.
6132
Features / Re: The calendar
« on October 4th, 2011, 07:24 PM »
The plugin architecture is designed to support plugin dependencies, though its implementation is rather incomplete. It isn't done by id, however, it's done by hook presence; if a plugin demands one or more hooks, they don't have to be all core hooks - and it's designed so that another plugin can indicate the hooks it provides.

Being core doesn't guarantee it will be well supported, it just guarantees that you'll get it with the core.

There is a distinct part of me that feels putting it into a plugin means support gets better - because the code is localised, we can narrow down changes better.

Plus the whole point of the plugin system is that, frankly, it's supposed to resist changes in Wedge-core and be more resilient as time goes on.

Lastly, the name being <wedge:calendar>, I'm good either way, though I tend to reflect its proper case. A plugin's id is really just an internal identifier, it isn't used for anything other than internal coherence and loading.[1][2]
Posted: October 4th, 2011, 06:55 PM

There is a secondary benefit for doing this: we get the ability to offer a bundle, where users who want the calendar can download it as part of the package if they so choose, with it fairly easy to enable (just a click)
 1. If a plugin wants to load its own template, source, language files etc., it has to supply its id.
 2. I suspect in time I'll extend that to also deal with duplicate detection but I don't know yet.
6133
Features / Re: New revs - Public comments
« on October 4th, 2011, 07:03 PM »
Yeah, it should go - subject to a good (better) replacement being added.
6134
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 06:45 PM »
Quote from Nao on October 4th, 2011, 04:35 PM
Well... Readability is important -- when you're planning to maintain the thing!
But do you think you're going to?
Therein lies the issue. I don't really expect to do much maintenance, even less than with BB.
Quote
I was looking for similar software, thanks for pointing to it. I manually passed all of the getid3 files to it, stripping comments and whitespace (but not doc comments because getid3 uses this in its parser... Geeky for sure, but a horrible way of doing things!), and keeping just the header comment.
The comments aren't needed for phpseclib and with the header that retains the copyright and so on, I spent 15 minutes on it and got it down to 280KB or so, then just spent time faffing about cleaning the code, didn't really change the size but it did make it tidier. It'll zip fairly well, I think, haven't tested it.
Quote
Not bad...! Although I'll have to test it, I guess... It's an interesting alternative, and it only took 15 minutes or so to convert all of the files. Something I *can* do on each major release for sure...
How important is it to keep the download size small vs readable? I'm not actually that fussed myself.
Quote
- doing on-the-fly minification (i.e. not cached...) on inline JS and CSS. Do you think it's realistic? I'm not sure myself, but I could cook up a simplified minification function, although I wouldn't know how to deal with strings. Hmm. Still, just as an example, if I manually minify the noi_resize() code, I save something like 60 to 80 bytes off the page, and a reasonable ~20 bytes when gzipped. Considered it's to be found on every single page...
If it's on every single page, why is it inlined? Or, at least, not minified by hand?
Quote
- media cache: I'm always tempted to add a htaccess for the media folder, just so I don't get the pagespeed warning when it can't find a far-future expiration date. Problem is -- if you replace the files with a newer version, if the files have the same name, then the generated name has the same name as well. And that's only for thumbnails... Previews and full pics are accessed through PHP, so I can't "regenerate" a new filename for them, it won't help at all.
Aren't the timestamps included in the filename? They are for avatars.
Quote
Need I worry about caching media items at all...?
If the timestamp's part of it, yes, we can cache them. If not, don't worry about it.
Quote
- considering using YepNope to load jQuery and subsequent code. YepNope is 1.6kb minified and gzipped, so it's not exactly super-light, but at least it would trick pagespeed into thinking no other JS is executed at page load time, so I'd be likelier to get it to a perfect score... Main problem is, I doubt I'll be saving any time here. The only 'big' script we have to load is jQuery, the rest is negligible (except maybe for script+theme). At best, jQuery will load in parallel while YN is loading other JS files, and thus will be able to execute everything at the same time instead of waiting to load script+theme and other scripts after jQ is loaded. Still, if jQ is integrated into the main local file, it's even more pointless. At worst, YN wastes time executing itself when both jQ and local scripts are already cached... :-/
I wouldn't worry about YepNope, because you're still doing more work that doesn't - ultimately - benefit the user. It just fools a score.
Quote
- Considering using "FileETag none" in all htaccess files. I'm not a specialist though... But as soon as we have an expiration date, ETags aren't useful at all. I'm not sure if it should be done for all files.
If you have an expiration date, the ETag is still good until that date.
Quote
- IP packets carry the cookie, as everyone knows. My question would be, does it carry it only in the first packet of the page, or on every single freakin' packet? In which case it'd be in our interest to make cookie size as small as possible...
It's embedded into the HTTP request, which is only sent once for the request, even if the header is split across multiple packets because of lots of extra headers. It's still worth keeping it as small as possible (though, frankly, I don't see how else we can!) simply to hope we can keep it into as few packets as possible.
Quote
- I noticed that by default, avatars are loaded into the attachment folder. I *know* AeMe will change the entire system, but since I still don't know when I'll deal with this, I'd like us to consider creating a 'custom' folder in /avatars/ and upload all avatars there by default -- and obviously, set Wedge by default to show clear URLs for these avatar images. We save *by default* as many HTTP requests (to PHP FFS!) as there are avatars on the page.
http://tracker.wedge.org/?sa=ticket;ticket=28 ;) Yes, we save multiple PHP/DB requests *per page load*.
6135
Features / Re: These two bytes may not matter to you...
« on October 4th, 2011, 12:45 PM »
Oh, I'm slacking today. Instead of a bunch of var declarations (or a bunch of private declarations, or whatever), I can do simply one big one and make it a long line. Means I get to do it properly *and* save space compared to how it was before!