-
As you may notice, there are quite a few(!) topics in this board now that represent SMF bugs that are suspected or known to exist in Wedge.
It's sort of a to-do list for me, and if no discussion results, I'll just merge the notice (with a note to confirm when it was fixed) into this thread to keep it tidy :)
-
Well, it should. I seem to recall looking at this before, but it should definitely be removed now there is absolutely no use for it, without the key/value cache, it has no benefits in the caching subsystem.
Posted: February 29th, 2012, 01:37 PM
Fixed in Wedge r1407.
-
While I think this is unnecessary fussing about a tiny amount, it doesn't hurt to put in such calls (and as my comment from ages ago in the related thread implies, it may have benefits that aren't immediately obvious)
Posted: February 29th, 2012, 01:48 PM
Fixed in Wedge r1407.
-
I was like WTF!? :lol:
-
For consistency, warning boxes/success notifications should all be in a consistent place and consistently styled - above principle content in the default area (but under menu tabs/tab data) - which the stated places do not adhere to (search personal messages, search generall judging by this post(http://www.simplemachines.org/community/index.php?topic=400683.msg3101331#msg3101331))
Posted: February 29th, 2012, 02:33 PM
Fixed in Wedge r1408.
-
Me too Nathan XD
-
Me too!
And no time to deal with it today (I'm having guests) and possibly tomorrow... UNTIL WE HAVE TO GO LIVE >_<
Very bad timing for guests, eh?
-
Eh I wouldn't worry, nothing here is *that serious* because if it was, I'd be hard at work fixing it, as opposed to sitting on my butt. It's simply that there's a lot of bugs that slipped through the net and this was the quickest way to record them so I didn't forget them.
-
And, bah, I should have posted this thread *first* because now half the threads would be messed up if I merged them here. Stupid, very stupid >_<
-
Ref http://www.simplemachines.org/community/index.php?topic=411507.0
Regarding the use of reason phrases being translated, I have to say that the reporter is incorrect. Certainly as per HTTP 1.1, section 6.1.1 of the specification(http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1):The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.
Regarding of SERVER_PROTOCOL, that's a much trickier question, but HTTP/1.0 is a valid response even to an HTTP/1.1 request given the situation.
Ultimately, I don't think anything needs to be done, but I'm documenting the state of play anyway.
Posted: February 29th, 2012, 01:04 PM
Even in HTTP 1.0, as per 6.1.1 of that spec(http://www.w3.org/Protocols/HTTP/1.0/spec.html#Status-Line):The individual values of the numeric status codes defined for HTTP/1.0, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol.
-
Just edit the first post in the new topic ;)
-
I suppose I could do that, yes. Surprisingly enough that didn't actually occur to me >_<
-
While it's possible this will be pulled, in the meantime until the fate of permissions is decided, it probably should be fixed.
Posted: February 29th, 2012, 02:55 PM
OK, I know why this is happening in SMF and why I apparently couldn't reproduce it myself. It's hidden permissions.
The first 'gap' where it skips a windowbg, should be approve_posts permission - but it's disabled by default. And the row is inverted regardless of whether anything was displayed or whether an input type="hidden" was inserted in its place. Just need to quietly move the flipping of state.
Posted: March 1st, 2012, 12:31 AM
Fixed in Wedge r1410.
-
Confirmed in Wedge, needs to be fixed.
Posted: February 29th, 2012, 01:09 PM
Fixed in Wedge r1411.
-
Because the form isn't validating properly, only relying on the session data being in $_POST to identify that it's supposed to receive content, it gets confused if the form immediately before happens to be the validate-password triggers from admin security (which also sends the session data in $_POST the same way)
Suggested solution is good (to name the submit and check for that instead)
Posted: February 29th, 2012, 02:46 PM
Fixed in Wedge r1411.
-
In the approve deletion screen, members are listed by registration date (like they are for approving new accounts), but we should rework that to order by last login, as stated it is likely to be more useful to decide whether to approve the deletion or not.
Posted: February 29th, 2012, 01:52 PM
Fixed in Wedge r1412.
-
Good work!
You'll reach 9k posts by tomorrow at this rhythm, BTW :lol:
OT
I'm still groggy from my evening. Totally unable to deal with coding. And it really, really doesn't happen to me often...
Definitely not a day to convert Wedge.org to use Wedge.
I will, however, at the very least release screenshots of Weaving. If the importer bugs are fixed today, I'll also publish a version running Wedge.org (but NOT on wedge.org, and possibly with posting disabled), otherwise I'll just publish a bare-bones version.
-
You'll reach 9k posts by tomorrow at this rhythm, BTW
I'm still groggy from my evening. Totally unable to deal with coding. And it really, really doesn't happen to me often...
-
Yeah I'll take it slow today.
I meant rate not rhythm. Direct french translation ;)
-
Well, rhythm/rate can be used interchangeably here ;)
I'm going through page 2 of their bugs now, and just as before, some don't apply to us due to obsolete features, some already got fixed in passing for other reasons and the rest... >_< But no worries, we'll get through everything in due course! Slow and steady wins the race, as they say.
-
In our case, everything is UTF-8, so we don't even need to wait to know what the character set is, we can just issue the header directly from SSI.php - if a different header is required, user code can replace it, but it should default to UTF-8 with text/html as a MIME type (because that's, principally, what SSI.php pages do)
Posted: March 1st, 2012, 01:44 PM
Fixed in Wedge r1413.
-
If i bbcode is disabled in signatures, img is as well due to the way string matching occurs.
And I even helped fix this one originally >_>
Posted: March 1st, 2012, 01:38 PM
Fixed in Wedge r1413.
-
These do detection based on matching the style of filename, but never detect for ~ endings. While this isn't really a problem for us, because we're not doing backups etc, I think it would be good practice to actually validate that it is a .php file and not anything else. It isn't harmful for what we're doing.
Posted: March 1st, 2012, 01:31 PM
Fixed in Wedge r1413.
-
This is a quirky one. Back in the mists of time, you used to be able to get a linktree that looked like a folder tree (each line was a new row, with folders and branches and stuff) but it was removed in 2.0 - but there was some legacy code attached to it.
Now, RC4 removed the actual UI option for it but left the lang string and a few related bits, but they can all go as well.
Posted: March 1st, 2012, 03:17 PM
Fixed in Wedge r1414.
-
I'm inclined to agree - if the forum stats aren't being tracked, there's not really a lot of point leaving the page available.
Posted: March 1st, 2012, 03:48 PM
Fixed in Wedge r1414.
-
If i bbcode is disabled in signatures, img is as well due to the way string matching occurs.
And I even helped fix this one originally >_>
-
Yes, that is what it is ultimately about, however at the time (and now, really), I figured it was only about stopping those characters rather than \b, though \b should work just fine.
And actually, theoretically, there could be a bbcode that contains a character that matches \b... it would be ugly of course but not impossible.
-
You mean a BBC like "[hello,world=foobar]"...? Sounds silly to me... ;)
-
Well, yeah, but doesn't prevent it being possible. I have encountered people doing numbers in bbcode in the past, doesn't seem to me as it would take much in the way of imagination for them to go one step further and use symbols given half a chance.
I have no idea if it would work or not, though ;)
-
I doubt it would :P
Well, even accented characters would be accepted... It's just an equivalent of (?!\w), anyway. (But I'd rather use \b because I'm not sure it'd work at the end of a string.)
-
It's just an equivalent of (?!\w)
-
Was playing with forum URL changes, and I've got to say, it's pretty complicated to update everything...
Wedge tells me to click here to update URLs. So I go there and it's just the theme page, so I update the theme data but the regular forum URL page isn't mentioned (although I did manually modify the Settings.php page), and Smiley sets, avatar and attachment URLs aren't mentioned either.
Also, even after updating all of these, I still needed to empty my JS cache manually. (Not sure why, but CSS was okay...)
Other issues: in the Attachment pruning page, I tried all three options to delete all files. The first one deleted a few files. The 'more than X days' setting was flawed: if I type in 0, it won't delete all files.
And the other two choices are similar. I was totally unable to delete any of the remaining files (dated today, 11:30am).
-
To a degree, this is why SMF always suggests use of repair_settings.php to fix everything.
As far as the attachment pruning, I seem to recall 0 being ignored as it falls foul of empty(), though it is a little unlikely to want to prune everything. I'm not sure it is a bug as a result. But I can look into it.
-
To a degree, this is why SMF always suggests use of repair_settings.php to fix everything.
As far as the attachment pruning, I seem to recall 0 being ignored as it falls foul of empty(), though it is a little unlikely to want to prune everything. I'm not sure it is a bug as a result. But I can look into it.
Also, max width and max height for attachment thumbnails are set to 400 in your code... Any reason for that? Even here, the max width is much higher than that. I changed it locally to 1280x1024 which is probably good enough for maximum thumbnail dimensions... :P
Speaking of which, how about setting 'int' to have a 'min' of 0 by default? You've already set it to 0 pretty much everywhere, really...
-
I've never really used that one. Don't even know if it works with Wedge actually...
Also, max width and max height for attachment thumbnails are set to 400 in your code... Any reason for that? Even here, the max width is much higher than that. I changed it locally to 1280x1024 which is probably good enough for maximum thumbnail dimensions...
Looking at this site, I don't think any thumbnail size is set (that's what 0 is for) but image attachments are capped at 640 wide, which means no thumbnail is generated.Speaking of which, how about setting 'int' to have a 'min' of 0 by default? You've already set it to 0 pretty much everywhere, really...
-
Curious error, though probably not very common to occur.
Posted: March 2nd, 2012, 11:09 AM
Fixed in Wedge r1417. Oddly enough it was a very simple fix, not even as complex as the one suggested in the bug report (no need to mess around unsetting session, just test session is set and that the relevant $show_method is also set. In our case it's even the very same isset call.
-
Easy fix this one.
Though, curiously, I appear to have broken other things in the paid subs area, so I'll fix that at the same time.
Posted: March 2nd, 2012, 11:07 AM
Fixed in r1417.
-
At least the replacement needs to be altered to prevent this, but it is worth spending a moment to explore whether rawurlencode is worth applying here or not (possibly not)
Posted: March 2nd, 2012, 10:34 AM
I've patched this in r1417, but I haven't done rawurlencode on it yet.
I was about to mark this one as done then I suddenly had a thought, and bad mojo happens if it contains fun characters like ', like an uncaught exception if it has to go do a web lookup.
Posted: March 2nd, 2012, 11:46 AM
Actually, I was wrong, the exception wasn't occurring because of the fun characters (they simply get htmlspecialchars'd somewhere as far as I can tell, no idea why that is right now), but because the URL I'd supplied caused a redirect which threw an exception. So I beefed up exception handling, and made things fall back cleaner to a 'safe' state.
-
Well, setting a max is good because it prevents the textboxes being huge (otherwise they're long enough to easily fit a 32 bit int), and I just figured 400 was a sane size for a *thumbnail*.
Wedge caps normal image size to 1280x1024 but it never works, they're always capped in 640x480. Does it mean I did it the other way around? That there's a setting I didn't find in the admin area, where I can set them to 1280x1024 and then a thumbnail size of 400x400 which, in this case, is perfectly allowable...?Speaking of which, how about setting 'int' to have a 'min' of 0 by default? You've already set it to 0 pretty much everywhere, really...
Maybe it's a bad idea, but if you search for array('int', -- it will always return values that shouldn't be < 0. Well, didn't look through all of them, but it looks like it. Generally speaking, SMF never asked an admin to set a value of -1 to disable something or whatever -- always zero.
Posted: March 2nd, 2012, 01:41 PM
Oh, a possible bug...?
Manage Attachments > Prune > Prune avatars for members who haven't logged in over X days
Enter a number, press the button.
"Unable to verify referring url. Please go back and try again."
Always says that...
Posted: March 2nd, 2012, 01:44 PM
Actually says the rest on other options, too.
-
I thought thumbnails were what Wedge would show below posts -- i.e. what is capped to 640x480 on Wedge.org right now. I thought there was nothing else..?
Generally speaking, SMF never asked an admin to set a value of -1 to disable something or whatever -- always zero.
"Unable to verify referring url. Please go back and try again."
Always says that...
-
The date parameter is not passed between pages properly, causing page 2+ not to filter by date.
Posted: March 2nd, 2012, 10:56 AM
I can reproduce this on SMF but I apparently can't reproduce this on Wedge even though the code hasn't apparently changed.
Posted: March 2nd, 2012, 01:26 PM
Eh, no, I can reproduce it. Just didn't see what I expected to see to start with. >_<
Posted: March 2nd, 2012, 01:32 PM
Fixed in r1419.
-
They are - to a point. If the image size is smaller than the thumbnail size, it will display the image unresized. Now, if no thumbnail size is set, it will just show the image full size... (that's what's happening here)
Generally speaking, SMF never asked an admin to set a value of -1 to disable something or whatever -- always zero.
Lemme guess, there's a broken image somewhere on the page?
(I've noticed this before: where even 404s are pushed to Wedge for handling, it screws up the referer, 404s need to not be logged in writeLog())
-
It's not full size here, it's at 640x480... Which is precisely the setting I'd like to modify. Having to use the media gallery when you just want to post a quick attachment isn't so cool.
Well, they need to be if you want the admin to be able to fix the 404 in the first place...?
-
It's not full size here, it's at 640x480... Which is precisely the setting I'd like to modify. Having to use the media gallery when you just want to post a quick attachment isn't so cool.
Well, I know that Weaving reports 3 missing images on the page for me, which fouls it up.
You can download them off the demo site if you want. They're there, you just need to upload them to the folders they belong to. I know, it's a hassle, but I have yet to update the site with the new tentative logos ;)I have no issue with the htaccess pushing 404s to index.php, but they must not be logged in writeLog(), because that pushes it into the online log, which is where the referrer is tracked as far as checkSession('post', 'admin') is concerned (which is what's causing the problem)
-
But the thumbnail settings in Wedge.org are 1280x1024. Where does the 640 value come from, then..?
logging 404's and not logging them for checkSession use.
-
"Fixed in r...."
Are you fixing all these bugs as you go along or just reserving an r number?
-
Just look at the New revs topic ;)
-
Yup, the r number indicate what revision in Wedge where the fix gets committed.
-
In that case I'm genuinely impressed. I've read all the topics and the new revs thread and it all sounds clever, but being able to bosh through the bugs in such a short period is real. Dare I wonder when SMF 2 would have been released if it were just the two of you on the team?
-
Maybe March or whenever the NPO got finalised. IIRC, they couldn't release it without an OSI license.
-
But the thumbnail settings in Wedge.org are 1280x1024. Where does the 640 value come from, then..?
And it doesn't work.
Heck. It's still resized to 640x480 max. So I don't see the point of one or the other.
:edit: Trying again, this time with thumbnails disabled.
:edit: Still doesn't work... This time, the thumbnail size data is emptied (not set to 0, just emptied.)
Still, I just have a question... Why the hell does this option show up in an admin area that has *nothing* to do with attachments...?!
It should be moved!
Logic says that if a software author can't find an option in their own software, it's because it's out of place.How do we know to log it? If we know to log it, we know to define WEDGE_NO_LOG so that it won't be logged in the online log.
-
Still, I just have a question... Why the hell does this option show up in an admin area that has *nothing* to do with attachments...?!
It should be moved!
Honestly, in this situation you know better than I do. I'm just saying we need to log this into the error log. In case it's not possible to log into the error log but not into the online log, then a new param should be added to specify that the online log should be skipped.
The code that logs a 404 is in QueryString.php, beginning with:
// Don't bother going further if we've come here from a *REAL* 404.
But yet it displays the standard content, indicating to me it isn't triggering. But all you should have to do is add a define of WEDGE_NO_LOG there.
-
What setting, exactly, are you changing?
Maximum uploaded image width (0 = disabled)
And same for height (the option below it.)
Set them to 1280x1024. Then I set the thumbnail size to 640x480 in Attachment Settings. They did get resized, but the original upload isn't kept.
Oh, I get it... The option is for REJECTING an upload if it's too wide/tall, not for resizing it. Which doesn't make sense. Especially compared with AeMe's comprehensive way of handling these. Heck... Another good incentive for getting rid of attachments, eh :P
Still, it automatically resizes the pics to 640x480 even with no thumbnail settings in...But yet it displays the standard content, indicating to me it isn't triggering. But all you should have to do is add a define of WEDGE_NO_LOG there.
Technically, these errors should be shown in a template-free template. Just a text message...
-
While I'm at it.
I'm currently adding language detection to the installer.
Here's the current logic implemented in SMF: take the first language in the list. If it's English and there are more languages available, take the next one. It takes sense because SMF only ships with English. Wedge has French available in the SVN, so it will always default to French because it assumes you want French.
So, possible solutions:
- implement browser detection and if it doesn't match an entry, fall back to SMF's solution
- just use SMF's solution and make sure not to ship French in the final release
What do you like best?
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name. I don't see myself maintaining a list of shortcuts against full names somewhere in the code... :^^;: And going through the complete list of index.*.php files, opening them and scanning for lang_dictionary or lang_locale... Not great either!
-
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name
And going through the complete list of index.*.php files, opening them and scanning for lang_dictionary or lang_locale... Not great either!
-
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name
@Farjo> Pete alone is working on these SMF bugs. Just don't want to steal his thunder ;)
-
Did you try?
Technically, these errors should be shown in a template-free template. Just a text message...
-
Interesting this one, you can see it on sm.org where the bugtracker child board is - there isn't proper padding between cells in the table.
Posted: February 29th, 2012, 02:39 PM
Or you could see it, apparently it has been fixed on sm.org at some point.
Posted: February 29th, 2012, 11:38 PM
I think this has been fixed in Wedge indirectly, as I can't seem to reproduce it through anything I can do (all boards seem properly spaced to me)
-
Generally there shouldn't be a need for it, and the resultant bandwidth can be saved (though a cursory glance suggests it's in the admin panel only) but when going through them, need to make sure that $_POST['submit'] isn't checked later to determine whether a specific button was pressed or not.
Posted: February 29th, 2012, 01:12 PM
Fixed in r1425.
-
The underlying problem is that if there is no agreement, there's no confirmation that the user is over COPPA age.
As I see it there are two choices, either disallow using COPPA when there's no agreement, or provide a substitute page that does do the 'I confirm I am over x years of age' test.
Posted: March 2nd, 2012, 11:11 AM
Fixed in r1426.
-
Pruning logs of spider activity is easy, but purging the log of stats is not.
Posted: March 4th, 2012, 06:08 PM
Fixed in r1427.
-
A small bump for #52, lost in an ocean of new posts ;)
-
Hmm, I need to investigate that deeper, unless there's some setting I managed to spirit away somehow.
-
It's just a mystery to me ;)
The answer is probably in plain view in some source file, but...
-
Like a bunch of stuff in SMF/Wedge, yes. I'll dig into it at some point, have other stuff I need+want to do first though.
-
Simple as that. It checks for the presence of specific theme variables to be set during registration (which cannot happen during normal registration, just through external registration and even then, with a bit of imagination), and if not found, it just sets to 'show, off by default', which sort of makes a mockery of the admin's settings, really.
Posted: March 7th, 2012, 12:30 AM
Fixed in r1441.