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 - Nao
3916
Archived fixes / [wedge site] Re: background image does not show in Firefox
« on January 14th, 2013, 07:06 PM »
I tend to use Chrome, Firefox and Opera indifferently these days... Heck, I've even been known to use IE10 for a few days recently... :whistle:
Just whatever doesn't crash on me when I use 100+ tabs, overall. Firefox is best at this game these days (used to be Opera 11.xx), but it still freezes at startup sometimes. Like these days. At least my Pale Moon session only had a couple dozen tabs ;)
Oh BTW, image embedding = done automatically by Wedge.. You don't have anything to do. If you do change one of the image files, though, you'll have to tell Wedge by either emptying the CSS cache, or just reuploading skin/common.css or whatever (it'll usually have the same effect as emptying the cache.)
Just whatever doesn't crash on me when I use 100+ tabs, overall. Firefox is best at this game these days (used to be Opera 11.xx), but it still freezes at startup sometimes. Like these days. At least my Pale Moon session only had a couple dozen tabs ;)
Oh BTW, image embedding = done automatically by Wedge.. You don't have anything to do. If you do change one of the image files, though, you'll have to tell Wedge by either emptying the CSS cache, or just reuploading skin/common.css or whatever (it'll usually have the same effect as emptying the cache.)
3917
Archived fixes / [wedge site] Re: background image does not show in Firefox
« on January 14th, 2013, 02:33 PM »
Looked into this...
Latest Pale Moon is v15.
Wedge recently got rid of pre-16 support, which is when prefixes were dropped for gradients.
Hence, gradients don't show. :(
Fixed by downgrading requirement to v15.
"The next major version of Pale Moon will be v19, to not fall behind too much in both graphics rendering engine and web standards support, even if this does not include h.264 video (which is planned for Firefox 20)."
(from website, this week.)
I'll update requirements when they do.
Latest Pale Moon is v15.
Wedge recently got rid of pre-16 support, which is when prefixes were dropped for gradients.
Hence, gradients don't show. :(
Fixed by downgrading requirement to v15.
Posted: January 14th, 2013, 02:31 PM
"The next major version of Pale Moon will be v19, to not fall behind too much in both graphics rendering engine and web standards support, even if this does not include h.264 video (which is planned for Firefox 20)."
(from website, this week.)
I'll update requirements when they do.
3918
Test board / Re: Losers. Testing.
« on January 13th, 2013, 11:12 PM »
Isn't that already the case?
3920
Archived fixes / Re: Error in Error log?
« on January 13th, 2013, 12:15 PM »
I explained myself incorrectly.
Basically, if I remove the first few elements of the test, which all evaluate to false, we find ourselves with:
if (strpos($file, $real_source) === false)
fatal_error(..)
Which evaluates to true for anything that is NOT in the Sources folder... (Even a root file will thus return an error, as opposed to what I said last night. It was very, very late for me...)
Hence the bug.
Also, it evaluates for $cachedir later in the line... Which doesn't make much sense to me..?! :edit: Oh yes it does, it ensures we shouldn't be trying to read a cache file...
Oh, and these extra brackets 'joining' the $boarddir and $sourcedir tests are weird and unneeded :P It really feels like a && test that became a || test and wasn't reprocessed entirely. Which is the case, but you know how much of a nazi I am for these things... :^^;:
So, basically, I've rewritten it to this...
Code: [Select]
I'm putting all of the 'light' work ahead, then the longer operations (realpath and is_readable) at the end, only one realpath is done, except if $boarddir isn't found in the path, in which case another realpath is done against $sourcedir (in the unlikely case $sourcedir isn't part of the $boarddir path...), and that should be it.
At the very least, that line works on my setup. Is it okay if I commit this?
PS: obviously, the $realxxx initialization lines are removed. This is to avoid doing a realpath(), as fast (or slow) as they might be, when the tests aren't even used. Well, it's an obscure admin feature so the only thing that wasted time here is *me* actually, but whatever... :lol:
Changed line to this...
Code: [Select]
I'm pretty sure people would want to protect against root_forum/Sources/../cache/randomname.php ;)
Although I don't really see how they could reach a critical cache file with a random filename, but whatever...!
Basically, if I remove the first few elements of the test, which all evaluate to false, we find ourselves with:
if (strpos($file, $real_source) === false)
fatal_error(..)
Which evaluates to true for anything that is NOT in the Sources folder... (Even a root file will thus return an error, as opposed to what I said last night. It was very, very late for me...)
Hence the bug.
Also, it evaluates for $cachedir later in the line... Which doesn't make much sense to me..?! :edit: Oh yes it does, it ensures we shouldn't be trying to read a cache file...
Oh, and these extra brackets 'joining' the $boarddir and $sourcedir tests are weird and unneeded :P It really feels like a && test that became a || test and wasn't reprocessed entirely. Which is the case, but you know how much of a nazi I am for these things... :^^;:
Posted: January 13th, 2013, 09:51 AM
So, basically, I've rewritten it to this...
if (strrchr($basename, '.') != '.php' || $basename == 'settings.php' || $basename == 'settings_bak.php' || strpos($file, $cachedir) !== false || (strpos($file, realpath($boarddir)) === false && strpos($file, realpath($sourcedir)) === false) || !is_readable($file))
I'm putting all of the 'light' work ahead, then the longer operations (realpath and is_readable) at the end, only one realpath is done, except if $boarddir isn't found in the path, in which case another realpath is done against $sourcedir (in the unlikely case $sourcedir isn't part of the $boarddir path...), and that should be it.
At the very least, that line works on my setup. Is it okay if I commit this?
PS: obviously, the $realxxx initialization lines are removed. This is to avoid doing a realpath(), as fast (or slow) as they might be, when the tests aren't even used. Well, it's an obscure admin feature so the only thing that wasted time here is *me* actually, but whatever... :lol:
Posted: January 13th, 2013, 12:03 PM
Changed line to this...
if (strrchr($basename, '.') != '.php' || $basename == 'settings.php' || $basename == 'settings_bak.php' || (strpos($file, realpath($boarddir)) === false && strpos($file, realpath($sourcedir)) === false) || strpos($file, realpath($cachedir)) !== false || !is_readable($file))I'm pretty sure people would want to protect against root_forum/Sources/../cache/randomname.php ;)
Although I don't really see how they could reach a critical cache file with a random filename, but whatever...!
3921
The Pub / Re: I just discovered a trick
« on January 13th, 2013, 10:43 AM »
How do you think i added badges to the select box in profile account pages? ;)
3922
Archived fixes / Re: Error in Error log?
« on January 13th, 2013, 12:53 AM »
I've found the reason for the recent crashes when trying to view a file...
It only happens (to me) when trying to view a template. Just insert a random error in one of them and check it out...
So, the reason is rev 1829, where Pete fixed a 'directory traversal error', but I'm guessing not as thoroughly as hoped.
SMF does: if path has '../' in it, then if the path has both $boarddir and $sourcedir in it, send an error. I'm guessing the bug is related to having a requirement for BOTH..?
Wedge does: if realpath(path) has $boarddir or $sourcedir in it, then it's all right, otherwise send error. That is, it only accepts paths that are in the root, or in Sources. It no longer accepts templates etc.
I'll leave the fix up to you, Pete, since you wrote it in the first place and you'll be more comfortable dealing with it. Hopefully my bug report makes it easier for you to work on :)
Time for bed...
(Grmpf I still haven't found time to answer this SMF topic. And yes, I have no problems joining up with Pete on anything he's willing to do regarding either SMF or Wedge. We're pretty much in the same position and state of mind when it comes to these. Sorry for the off-topic...)
It only happens (to me) when trying to view a template. Just insert a random error in one of them and check it out...
So, the reason is rev 1829, where Pete fixed a 'directory traversal error', but I'm guessing not as thoroughly as hoped.
SMF does: if path has '../' in it, then if the path has both $boarddir and $sourcedir in it, send an error. I'm guessing the bug is related to having a requirement for BOTH..?
Wedge does: if realpath(path) has $boarddir or $sourcedir in it, then it's all right, otherwise send error. That is, it only accepts paths that are in the root, or in Sources. It no longer accepts templates etc.
I'll leave the fix up to you, Pete, since you wrote it in the first place and you'll be more comfortable dealing with it. Hopefully my bug report makes it easier for you to work on :)
Time for bed...
(Grmpf I still haven't found time to answer this SMF topic. And yes, I have no problems joining up with Pete on anything he's willing to do regarding either SMF or Wedge. We're pretty much in the same position and state of mind when it comes to these. Sorry for the off-topic...)
3923
Features / Re: New revs
« on January 12th, 2013, 07:06 PM »
rev 1842 -- heavy CSS work I had to commit for the last few months... Hopefully won't break anything, please test! -_-
(10 files -13, 9kb)
! Various Wuthering fixes, such as blog titles, fixing the sidebar, removing the gradient on the header (grew tired of it!), or rewriting the breadcrumb for better results and cross-browser compatibility. (Wuthering/extra.css)
* Moved plenty of browser hack CSS files into their parents, using @if and @is instructions. Not all children files were removed, I'm still trying to determine if it's worth it for big files like main IE hacks. (common.css, common.firefox[-2].css, extra.chrome.css, extra.firefox.css, extra.ie[-8].css, index.css, index.member.css, media.css, media.ie[-7].css, zoom.css, zoom.webkit.css, WINE: extra.css, extra.ie.css, extra.ie6.css, extra.ie8.css, WARM: extra.css, extra.ie[-9].css, extra.ios.css, WUTHERING: extra.css, extra.ie[-9].css, WIRELESS: extra.css, extra.ios.css)
- Removed a safety on Chrome. It didn't have the opacity animation on menus, perhaps it used to kill performance? Please report if you have any problems with this, seems to work fine in Chrome v26. (extra.chrome.css)
* Giving a max to a random input value somewhere, because its input size bothered me. You know me... (ManageSettings.php)
(10 files -13, 9kb)
! Various Wuthering fixes, such as blog titles, fixing the sidebar, removing the gradient on the header (grew tired of it!), or rewriting the breadcrumb for better results and cross-browser compatibility. (Wuthering/extra.css)
* Moved plenty of browser hack CSS files into their parents, using @if and @is instructions. Not all children files were removed, I'm still trying to determine if it's worth it for big files like main IE hacks. (common.css, common.firefox[-2].css, extra.chrome.css, extra.firefox.css, extra.ie[-8].css, index.css, index.member.css, media.css, media.ie[-7].css, zoom.css, zoom.webkit.css, WINE: extra.css, extra.ie.css, extra.ie6.css, extra.ie8.css, WARM: extra.css, extra.ie[-9].css, extra.ios.css, WUTHERING: extra.css, extra.ie[-9].css, WIRELESS: extra.css, extra.ios.css)
- Removed a safety on Chrome. It didn't have the opacity animation on menus, perhaps it used to kill performance? Please report if you have any problems with this, seems to work fine in Chrome v26. (extra.chrome.css)
* Giving a max to a random input value somewhere, because its input size bothered me. You know me... (ManageSettings.php)
3924
Features / Re: Plugin revs
« on January 12th, 2013, 05:40 PM »
rev 68
* Replaced $scripturl with <URL> tricks in all plugins, except for the calendar. I'm lazy right now. (Birthday-Main.php, Fitter-Admin.php, mass_upload/plugin.php, Readability-Admin.php, ThemeSelector.php, TopicButtons.php)
* Replaced $context['user'] with we object. (PersonalMessageFlash.php, ThemeSelector.php, TopicButtons.php, OnlineToday.php)
* Replaced $scripturl with <URL> tricks in all plugins, except for the calendar. I'm lazy right now. (Birthday-Main.php, Fitter-Admin.php, mass_upload/plugin.php, Readability-Admin.php, ThemeSelector.php, TopicButtons.php)
* Replaced $context['user'] with we object. (PersonalMessageFlash.php, ThemeSelector.php, TopicButtons.php, OnlineToday.php)
3925
Archived fixes / Re: Development blog page. Blog topic name overlaps author name, time & date
« on January 12th, 2013, 02:20 PM »
Known issue, due to .title styling in these skins (that's the headers you can see in sidebars for instance.)
Yeah I should work on fixing that...
Yeah I should work on fixing that...
3926
Features / Re: New revs
« on January 12th, 2013, 12:54 AM »
rev 1840
(27 files, 8kb)
* Finished converting $context['user'] to we::$user. Hopefully, it'll work without changes... (Display.php, Login.php, ManageMembergroups.php, PackageGet.php, PersonalMessage.php, Aeva-Gallery.php, ManageMedia2.php, Post.php, Profile.php, Profile-*.php, Register.php, Search2.php, Security.php, Subs-Cache.php, Subs-Template.php, ViewQuery.php, TEMPLATES: Admin, Boards, Display, index, InfoCenter, Login, Mailer, ManageMembergroups, MAnagePaid)
@ Note to Pete: lulz, commit conflict ;) I'd actually fixed the index template typo ready for this rev (hence the rev conflict), but it's good that you saw it as well!
(27 files, 8kb)
* Finished converting $context['user'] to we::$user. Hopefully, it'll work without changes... (Display.php, Login.php, ManageMembergroups.php, PackageGet.php, PersonalMessage.php, Aeva-Gallery.php, ManageMedia2.php, Post.php, Profile.php, Profile-*.php, Register.php, Search2.php, Security.php, Subs-Cache.php, Subs-Template.php, ViewQuery.php, TEMPLATES: Admin, Boards, Display, index, InfoCenter, Login, Mailer, ManageMembergroups, MAnagePaid)
@ Note to Pete: lulz, commit conflict ;) I'd actually fixed the index template typo ready for this rev (hence the rev conflict), but it's good that you saw it as well!
3927
Features / Re: New revs
« on January 11th, 2013, 07:29 PM »
rev 1838
(22 files, 15kb)
* Turned $context['user']['is_logged'] into !we::$is_guest, $context['user'] into we::$user and optimized $context globaling on many files. (index.php, Subscriptions-Authorize.php, Subscriptions-twoCheckOut.php, smfinfo.php (uh?), Ajax.php (actually a comment that no longer makes much sense..), Class-System.php, Load.php, MessageIndex.php, Profile-Modify.php, Subs-Template.php, ViewQuery.php, SSI.php, TEMPLATES: Boards, index, ManagePermissions, MessageIndex, ModerationCenter, Profile)
* Converted a few more $scripturl calls to <URL>. (MessageIndex.template.php, Profile.template.php)
* Forgot to commit a couple of language files. French translation, but also another fix (a line that is no longer used AFAIK.) (Admin.english.php, Admin.french.php, ManagePlugins.french.php)
! Fixed Chrome and IE10 behaving oddly with the body transition when loading (IE10) or reloading (Chrome) pages. (index.css)
@ Only got started on $context['user'], as there are a lot, so please bear with me, I should fix Wedge, err... hopefully tonight. I'm watching the FF9 live speedrun for AGDQ at the same time... These are the limits of my multi-tasking abilities.
(22 files, 15kb)
* Turned $context['user']['is_logged'] into !we::$is_guest, $context['user'] into we::$user and optimized $context globaling on many files. (index.php, Subscriptions-Authorize.php, Subscriptions-twoCheckOut.php, smfinfo.php (uh?), Ajax.php (actually a comment that no longer makes much sense..), Class-System.php, Load.php, MessageIndex.php, Profile-Modify.php, Subs-Template.php, ViewQuery.php, SSI.php, TEMPLATES: Boards, index, ManagePermissions, MessageIndex, ModerationCenter, Profile)
* Converted a few more $scripturl calls to <URL>. (MessageIndex.template.php, Profile.template.php)
* Forgot to commit a couple of language files. French translation, but also another fix (a line that is no longer used AFAIK.) (Admin.english.php, Admin.french.php, ManagePlugins.french.php)
! Fixed Chrome and IE10 behaving oddly with the body transition when loading (IE10) or reloading (Chrome) pages. (index.css)
@ Only got started on $context['user'], as there are a lot, so please bear with me, I should fix Wedge, err... hopefully tonight. I'm watching the FF9 live speedrun for AGDQ at the same time... These are the limits of my multi-tasking abilities.
3928
Other software / Re: Discussing Wedge on simplemachines.org
« on January 11th, 2013, 06:03 PM »
It's just a bit sad to let the 'SMF' brand die, somehow. I still like it, just as much as I like my own 'Wedge' brand... (It's just that I'm not a fan of how the product is managed, to begin with.)
Pete, I don't think that ~200 extra bytes is short. Also, an extra line is needed at the beginning (/** isn't just there for show, technically... :P)
And we can't really remove our file description, either... I'd say.
We could get rid of @version, though. It's a SMF thingy, we never really took care of it, and I don't know if it's ever gonna become useful to us one day.
Pete, I don't think that ~200 extra bytes is short. Also, an extra line is needed at the beginning (/** isn't just there for show, technically... :P)
And we can't really remove our file description, either... I'd say.
We could get rid of @version, though. It's a SMF thingy, we never really took care of it, and I don't know if it's ever gonna become useful to us one day.
3929
Archived fixes / Re: Why does Wedge look different for me?
« on January 11th, 2013, 05:59 PM »3930
Other software / Re: Discussing Wedge on simplemachines.org
« on January 11th, 2013, 01:53 PM »
...?
16 lines...? Not very large?
Ours is like 2 lines...
16 lines...? Not very large?
Ours is like 2 lines...