Fixed SMF bugs
it keeps giving me this error in Error Log »

Farjo

  • "a valuable asset to the community"
  • Posts: 492
Re: Fixed SMF bugs
« Reply #45, on March 2nd, 2012, 10:21 PM »
"Fixed in r...."

Are you fixing all these bugs as you go along or just reserving an r number?

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Fixed SMF bugs
« Reply #46, on March 2nd, 2012, 10:45 PM »Last edited on March 6th, 2012, 11:10 AM by Nao
Just look at the New revs topic ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fixed SMF bugs
« Reply #47, on March 2nd, 2012, 11:17 PM »
Yup, the r number indicate what revision in Wedge where the fix gets committed.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Farjo

  • "a valuable asset to the community"
  • Posts: 492
Re: Fixed SMF bugs
« Reply #48, on March 3rd, 2012, 07:31 AM »
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?

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Fixed SMF bugs
« Reply #49, on March 3rd, 2012, 08:19 AM »
Maybe March or whenever the NPO got finalised. IIRC, they couldn't release it without an OSI license.
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Fixed SMF bugs
« Reply #50, on March 3rd, 2012, 10:46 AM »
Quote from Arantor on March 2nd, 2012, 06:46 PM
Quote
But the thumbnail settings in Wedge.org are 1280x1024. Where does the 640 value come from, then..?
Maximum uploaded image size.
Okay, testing... Setting this option to 1280x1024, and thumbnails to 640x480.
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.
Quote
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.
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.

📎 test730.png - 31.51 kB, 640x446, viewed 172 times.

📎 test730.png - 31.51 kB, 640x446, viewed 170 times.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fixed SMF bugs
« Reply #51, on March 3rd, 2012, 11:57 AM »
Quote
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!
What setting, exactly, are you changing?
Quote
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.
It's weird.

The code that logs a 404 is in QueryString.php, beginning with:
Code: [Select]
// 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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Fixed SMF bugs
« Reply #52, on March 3rd, 2012, 12:13 PM »
Quote from Arantor on March 3rd, 2012, 11:57 AM
What setting, exactly, are you changing?
Largeur max. des images envoyées (0 = désactivé)
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...
Quote
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.
Did you try?

Technically, these errors should be shown in a template-free template. Just a text message...
Re: Fixed SMF bugs
« Reply #53, on March 3rd, 2012, 12:20 PM »
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!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fixed SMF bugs
« Reply #54, on March 3rd, 2012, 12:59 PM »
Quote
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name
It's not even as simple as that potentially. Remember that you get regional codes too, en_GB vs en_US for example.
Quote
And going through the complete list of index.*.php files, opening them and scanning for lang_dictionary or lang_locale... Not great either!
You only need to do it once at the start of installation remember.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Fixed SMF bugs
« Reply #55, on March 3rd, 2012, 01:26 PM »
Quote from Arantor on March 3rd, 2012, 12:59 PM
Quote
Browser detection is not great, because it returns a shortcode (fr, en) instead of the full name
It's not even as simple as that potentially. Remember that you get regional codes too, en_GB vs en_US for example.
Which is why I added lang_locale to the lot...

@Farjo> Pete alone is working on these SMF bugs. Just don't want to steal his thunder ;)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Fixed SMF bugs
« Reply #56, on March 4th, 2012, 02:13 AM »
Quote
Did you try?

Technically, these errors should be shown in a template-free template. Just a text message...
This works properly in r1424 now, it would only work before in the event of pretty URLs being enabled. And since I never enable that... :whistle:
SMF bug 4773 (multiple child boards aren't padded properly)
« Reply #57, on March 4th, 2012, 02:21 AM »
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)
SMF bug 4442 (submit buttons with name="submit")
« Reply #58, on March 4th, 2012, 03:13 AM »
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.
SMF bug 4817 (can't register if no agreement and COPPA age set)
« Reply #59, on March 4th, 2012, 03:20 PM »
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.
it keeps giving me this error in Error Log »