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
2101
The Pub / Re: Minimum PHP version?
« on December 23rd, 2013, 04:07 PM »
Minimal requirement of 5.4 is a bit overkill, actually. The only 'nice' feature in 5.4 is that they now allow for the JavaScript array notation, i.e. $a = [1, 2, 3];
So this saves code, but you know what..? With Wedge's PHP caching, I can perfectly do it 'à la Wess', use array shortcuts, and then at cache time, replace any 5.4-arrays with 5.3-arrays. That sounds silly, but it's quite easy to do with my current codebase.
While 5.3 had two features that I wanted to use, and that are hard to 'emulate'[1]: closures and namespaces. However, it's not the panacea I thought it was...
- Namespaces are actually quite useless in a SMF codebase, AFAICT. Add 'namespace Wedge' to the top of index.php... Run it. It crashes. To be clear, any functions defined inside index.php are prefixed with Wedge\, and need to be called that way (such as Wedge\loadSource(...)) when called OUTSIDE of the Wedge namespace. That's fine by me... Except for something I didn't know before: if you include/require a file, it will NOT inherit the current namespace. So, the 'solution' is not only to include a namespace Wedge at the top of ALL files that Wedge uses, but also hardcode the Wedge\ prefix into any callback strings, and other things like that. That seems awfully overkill for the use I wanted to do of it (i.e. simplify a few function names while not risking name collisions with other libraries or the main website.)
In the end, I don't think I'll be using that, then. But the good news is, now you can use Laravel next to Wedge, or something... :P
- Closures ARE the panacea for me, for sure, but I've made a few benchmarks, and didn't notice any difference with creation_function(), even though it's supposed to be about 10 times faster. Not a big deal, though -- I spent years complaining that I couldn't use closures, I'm happy enough that I can use them now...! I've already rewritten Profile-Modify.php, it saves 500 bytes of escaped quotes (!!), much easier to debug, and at last code inside these functions is easily findable through a grep.
But PHP 5.4...? I'll probably use array shortcuts, for sure. I'll just backport them to PHP 5.3, and everyone will be happy.
(Oh, and also: getting rid of create_function() and generally any evals will also make my PHP minifier safer to use.)
So this saves code, but you know what..? With Wedge's PHP caching, I can perfectly do it 'à la Wess', use array shortcuts, and then at cache time, replace any 5.4-arrays with 5.3-arrays. That sounds silly, but it's quite easy to do with my current codebase.
While 5.3 had two features that I wanted to use, and that are hard to 'emulate'[1]: closures and namespaces. However, it's not the panacea I thought it was...
- Namespaces are actually quite useless in a SMF codebase, AFAICT. Add 'namespace Wedge' to the top of index.php... Run it. It crashes. To be clear, any functions defined inside index.php are prefixed with Wedge\, and need to be called that way (such as Wedge\loadSource(...)) when called OUTSIDE of the Wedge namespace. That's fine by me... Except for something I didn't know before: if you include/require a file, it will NOT inherit the current namespace. So, the 'solution' is not only to include a namespace Wedge at the top of ALL files that Wedge uses, but also hardcode the Wedge\ prefix into any callback strings, and other things like that. That seems awfully overkill for the use I wanted to do of it (i.e. simplify a few function names while not risking name collisions with other libraries or the main website.)
In the end, I don't think I'll be using that, then. But the good news is, now you can use Laravel next to Wedge, or something... :P
- Closures ARE the panacea for me, for sure, but I've made a few benchmarks, and didn't notice any difference with creation_function(), even though it's supposed to be about 10 times faster. Not a big deal, though -- I spent years complaining that I couldn't use closures, I'm happy enough that I can use them now...! I've already rewritten Profile-Modify.php, it saves 500 bytes of escaped quotes (!!), much easier to debug, and at last code inside these functions is easily findable through a grep.
But PHP 5.4...? I'll probably use array shortcuts, for sure. I'll just backport them to PHP 5.3, and everyone will be happy.
Posted: December 23rd, 2013, 04:04 PM
(Oh, and also: getting rid of create_function() and generally any evals will also make my PHP minifier safer to use.)
| 1. | Technically, a closure can be emulated pre-5.3, by detecting any function assignments (basically, anything 'function(' that isn't preceded by a bracket or things like that), and then turning the result into an escaped string inside a create_function(). Still, it requires properly handling use() keywords, I don't know if that can be done, AND, let's be clear: upgrading to PHP 5.3 is not ONLY about getting new features, it's also about making some things easier, e.g. PCRE 7.2 is required in Wedge, but up until PHP 5.3, a host could disable PCRE, so that was a problem for me. |
2102
Off-topic / Re: Happy Holidays !
« on December 23rd, 2013, 12:24 PM »
Merry Christmas everyone. I'll be gone to my family for a couple of days, unfortunately won't have time to code :cry:, but I'll soon be back with more commits presents!
Err... Okay, I'm only leaving tomorrow, but you know what it is... Code, code, code, losing track of time! :P
Err... Okay, I'm only leaving tomorrow, but you know what it is... Code, code, code, losing track of time! :P
2103
Features / Re: New revs
« on December 23rd, 2013, 12:15 PM »
[misc-fixes 434d117]
9 files changed, 106 insertions(+), 115 deletions(-), 3.13 KiB
* Improved htaccess to automatically detect the best alternative for pretty URLs. In short: enable mod_dir and mod_version, and then you can disable mod_rewrite. (root/.htaccess)
! Fixed a PHP 5.4 warning in contact list generation. (Maybe it's 5.3, I dunno, I skipped that one.) (Class-System.php)
! Fixed a bug in the smiley parser that caused it to always regenerate the smiley cache. Wedge is so fast, I didn't even notice that this was slowing it down. (Subs-BBC.php)
! Prevent running the installer on an existing copy of Wedge. Also fixed that particular detection process, and the error message not disabling the Continue button. (install.php)
* It's certainly much unneeded (for now), but I'd rather make sure the installer only loads pristine copies of the files. I'll need to test later. (install.php)
- Removed some browser version tests that were too old and unneeded. (Class-CSS.php)
* Improved poll builder layout. (Poll.template.php)
9 files changed, 106 insertions(+), 115 deletions(-), 3.13 KiB
* Improved htaccess to automatically detect the best alternative for pretty URLs. In short: enable mod_dir and mod_version, and then you can disable mod_rewrite. (root/.htaccess)
! Fixed a PHP 5.4 warning in contact list generation. (Maybe it's 5.3, I dunno, I skipped that one.) (Class-System.php)
! Fixed a bug in the smiley parser that caused it to always regenerate the smiley cache. Wedge is so fast, I didn't even notice that this was slowing it down. (Subs-BBC.php)
! Prevent running the installer on an existing copy of Wedge. Also fixed that particular detection process, and the error message not disabling the Continue button. (install.php)
* It's certainly much unneeded (for now), but I'd rather make sure the installer only loads pristine copies of the files. I'll need to test later. (install.php)
- Removed some browser version tests that were too old and unneeded. (Class-CSS.php)
* Improved poll builder layout. (Poll.template.php)
2104
The Pub / Re: Minimum PHP version?
« on December 23rd, 2013, 11:41 AM »
Okay, after 14 votes, I think it's safe to say that PHP 5.3 will be my choice. ;)
- I'll be implementing closures (anonymous functions) for cache_get_data (hopefully, as there are many occurrences to transform), anything that uses the awfully slow and ugly create_function(), and a few other places.
- I'll restore nl2br($stuf, false) functions that I'd replaced with regexes at one point for compatibility.
- I'll try to set up a Wedge namespace, so that I can (finally) safely use simpler function names without risk of any clashes.
For the anecdote, I wrote a closure in an array_map call just minutes ago -- but removed it, because I figured out a much faster solution.
Versus:
It may be slower, but isn't it beautiful? :P
- I'll be implementing closures (anonymous functions) for cache_get_data (hopefully, as there are many occurrences to transform), anything that uses the awfully slow and ugly create_function(), and a few other places.
- I'll restore nl2br($stuf, false) functions that I'd replaced with regexes at one point for compatibility.
- I'll try to set up a Wedge namespace, so that I can (finally) safely use simpler function names without risk of any clashes.
For the anecdote, I wrote a closure in an array_map call just minutes ago -- but removed it, because I figured out a much faster solution.
$in_lists = array_combine(array_keys($temp['lists']), array_fill(0, count($temp['lists']), $id_member));Versus:
$in_lists = array_map(function () use ($id_member) { return $id_member; }, $temp['lists']);It may be slower, but isn't it beautiful? :P
2105
The Pub / Re: Minimum PHP version?
« on December 23rd, 2013, 12:10 AM »
Fun fact. I switched my localhost to PHP 5.3.13, and mysqli no longer worked. Switched to 5.4.11, same.
Had to frigging backup, uninstall WampServer, delete everything, reinstall WS, restore my virtualhost data into the httpd.conf file, re-enable rewrite_module (I'm not sure why it's disabled by default........ made me lose 20 minutes), and then it started working again.
All in all: 2 hours used up. Hopefully not all servers are messed up like mine..... :P
Had to frigging backup, uninstall WampServer, delete everything, reinstall WS, restore my virtualhost data into the httpd.conf file, re-enable rewrite_module (I'm not sure why it's disabled by default........ made me lose 20 minutes), and then it started working again.
All in all: 2 hours used up. Hopefully not all servers are messed up like mine..... :P
2106
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 06:15 PM »
Great! Does this mean 5.3 was already there, but disabled...?
2107
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 03:38 PM »
Keep me posted ASAP! (Well, timezones permitting, of course!)
2108
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 02:06 PM »
Well... Then, it's time to determine if you're willing to switch hosts for Wedge if Charlottezweb won't update their site for you.
2109
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 01:59 PM »
Yes but upgrading PHP is not a trivial action, of course. Let's see what they have to say.
Which is why they may have decided to stick to 5.2. But since 5.2 was EOL'ed two years ago, it doesn't make sense.
In fact, I'm going to switch to 5.3 on my local install, if only for security.
Do you have any 'active' website, BTW? Because pplb.net only has demos on it, and the root is empty...
Also, did you do a phpinfo() on them, are you sure it's 5.2 on their server? Which one, 5.2.17?
Which is why they may have decided to stick to 5.2. But since 5.2 was EOL'ed two years ago, it doesn't make sense.
In fact, I'm going to switch to 5.3 on my local install, if only for security.
Do you have any 'active' website, BTW? Because pplb.net only has demos on it, and the root is empty...
Also, did you do a phpinfo() on them, are you sure it's 5.2 on their server? Which one, 5.2.17?
2110
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 01:08 PM »
Hmm, I spent a few minutes at Powerbob's host (charlottezweb):
- Apparently, it's a host with links to the SMF team (their forum is SMF, and it has members who come from SMF too),
- Their PHP 5 upgrade dates back to 2006, so they have no reasons not to switch to 5.3 (are you sure they never did?)
Considering that 5.2 was released in late 2006 and 5.3 in early 2009, if a host only follows PHP 5.2 releases (which stopped 2 years ago!), then they're clearly out of the game, i.e. they're not willing to do any more work to get things going, and they're only relying on an existing pool of installed websites that bring some monthly cash. I'm not saying it's a 'bad' thing (well, I'm not saying it's not wrong either), but if you're into building new websites, it may be best to do it on a server that's more up to date, because right now, there's a chance your server is, err... How can I say that..? Outdated, not only in terms of software versions, but also in OS patches, and other security fixes.
Security is important, especially because black hats will never stop trying to abuse security holes, and your website is only as safe as the weakest link in your whole hosting chain, i.e. if your OS is outdated you can get hacked even if you're on PHP 5.5, if your PHP is 4.x then you can get hacked even on a new OS, if your Apache is too old, same thing, etc.
Back in 2010, we decided to go for PHP 5.0+, when SMF was still in PHP 4.0 era. It was way overdue. Then a couple of years later, we thought it was safe to require PHP 5.2. But statistics aren't everything. Hosts should be playing the security game, not you. That's what you're paying them for.
So, it's the web software's duty to push for better server updates. Browser updates are harder to consider because it's pretty much impossible to require of your customers/visitors to change their browser from some IE crap to Chrome or something else, and that's who you want to deal with. They're important for you. Your host? You can always switch hosts if you're not happy with them.
I personally have only good things to say about OVH (which hosts Cynagames.com) and AlwaysData (which hosts Noisen and Wedge), two French companies with good prices and a good service. And their software versions are up to date, too!
- Apparently, it's a host with links to the SMF team (their forum is SMF, and it has members who come from SMF too),
- Their PHP 5 upgrade dates back to 2006, so they have no reasons not to switch to 5.3 (are you sure they never did?)
Considering that 5.2 was released in late 2006 and 5.3 in early 2009, if a host only follows PHP 5.2 releases (which stopped 2 years ago!), then they're clearly out of the game, i.e. they're not willing to do any more work to get things going, and they're only relying on an existing pool of installed websites that bring some monthly cash. I'm not saying it's a 'bad' thing (well, I'm not saying it's not wrong either), but if you're into building new websites, it may be best to do it on a server that's more up to date, because right now, there's a chance your server is, err... How can I say that..? Outdated, not only in terms of software versions, but also in OS patches, and other security fixes.
Security is important, especially because black hats will never stop trying to abuse security holes, and your website is only as safe as the weakest link in your whole hosting chain, i.e. if your OS is outdated you can get hacked even if you're on PHP 5.5, if your PHP is 4.x then you can get hacked even on a new OS, if your Apache is too old, same thing, etc.
Back in 2010, we decided to go for PHP 5.0+, when SMF was still in PHP 4.0 era. It was way overdue. Then a couple of years later, we thought it was safe to require PHP 5.2. But statistics aren't everything. Hosts should be playing the security game, not you. That's what you're paying them for.
So, it's the web software's duty to push for better server updates. Browser updates are harder to consider because it's pretty much impossible to require of your customers/visitors to change their browser from some IE crap to Chrome or something else, and that's who you want to deal with. They're important for you. Your host? You can always switch hosts if you're not happy with them.
I personally have only good things to say about OVH (which hosts Cynagames.com) and AlwaysData (which hosts Noisen and Wedge), two French companies with good prices and a good service. And their software versions are up to date, too!
2111
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 12:23 PM »
Yes, I think I'll be going for PHP 5.3
I'm mostly convinced by the fact that PHP 5.2 is End of Life, its last version was released over 2 years ago, and even 5.3 is nearing End of Line (July 2014), and will no longer receive any bug fixes, only security fixes, apparently. Going for 5.4-only was a joke in my poll, because it's clearly not widespread enough, but 5.3 seems more realistic to me.
Also, I can afford that because Wedge is imported from SMF, so if someone can't use it, they can still remain on SMF, or switch to ElkArte or Protendo for instance. Really, not a big deal.
Myself, I guess I'm more concerned with pushing things forward.
My main concern right now, though, is to ensure that all of the faithful Wedge followers can install it when it's available. I seem to remember that back in the private alpha days (a year ago), someone had trouble with a feature that was 5.3-only, but I couldn't find that discussion. Powerbob is a regular on this forum, he's been here for years, and I wouldn't like to leave him on the side of the road. Every regular in here is important to me, it's important that they're satisfied with Wedge, and that they can end up using it on their forums, because that's what they've been waiting for for so long.
My second concern is that even if I went for 5.3... What is the minimum 5.3 version I should adopt? For PHP 5.2, it was 5.2.4 because of the support of \h and a few other goodies. For PHP 5.3, what would be the acceptable version? 5.3.0? Or much higher? According to w3techs, a safe version to use would be 5.3.3, because it's still in use by 21% of all 5.3 installs. But 5.3.2 is also used by 3% of them, should I drop these from my support list without even reading through the 5.3 changelogs? I don't know, honestly...
I'm mostly convinced by the fact that PHP 5.2 is End of Life, its last version was released over 2 years ago, and even 5.3 is nearing End of Line (July 2014), and will no longer receive any bug fixes, only security fixes, apparently. Going for 5.4-only was a joke in my poll, because it's clearly not widespread enough, but 5.3 seems more realistic to me.
Also, I can afford that because Wedge is imported from SMF, so if someone can't use it, they can still remain on SMF, or switch to ElkArte or Protendo for instance. Really, not a big deal.
Myself, I guess I'm more concerned with pushing things forward.
My main concern right now, though, is to ensure that all of the faithful Wedge followers can install it when it's available. I seem to remember that back in the private alpha days (a year ago), someone had trouble with a feature that was 5.3-only, but I couldn't find that discussion. Powerbob is a regular on this forum, he's been here for years, and I wouldn't like to leave him on the side of the road. Every regular in here is important to me, it's important that they're satisfied with Wedge, and that they can end up using it on their forums, because that's what they've been waiting for for so long.
My second concern is that even if I went for 5.3... What is the minimum 5.3 version I should adopt? For PHP 5.2, it was 5.2.4 because of the support of \h and a few other goodies. For PHP 5.3, what would be the acceptable version? 5.3.0? Or much higher? According to w3techs, a safe version to use would be 5.3.3, because it's still in use by 21% of all 5.3 installs. But 5.3.2 is also used by 3% of them, should I drop these from my support list without even reading through the 5.3 changelogs? I don't know, honestly...
2112
The Pub / Re: Minimum PHP version?
« on December 22nd, 2013, 09:42 AM »
Powerbob, can't you ask your host for php 5.3 support..? What is your host, anyway?
2113
The Pub / Re: Minimum PHP version?
« on December 21st, 2013, 05:52 PM »
It's hard to be in the group that forces people to upgrade because they also get criticized for it. But yes if frameworks like Laravel can be popular, there's no reason to believe it will be the death of Wedge.
Simply, couple of years ago, someone complained that they couldn't install Wedge because of php limitations and I seriously wanted to help with that. I'm afraid I might 'lose' the opportunity for Wedge to be on great forums that are on slightly less thrilling hosts.
Simply, couple of years ago, someone complained that they couldn't install Wedge because of php limitations and I seriously wanted to help with that. I'm afraid I might 'lose' the opportunity for Wedge to be on great forums that are on slightly less thrilling hosts.
2114
The Pub / Re: Minimum PHP version?
« on December 21st, 2013, 04:26 PM »
Actually when we switched to php 5 only, it was so we could remove all legacy code. ;)
Not the case here, although I could remove magic quotes. Yay.
Not the case here, although I could remove magic quotes. Yay.
2115
The Pub / Minimum PHP version?
« on December 21st, 2013, 02:20 PM »
I figured I could ask that.
I've often met situations where I wanted to turn silly create_function() calls into closures, but this morning -- more frustration for me. I figured I could rewrite the cache handler to basically link cache_get_data and cache_put_data together by putting the regeneration code into a closure, which would then allow me to easily benchmark regeneration times, instead of just cache storage times.
So, this just means-- "I'd really like to use PHP 5.3 in Wedge."
But then, it also means that a third of all servers won't be able to install Wedge. IIRC, Wedge.org runs on PHP 5.5 or something, and my Wampserver has PHP 5.3, so it's not a problem for me, and generally speaking I think that the '5.2 third' portion is likely to be a portion of servers that have either been abandoned, or just not maintained very often, and thus more likely to cause configuration problems when using Wedge.
In short:
- 5.2 is the current version required by Wedge. PHP 5.2 is great.
- 5.3 is a bit better, not THAT much better, but I've been wanting to do closures for years, just like I'm doing in JavaScript. Going for PHP 5.3 won't make my life much easier, and won't make Wedge better. But still, I'd like to look into it.
The competition usually has a required PHP version < 5.3: xenForo has 5.2 IIRC, SMF has something like 4.0 (lulz, but they're trying to account for website upgrades, while I'm betting on website importing), even newer software like esoTalk only requires 'PHP 5'. Vanilla, I think has a requirement of 5.1. The only 'popular' PHP package I know of that requires PHP 5.3 is Laravel, and it's a framework, not a forum package. So, both logic and statistics tell me to keep using 5.2, although maybe, well... Maybe it's okay, hence this poll.
Remember, Wedge is striving to remain compatible with as many browsers as possible; but when it comes to the server behind it, this is usually something that most serious webmasters CAN control, and personally, I like being in charge!
I've often met situations where I wanted to turn silly create_function() calls into closures, but this morning -- more frustration for me. I figured I could rewrite the cache handler to basically link cache_get_data and cache_put_data together by putting the regeneration code into a closure, which would then allow me to easily benchmark regeneration times, instead of just cache storage times.
So, this just means-- "I'd really like to use PHP 5.3 in Wedge."
But then, it also means that a third of all servers won't be able to install Wedge. IIRC, Wedge.org runs on PHP 5.5 or something, and my Wampserver has PHP 5.3, so it's not a problem for me, and generally speaking I think that the '5.2 third' portion is likely to be a portion of servers that have either been abandoned, or just not maintained very often, and thus more likely to cause configuration problems when using Wedge.
In short:
- 5.2 is the current version required by Wedge. PHP 5.2 is great.
- 5.3 is a bit better, not THAT much better, but I've been wanting to do closures for years, just like I'm doing in JavaScript. Going for PHP 5.3 won't make my life much easier, and won't make Wedge better. But still, I'd like to look into it.
The competition usually has a required PHP version < 5.3: xenForo has 5.2 IIRC, SMF has something like 4.0 (lulz, but they're trying to account for website upgrades, while I'm betting on website importing), even newer software like esoTalk only requires 'PHP 5'. Vanilla, I think has a requirement of 5.1. The only 'popular' PHP package I know of that requires PHP 5.3 is Laravel, and it's a framework, not a forum package. So, both logic and statistics tell me to keep using 5.2, although maybe, well... Maybe it's okay, hence this poll.
Remember, Wedge is striving to remain compatible with as many browsers as possible; but when it comes to the server behind it, this is usually something that most serious webmasters CAN control, and personally, I like being in charge!