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
2266
The Pub / Re: git problems for non-gits.
« on November 16th, 2013, 11:00 PM »
Regarding issue 1990, I decided to look into squashing the commit with its fix.
So, I made a backup of my repo, then tried various options in TortoiseGit, which all failed. Nice. I then used the bash, with git rebase -i, and it was incredibly, horribly not natural. For instance, I can't select the buggy commit and rebase from that. I have to select the commit BEFORE it, and then ignore the buggy commit, and change the bugfix to 'squash'.
Then I can save the rebase file, wait for 10 minutes (how slow!), and I get a rewritten history.
Only problem, but I was expecting that, is that all subsequent commits have a different SHA1, so I'll/I'd have to push --force the result, and expect all of you guys to give up on your current repo, clone the updated repo somewhere else, and then transmit all your changes/commits to that new repo. A bit annoying...
But, OTOH, this also eliminates the 2 extra 'blame previous file' steps that we currently get everytime we're trying to blame a file that has an instance of a we::$user call (all of these ~99 files had their line endings corrupted by this wide-scale change using new software. Thank you, new software. Well, it's old and forgotten software since that day, of course.)
Are you okay with that, guys..?
I can't really expect the TortoiseGit committers to suddenly offer a -w parameter on their blame tool's settings UI, and if they do, I don't know if it'll be saved for all uses, etc, so I'd rather fix the repo myself.
I could also use the opportunity to rebase other problems in the history, but... Actually, I can't really think of anything else, so it's just this one shot, normally.
So, I made a backup of my repo, then tried various options in TortoiseGit, which all failed. Nice. I then used the bash, with git rebase -i, and it was incredibly, horribly not natural. For instance, I can't select the buggy commit and rebase from that. I have to select the commit BEFORE it, and then ignore the buggy commit, and change the bugfix to 'squash'.
Then I can save the rebase file, wait for 10 minutes (how slow!), and I get a rewritten history.
Only problem, but I was expecting that, is that all subsequent commits have a different SHA1, so I'll/I'd have to push --force the result, and expect all of you guys to give up on your current repo, clone the updated repo somewhere else, and then transmit all your changes/commits to that new repo. A bit annoying...
But, OTOH, this also eliminates the 2 extra 'blame previous file' steps that we currently get everytime we're trying to blame a file that has an instance of a we::$user call (all of these ~99 files had their line endings corrupted by this wide-scale change using new software. Thank you, new software. Well, it's old and forgotten software since that day, of course.)
Are you okay with that, guys..?
I can't really expect the TortoiseGit committers to suddenly offer a -w parameter on their blame tool's settings UI, and if they do, I don't know if it'll be saved for all uses, etc, so I'd rather fix the repo myself.
I could also use the opportunity to rebase other problems in the history, but... Actually, I can't really think of anything else, so it's just this one shot, normally.
2267
Features / Re: New revs
« on November 16th, 2013, 10:51 PM »
rev 2324 -- more quick edit bug squashing! Hopefully all working now, eh.
3 files changed, 8 insertions(+), 17 deletions(-), 1.04 KiB
! Quick edit save was somehow broken by an earlier commit of Pete's, due to a wrongly placed parenthesis. I don't know if it had any influence over the contents of posts. Sorry if it did. (JSModify.php)
! And, Quick edit retrieval was also broken, this time by a recent commit of mine, where some [ signs were turned into their entity equivalent. I was under the impression that un_htmlspecialchars was enough, when I should have gone all the way through westr::entity_to_utf8. Let's not talk about that anymore. (QuoteFast.php)
@ Well, at least the Quick edit 'last post' bug fix from the last commit was proven to work. Yay. How strange that quick edit had so many bugs, and I didn't realize it until recently.
- Removed some remaining unused index params from wesql::insert calls. (ManageSmileys.php)
3 files changed, 8 insertions(+), 17 deletions(-), 1.04 KiB
! Quick edit save was somehow broken by an earlier commit of Pete's, due to a wrongly placed parenthesis. I don't know if it had any influence over the contents of posts. Sorry if it did. (JSModify.php)
! And, Quick edit retrieval was also broken, this time by a recent commit of mine, where some [ signs were turned into their entity equivalent. I was under the impression that un_htmlspecialchars was enough, when I should have gone all the way through westr::entity_to_utf8. Let's not talk about that anymore. (QuoteFast.php)
@ Well, at least the Quick edit 'last post' bug fix from the last commit was proven to work. Yay. How strange that quick edit had so many bugs, and I didn't realize it until recently.
- Removed some remaining unused index params from wesql::insert calls. (ManageSmileys.php)
2268
Features / Re: One theme to rule them all?
« on November 16th, 2013, 12:35 PM »
You never officially voted, though :P (Or maybe it's just because I don't like seeing the number '13'...)
One of the things that always bothered me is the difficulty to grasp differences between $theme and $options. (In SMF, I think that's $modSettings and $theme, respectively. Which is even sillier.)
I believe they should be merged together. I simply thought that it'd make more sense to get rid of $options (or rename $settings to $options because it's shorter, but it'd take time to get used to...), and merge them into settings at user load time.
I haven't started work on this yet though, mostly because I want to get it right. And if I ever miss the December 2013 window for first public alpha release, nobody will die for it. It'll just be released a month or two later, and with less predictable hassle for future users.
One of the things that always bothered me is the difficulty to grasp differences between $theme and $options. (In SMF, I think that's $modSettings and $theme, respectively. Which is even sillier.)
I believe they should be merged together. I simply thought that it'd make more sense to get rid of $options (or rename $settings to $options because it's shorter, but it'd take time to get used to...), and merge them into settings at user load time.
I haven't started work on this yet though, mostly because I want to get it right. And if I ever miss the December 2013 window for first public alpha release, nobody will die for it. It'll just be released a month or two later, and with less predictable hassle for future users.
2269
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 16th, 2013, 12:30 PM »Come to think of it - I am illiterate at this really - the use of objects, they also take up memory..so could Elkarte with so few globals in fact be using just as much memory as SMF due to them? Maybe some benchmark/resource meter for PHP will show this, I need to investigate further.
They are, however, very much welcome for complex code. And when it comes to micro-optimization, objects are not really worth it. I made many tests on the system object, for instance. Replacing $user_info['something'] (+ global) with we::$user['something'] (no global) had a tiny, tiny performance impact, but not enough to justify not using it.
In case it doesn't show... I hate globals :lol:
2270
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 16th, 2013, 12:27 PM »Very interesting! I have been lazy with this..
And with this script, then everyone can afford to be lazy again, in the future. They can just whip it up at some point, and fix everything they forgot to fix in one go.
The results I got..(differs from yours? could be my changed script..?
It's no problem, though.
In fact, I don't think adding tons of unused globals will have any performance impact. It's just, after all, an 'alias' to something that can be accessed through $GLOBALS['var'] just the same.
I do think, however, that it's best to save on filesize as much as possible. Every byte always counts, in the long run. Your mileage may vary.
My working copy had fewer than 542, because I'd already started removing a few ones manually, but not that much.
Also, I've fixed my script to output duplicate globals. It's a nice new feature.
I edited my post a few minutes ago, so you missed it, sorry.
Still missing: some support for create_function stuff and nested functions... (Yes, they're not taken into account.)
(is there some styling in the table tag in wedge btw? I added a few basic color schemes in Protendo,in a new table-like tag with headers and title as well, very useful for me at least :D ).
Having unused globals takes memory, right? Thats the main point in removing them?
oh, and I added some to the script to read the results better(for me) so it now just reads:
I'll leave it up to you, though!
2271
Features / Re: New revs
« on November 16th, 2013, 12:12 PM »
rev 2323 -- what's with the number 23 again?! I love this commit. It has so many fixes for details *important* to me.
8 files changed, 44 insertions(+), 46 deletions(-), 3.12 KiB
! This is my tentative fix for the infamous "quick edit just marked my post as unread, you silly!" bug... I'm pretty sure it's due to a settings caching problem (as I believe it only happens when the post you're editing is the latest in the forum *and* you've finished editing it within a minute of posting it in the first place), but I tried to follow the 'workflow' and it seemed flawless to me, so I'll instead use the message ID as the log date if the maxMsgID value is outdated at that point. (Subs-Post.php)
+ Added support for outputting Secure HTTP links in Aeva embedding. Rendered videos will still be unsecure, but the point is only to prevent https protocols from breaking the whole process. (ManageMedia3.php)
! Select boxes will now take the page height into account if it's shorter than the window height. Meaning, they'll try to avoid showing their dropdowns below them if there's more room above them, than between their bottom and the actual bottom of the body tag (not the window height). I know, it's complicated, but it magically fixes the skin selector in short pages with a responsive sidebar. That one ate at me over a long time, you can't imagine. Uh, no, actually not that much. (sbox.js)
* Instead of having stat bars span from 4px to 104px in size, I'll have them span from 5px to 100px, that's more than enough thank you. (Stats.php, Stats.template.php)
! Macros weren't being parsed if the skin.xml file was missing, even though they're located in the macros.xml file. (Subs-Cache.php)
* Removed flexbox and display: table code paths for Wilde linktrees. Seriously, it was too complicated for its own good. It works better as an inline-block, especially in iPhones. As a fix for broken gradients on multi-line linktrees, I've simply decided to drop all linktree gradients in responsive mode. Looks 80% as good, and doesn't 'break' when over 2 lines or more. (Wilde/extra.css)
* Improved translation. (PersonalMessage.french.php)
@ Re: quick edit bug. Considering that Wedge is using pretty much the same workflow as SMF here, I'd like to invite SMF developers to look into doing the same. Same comment as before: if you're unsure, ask me to do a pull request. I'll wait until I can confirm this is definitely fixed, though.
8 files changed, 44 insertions(+), 46 deletions(-), 3.12 KiB
! This is my tentative fix for the infamous "quick edit just marked my post as unread, you silly!" bug... I'm pretty sure it's due to a settings caching problem (as I believe it only happens when the post you're editing is the latest in the forum *and* you've finished editing it within a minute of posting it in the first place), but I tried to follow the 'workflow' and it seemed flawless to me, so I'll instead use the message ID as the log date if the maxMsgID value is outdated at that point. (Subs-Post.php)
+ Added support for outputting Secure HTTP links in Aeva embedding. Rendered videos will still be unsecure, but the point is only to prevent https protocols from breaking the whole process. (ManageMedia3.php)
! Select boxes will now take the page height into account if it's shorter than the window height. Meaning, they'll try to avoid showing their dropdowns below them if there's more room above them, than between their bottom and the actual bottom of the body tag (not the window height). I know, it's complicated, but it magically fixes the skin selector in short pages with a responsive sidebar. That one ate at me over a long time, you can't imagine. Uh, no, actually not that much. (sbox.js)
* Instead of having stat bars span from 4px to 104px in size, I'll have them span from 5px to 100px, that's more than enough thank you. (Stats.php, Stats.template.php)
! Macros weren't being parsed if the skin.xml file was missing, even though they're located in the macros.xml file. (Subs-Cache.php)
* Removed flexbox and display: table code paths for Wilde linktrees. Seriously, it was too complicated for its own good. It works better as an inline-block, especially in iPhones. As a fix for broken gradients on multi-line linktrees, I've simply decided to drop all linktree gradients in responsive mode. Looks 80% as good, and doesn't 'break' when over 2 lines or more. (Wilde/extra.css)
* Improved translation. (PersonalMessage.french.php)
@ Re: quick edit bug. Considering that Wedge is using pretty much the same workflow as SMF here, I'd like to invite SMF developers to look into doing the same. Same comment as before: if you're unsure, ask me to do a pull request. I'll wait until I can confirm this is definitely fixed, though.
2272
Features / Re: New revs
« on November 16th, 2013, 11:37 AM »
rev 2322 -- first batch of small fixes to Wedge. Attention SMF developers: some minor bugs are mentioned in there that are also in SMF 2.1 as far as I could see. If you can't find the bugs I'm referring to, please open a topic somewhere in the SMF board here, and I'll try to help. At worst, I'll do a pull request, but right now I'm focusing on Wedge issues, so it'll have to wait until I have more time.
24 files changed, 74 insertions(+), 91 deletions(-), 4.72 KiB
! weSkeleton->remove() was expected to return a success value. (Class-Skeleton.php)
! The new ban management code returned $row at one point, instead of $rowData. Blame Pete. (ManageBans.php)
! The 'do_empty_field' feature could never be disabled, due to a typo in the disabler code. Blame Pete. Still, nice feature, not sure why anyone would want to disable it. (Subs-Editor.php)
- pretty_synchronize_topic_urls doesn't provide a return value, no need to output it then... (ManageSettings.php)
! SMF 'bug': While session-related functions are not expected to return a value (it's undocumented, but the official examples provide values), I realized that the SMF implementation was flawed, such as providing a return value from an insert query, which is also undefined. Ahum. Cleaned it all up. (Load.php)
! SMF bug: $_COOKIE['guest_poll_vote'] has three bugs in one line: a 'count' ternary test that can perfectly be eliminated; an explode() used instead of implode() (!!), and the explode itself only has one parameter, since the comma was replaced with a period. (!!!) (Poll.php)
- SMF bug? Error lists in saveProfileFields and groupMembership2 parameters are never used. Also a typo in the documentation for these, hmm. (Profile.php, Profile-Modify.php)
- SMF bug: a beautiful unneeded line indeed... validateSession() never returns any value, and what do you think that test does anyway? (we::$is_member || validateSession()) -- if it's a member, it's true. If it's a guest, it calls the function, which then calls is_not_guest(), which generates an error. Thus skipping the line executed by that test, which... Generated an error. Well, yeah, sure, man, whatever you want. (Profile.php)
- SMF 'bug'? The first parameter in mergePosts() was optional, while the others weren't. (RemoveTopic.php)
! SMF bug: $entryname is used before it's declared. Wrong copy & paste, I guess. (Subs-Package.php)
! ...Which Pete then proceeded to reproduce in his plugin system. Along with an undeclared $path variable, a $dir variable missing its dollar sign (and thus considered as a constant), a $pluginsdir global renamed to '$plugins_dir', and another variable used before it's declared, $full_path, although in this case I think he meant to say $dir. Yeah, that one again... (Subs-Plugins.php)
! Nice one... A file_get_contents call using FILE_BINARY as a flag. Not only is it not necessary (file is considered binary by default), but it's a PHP 6-only flag. In code written at least 4 years ago. Real fun. (Class-Media.php)
* media_handler->resizeJpgImage() returned nothing, and that null return value was used and inverted to turn it into a true value. That's oh-so-badass. But it's also confusing, and fixed by simply forcibly return true. (Class-Media.php)
! show_prevnext() should have returned its output, rather than echoed it. Same for aeva_listFiles(), but as this one's more complicated, I'll just settle on echoing stuff, and then doing an explicit return ''. (Media.template.php)
- Unused function, getZippedfile(). Was buggy anyway. Debug code I'm sure. (Class-Zip.php)
! Undeclared global in aeva_moveAlbum(). It was only used if an error occurred, which I guess, never did happen. (Aeva-Gallery2.php)
- Unused globals. (install.php, Profile-Modify.php, Reports.php, Subs-Members.php)
- Duplicate globals. (ManageBoards.php, MoveTopic.php, Profile-Modify.php, Subs-Menu.php, Media.template.php)
! Missing global. Technically, it's a non-existing global, but it's also for a non-existing function, so who cares. (ManageMaintenance.php)
- Spacinazi, commenazi, etc. (PrettyUrls-Filters.php, Security.php)
24 files changed, 74 insertions(+), 91 deletions(-), 4.72 KiB
! weSkeleton->remove() was expected to return a success value. (Class-Skeleton.php)
! The new ban management code returned $row at one point, instead of $rowData. Blame Pete. (ManageBans.php)
! The 'do_empty_field' feature could never be disabled, due to a typo in the disabler code. Blame Pete. Still, nice feature, not sure why anyone would want to disable it. (Subs-Editor.php)
- pretty_synchronize_topic_urls doesn't provide a return value, no need to output it then... (ManageSettings.php)
! SMF 'bug': While session-related functions are not expected to return a value (it's undocumented, but the official examples provide values), I realized that the SMF implementation was flawed, such as providing a return value from an insert query, which is also undefined. Ahum. Cleaned it all up. (Load.php)
! SMF bug: $_COOKIE['guest_poll_vote'] has three bugs in one line: a 'count' ternary test that can perfectly be eliminated; an explode() used instead of implode() (!!), and the explode itself only has one parameter, since the comma was replaced with a period. (!!!) (Poll.php)
- SMF bug? Error lists in saveProfileFields and groupMembership2 parameters are never used. Also a typo in the documentation for these, hmm. (Profile.php, Profile-Modify.php)
- SMF bug: a beautiful unneeded line indeed... validateSession() never returns any value, and what do you think that test does anyway? (we::$is_member || validateSession()) -- if it's a member, it's true. If it's a guest, it calls the function, which then calls is_not_guest(), which generates an error. Thus skipping the line executed by that test, which... Generated an error. Well, yeah, sure, man, whatever you want. (Profile.php)
- SMF 'bug'? The first parameter in mergePosts() was optional, while the others weren't. (RemoveTopic.php)
! SMF bug: $entryname is used before it's declared. Wrong copy & paste, I guess. (Subs-Package.php)
! ...Which Pete then proceeded to reproduce in his plugin system. Along with an undeclared $path variable, a $dir variable missing its dollar sign (and thus considered as a constant), a $pluginsdir global renamed to '$plugins_dir', and another variable used before it's declared, $full_path, although in this case I think he meant to say $dir. Yeah, that one again... (Subs-Plugins.php)
! Nice one... A file_get_contents call using FILE_BINARY as a flag. Not only is it not necessary (file is considered binary by default), but it's a PHP 6-only flag. In code written at least 4 years ago. Real fun. (Class-Media.php)
* media_handler->resizeJpgImage() returned nothing, and that null return value was used and inverted to turn it into a true value. That's oh-so-badass. But it's also confusing, and fixed by simply forcibly return true. (Class-Media.php)
! show_prevnext() should have returned its output, rather than echoed it. Same for aeva_listFiles(), but as this one's more complicated, I'll just settle on echoing stuff, and then doing an explicit return ''. (Media.template.php)
- Unused function, getZippedfile(). Was buggy anyway. Debug code I'm sure. (Class-Zip.php)
! Undeclared global in aeva_moveAlbum(). It was only used if an error occurred, which I guess, never did happen. (Aeva-Gallery2.php)
- Unused globals. (install.php, Profile-Modify.php, Reports.php, Subs-Members.php)
- Duplicate globals. (ManageBoards.php, MoveTopic.php, Profile-Modify.php, Subs-Menu.php, Media.template.php)
! Missing global. Technically, it's a non-existing global, but it's also for a non-existing function, so who cares. (ManageMaintenance.php)
- Spacinazi, commenazi, etc. (PrettyUrls-Filters.php, Security.php)
2273
Off-topic / Re: A short script to remove unused, useless globals in PHP.
« on November 16th, 2013, 09:08 AM »
I fixed a small bug in which unused globals were reported in wrong situations.
Current results:
Elk - 159 declared, but unused globals. Good job. I suspect this is the work of TE using NetBeans :P
Wedge - 323 declared, but unused globals. I'll get started on this! (I removed the /other/ folder from results, because it's a large offender, and will never make it into the Wedge package.)
SMF 2.1 - 1231 declared, but unused globals. Baaaaad!
Current results:
Elk - 159 declared, but unused globals. Good job. I suspect this is the work of TE using NetBeans :P
Wedge - 323 declared, but unused globals. I'll get started on this! (I removed the /other/ folder from results, because it's a large offender, and will never make it into the Wedge package.)
SMF 2.1 - 1231 declared, but unused globals. Baaaaad!
2274
Off-topic / A short script to remove unused, useless globals in PHP.
« on November 16th, 2013, 01:03 AM »
As mentioned in the thoughts area, I quickly wrote a script to find unused variables declared with the global keyword in your PHP scripts.
Just copy this into any PHP file, drop it at the root of your website install, and have fun! It's not 100% tested, but it seems to be working fine, so I thought I'd share it, if only because SMF needs to do something about their 1600+ unused globals. I know they don't take much processing power or anything, but it just sounds lazy to me to leave globals that are unused.
Feel free to improve it as you like!
I'm releasing this under the WTF Public License, for what it's worth. It's not long enough to even bother with a MIT license, although I dream of using that one in the future... :P
Code: [Select]
To do the opposite operation (i.e. finding globals that weren't declared in a global keyword) isn't going to work with a short script -- unless you only look for the 'usual culprits' ($context, $txt, etc), in which case, yes, a short script is doable, I guess. But for that, I'm using HHVM. It's working fine, and is very smart about it. Only problem, it only works on Linux, so I had to install a VM to run that VM. Amusing. And install tons of dependencies. And go through many more steps of the program not wanting to run (the joys of permissions), then not wanting to start operating (the joys of parameters), then not wanting to complete (the joys of JSON bugs in Ubuntu.)
It took me several hours to go through it, but I found over 400 documented 'bugs' in Wedge, some of which I believe are in SMF/Elk as well, not that many though, but I'll try to document those I find important for them to fix.
:edit:
- Fixed most single-line function declarations.
- Added a 'duplicate global definitions' part. If you have a line that says global $txt, $context, $txt, the script will now tell you about it.
Just copy this into any PHP file, drop it at the root of your website install, and have fun! It's not 100% tested, but it seems to be working fine, so I thought I'd share it, if only because SMF needs to do something about their 1600+ unused globals. I know they don't take much processing power or anything, but it just sounds lazy to me to leave globals that are unused.
Feel free to improve it as you like!
I'm releasing this under the WTF Public License, for what it's worth. It's not long enough to even bother with a MIT license, although I dream of using that one in the future... :P
<?php
find_unused_globals(dirname(__FILE__));
function find_unused_globals($dir)
{
$i = 0;
$files = scandir($dir);
foreach ($files as $file)
{
if ($file == '.' || $file == '..' || $file == '.git' || $file == 'other')
continue;
if (is_dir($dir . '/' . $file))
{
find_unused_globals($dir . '/' . $file);
continue;
}
if (substr($file, -4) != '.php')
continue;
$php = file_get_contents($dir . '/' . $file);
preg_match_all('~\n(\t*)function ([\w]+)[^}\n]+\n\1(.*?)\n\1}~s', $php, $matches);
foreach ($matches[3] as $key => $val)
{
preg_match_all('~global (\$[^;]+);~', $val, $globs);
$globs[1] = isset($globs[1]) ? $globs[1] : array();
foreach ($globs[1] as $find_dupes)
{
$dupes = array_map('trim', explode(',', $find_dupes));
if (count($dupes) > count(array_flip(array_flip($dupes))))
echo 'Found duplicate globals in ', $file, ':', $matches[2][$key], ' -- ', $find_dupes, "\n";
}
preg_match_all('~\$[a-zA-Z_]+~', implode(', ', $globs[1]), $there_we_are);
$val = str_replace($globs[0], '', $val);
if (isset($there_we_are[0]))
foreach ($there_we_are[0] as $test_me)
if (strpos($val, $test_me) === false)
echo 'Unused global in ', $file, ':', $matches[2][$key], ' -- ', $test_me, "\n";
}
}
}To do the opposite operation (i.e. finding globals that weren't declared in a global keyword) isn't going to work with a short script -- unless you only look for the 'usual culprits' ($context, $txt, etc), in which case, yes, a short script is doable, I guess. But for that, I'm using HHVM. It's working fine, and is very smart about it. Only problem, it only works on Linux, so I had to install a VM to run that VM. Amusing. And install tons of dependencies. And go through many more steps of the program not wanting to run (the joys of permissions), then not wanting to start operating (the joys of parameters), then not wanting to complete (the joys of JSON bugs in Ubuntu.)
It took me several hours to go through it, but I found over 400 documented 'bugs' in Wedge, some of which I believe are in SMF/Elk as well, not that many though, but I'll try to document those I find important for them to fix.
:edit:
- Fixed most single-line function declarations.
- Added a 'duplicate global definitions' part. If you have a line that says global $txt, $context, $txt, the script will now tell you about it.
2275
Features: Miscellaneous / Re: Plugins
« on November 15th, 2013, 10:08 PM »
A question for those of you who've played with the plugin system more than I did, which is basically, everyone who released a plugin so far... :P
I'm currently 'fixing' code everywhere in Wedge, and found these undeclared variables in Subs-Plugin.php...
At the beginning, there's a $path on which empty() is tested. Obviously, it always returns true... So, I removed it. But I suspect there's something bigger behind.
Later, search for $full_path and you'll see the deleteFiletree function, which uses that variable, when it's not declared anywhere. I suspect Arantor meant to use $dir instead, as he's declaring $full_path later on, and then calling deleteFiletree with that variable as $dir. Any ideas..?
The line just below that uses yet another undefined variable, aka $entryname. Smells of copy & paste to me. I replaced it with if (!is_writable($dir)), because it makes the most sense. Nice.[1]
In uploadedPluginPrune, the $dir var is at one point called dir. Nice.
There's also a typo in the globals list in test_hooks_conflict... Nice.
It's surprising the plugin system worked so far without any errors, really... ;)
I'm currently 'fixing' code everywhere in Wedge, and found these undeclared variables in Subs-Plugin.php...
At the beginning, there's a $path on which empty() is tested. Obviously, it always returns true... So, I removed it. But I suspect there's something bigger behind.
Later, search for $full_path and you'll see the deleteFiletree function, which uses that variable, when it's not declared anywhere. I suspect Arantor meant to use $dir instead, as he's declaring $full_path later on, and then calling deleteFiletree with that variable as $dir. Any ideas..?
The line just below that uses yet another undefined variable, aka $entryname. Smells of copy & paste to me. I replaced it with if (!is_writable($dir)), because it makes the most sense. Nice.[1]
In uploadedPluginPrune, the $dir var is at one point called dir. Nice.
There's also a typo in the globals list in test_hooks_conflict... Nice.
It's surprising the plugin system worked so far without any errors, really... ;)
| 1. | Oh wait, that's funny... That code is actually copied from Subs-Package:deltree, and I checked out SMF 2.1, and guess what? They also have the $entryname bug... Except, Spuds documented it, but never fixed it. Well, easy enough guys: you probably can just remove it, and the slash... |
2276
Off-topic / Re: Doctor Who
« on November 15th, 2013, 05:09 PM »Oh, the usual. I use 'HTTPS Everywhere' in Firefox, so all YouTube urls are using https instead of http for me. The only difference is the protocol that prefixes the url. :)
Test:
Yup, it did get the https URL, and turned it into http at cache time. Is that okay with you..?
As for the TV movie... It's rather silly (if not awful) story-wise, but Paul McGann's performance is superb. Loved him in the few audio novels I've listened to, too.
If anything, his performance in here seems to me like a bit of a mix between Eccleston and Tennant. Maybe I'm mistaken, but... :P
2277
Features / Re: One theme to rule them all?
« on November 15th, 2013, 04:46 PM »
I forgot to mention one other 'advantage' of this technique...
One could add an option to a specific skin, saying something like this.
<option><var override="view_newest_pms_first">1</var></option>
That would still allow a 'theme' to have theme variables. I'd have to decide whether they can override non-overridable variables, though, and if their own setting can be overridden by users later on. Fun times... :lol:
Still, I think it's an interesting implementation I'm going to have.
One could add an option to a specific skin, saying something like this.
<option><var override="view_newest_pms_first">1</var></option>
That would still allow a 'theme' to have theme variables. I'd have to decide whether they can override non-overridable variables, though, and if their own setting can be overridden by users later on. Fun times... :lol:
Still, I think it's an interesting implementation I'm going to have.
2278
Features / Re: One theme to rule them all?
« on November 15th, 2013, 04:04 PM »
So, err... Suggestion!
- Get rid of the themes table entirely.
- Turn the settings table from a (variable, value) table into a (variable, value, can_override) table where 'can_override' is an ENUM ('never', 'yes', 'no'), set by default to 'never'. 'never' means that it's a generic setting for the forum, while 'yes'/'no' is a setting that depends on the user's taste. If the admin decides that they want the forum to be as free as possible, they'll set all of these variables to 'yes'.
- User can then access settings that are flagged as 'yes' from their profile, and change these settings. These are then stored in a special variable in their data field of the members table.
- User then loads $settings from the file cache; then loads the data field, unserializes the variable lists, and quite simply replaces existing $settings variables with their overrides. That way, for instance, $settings['view_newest_pms_first']'s value would be set by the user. (Well, technically it'd probably be in $options, but I have yet to decide whether it's best to split {db_prefix}settings variables between two arrays depending on their can_override=never status, or if they should be grouped together.
What do you think, guys..?
The only place where I see potential problems is enabling users to change $settings from their profile, which means centralizing all of the ex-theme variables into one file. (I think most of these are/were in ManageSettings.language.php and Themes.language.php, so it's doable.)
Also, managing 'special' variables like anything that's not a textbox or a checkbox, of course... But I can look into that.
Oh, and the fact that it makes my 'get rid of themes' chore a little bit longer than expected, but... Then again, I've seen worse delays ;)
- Get rid of the themes table entirely.
- Turn the settings table from a (variable, value) table into a (variable, value, can_override) table where 'can_override' is an ENUM ('never', 'yes', 'no'), set by default to 'never'. 'never' means that it's a generic setting for the forum, while 'yes'/'no' is a setting that depends on the user's taste. If the admin decides that they want the forum to be as free as possible, they'll set all of these variables to 'yes'.
- User can then access settings that are flagged as 'yes' from their profile, and change these settings. These are then stored in a special variable in their data field of the members table.
- User then loads $settings from the file cache; then loads the data field, unserializes the variable lists, and quite simply replaces existing $settings variables with their overrides. That way, for instance, $settings['view_newest_pms_first']'s value would be set by the user. (Well, technically it'd probably be in $options, but I have yet to decide whether it's best to split {db_prefix}settings variables between two arrays depending on their can_override=never status, or if they should be grouped together.
What do you think, guys..?
The only place where I see potential problems is enabling users to change $settings from their profile, which means centralizing all of the ex-theme variables into one file. (I think most of these are/were in ManageSettings.language.php and Themes.language.php, so it's doable.)
Also, managing 'special' variables like anything that's not a textbox or a checkbox, of course... But I can look into that.
Oh, and the fact that it makes my 'get rid of themes' chore a little bit longer than expected, but... Then again, I've seen worse delays ;)
2279
Features / Re: One theme to rule them all?
« on November 15th, 2013, 01:20 PM »
Avatar size isn't a theme option, it's a general setting, so that's okay.
Theme changing options, yep, that one's staying anyway... ;) It's in a different page, and it's handled differently.
Okay, I think I found out why I couldn't change member defaults. It's actually there in the code, but it doesn't execute on my local install. Something was broken in yesterday's update, and I haven't had time to look into it. It's just a JS issue, so don't bother with my remark about default options being f*cked up.
Theme changing options, yep, that one's staying anyway... ;) It's in a different page, and it's handled differently.
Okay, I think I found out why I couldn't change member defaults. It's actually there in the code, but it doesn't execute on my local install. Something was broken in yesterday's update, and I haven't had time to look into it. It's just a JS issue, so don't bother with my remark about default options being f*cked up.
2280
Off-topic / Re: Doctor Who
« on November 15th, 2013, 01:13 PM »
Re: HTTPS, I just added some code to Aeva so that it supports https links on any websites. Saving me the hassle of modifying all links ;)
Will only work when refreshing the site cache, though (e.g. add then remove a site in the site list through the admin.)
Not enabled here for now. Where can I find https links at youtube?
Will only work when refreshing the site cache, though (e.g. add then remove a site in the site list through the admin.)
Not enabled here for now. Where can I find https links at youtube?