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
1681
Archived fixes / Re: Not exactly a *bug* but...
« on January 31st, 2014, 10:26 PM »
Nope!
I've updated the language files for this plugin. Please redownload and tell me if it makes sense at all..!
I've updated the language files for this plugin. Please redownload and tell me if it makes sense at all..!
1682
Features / Re: Plugin revs
« on January 31st, 2014, 10:26 PM »
[Commit revision baab37a]
Author: Nao (Signed-off)
Date: Fri, 31 Jan 2014 22:26:11 +0100
Stats: 2 files changed; +29 (insertions), -0 (deletion)
Author: Nao (Signed-off)Date: Fri, 31 Jan 2014 22:26:11 +0100
Stats: 2 files changed; +29 (insertions), -0 (deletion)
- Missing strings in the Birthday plugin. Hopefully, these should be okay... (Birthday-Admin.english.php)
- Why wasn't that file translated to French at all..? Heresy! Qu'on lui tranche la tête ! (Birthday-Admin.french.php)
1683
Features / On the desirability of automatic updates..?
« on January 31st, 2014, 10:12 PM »
In reply to:
http://wedge.org/pub/bugs/8393/errors-when-checking-detailed-version-info/msg293427/#msg293427
Believe it or not, it's actually in my plans... :P
However, it might require some time.
Remember when Aeva used to update its sitelist by itself every day..? Well, for a long time I've had the same idea in mind for Wedge, but with technical difficulties (notably the amount of bandwidth needed to account for version checks.)
When I heard of Github Releases, I figured, is it possible to get a URL to these files, directly..? And yes, it is. By using their well-documented API, one can do up to 60 requests per hour (or 5000 if you provide an ID token) from a certain IP, so it's a piece of cake for Github to 'accept' a daily request from even thousands of different servers, checking whether a new release was posted.
If a release is available, I can then get the URL to the zip or tarball, and then proceed to warn the user about it. Should they choose not to ignore the update, they could press a button to automatically download it to the server, and optionally (if supported), unzip it somewhere. Then, if that works, either apply the files automatically (move from tmp folder to core, assets, etc.), or offer the user to log into their site by FTP, and move the files they want to move.
Technical problems:
- This doesn't account for deleted files... But the automatic upgrade script could account for these, though, and make sure to try and delete them, if they can be harmful to Wedge.
- I don't know much about unzipping tarballs. I think there are plenty of functions for that kind of action available in Wedge, though...
- What if the automatic update process fails? Will it break a forum..?
- What if users don't have correct PHP file permissions for unzipping, etc..?
http://wedge.org/pub/bugs/8393/errors-when-checking-detailed-version-info/msg293427/#msg293427
Believe it or not, it's actually in my plans... :P
However, it might require some time.
Remember when Aeva used to update its sitelist by itself every day..? Well, for a long time I've had the same idea in mind for Wedge, but with technical difficulties (notably the amount of bandwidth needed to account for version checks.)
When I heard of Github Releases, I figured, is it possible to get a URL to these files, directly..? And yes, it is. By using their well-documented API, one can do up to 60 requests per hour (or 5000 if you provide an ID token) from a certain IP, so it's a piece of cake for Github to 'accept' a daily request from even thousands of different servers, checking whether a new release was posted.
If a release is available, I can then get the URL to the zip or tarball, and then proceed to warn the user about it. Should they choose not to ignore the update, they could press a button to automatically download it to the server, and optionally (if supported), unzip it somewhere. Then, if that works, either apply the files automatically (move from tmp folder to core, assets, etc.), or offer the user to log into their site by FTP, and move the files they want to move.
Technical problems:
- This doesn't account for deleted files... But the automatic upgrade script could account for these, though, and make sure to try and delete them, if they can be harmful to Wedge.
- I don't know much about unzipping tarballs. I think there are plenty of functions for that kind of action available in Wedge, though...
- What if the automatic update process fails? Will it break a forum..?
- What if users don't have correct PHP file permissions for unzipping, etc..?
1684
Archived fixes / Re: Pretty URLs and Paths
« on January 31st, 2014, 08:47 PM »So after a fresh install on my local machine and my VPS everything appears right with the world. Paths are normal again and Pretty URLs is working. For me at least.
1685
Archived fixes / Re: Errors when checking detailed version info
« on January 31st, 2014, 07:15 PM »
This feature, I'm afraid, isn't available in Wedge.
I have no plans to provide version number comparisons for two reasons:
1/ It's easier and faster to just say, "Re-upload all of the latest package's /core into your /core folder." (A lot of thought was put into making that possible... :P)
2/ File headers in Wedge are built in a way that they don't need to be updated if nothing changes in them. i.e., (a) the copyright info only specifies the starting date (2010), and specifying a date isn't even necessary, but I thought the starting date was okay, (b) files have no version number, because, once again, you're expected to have all of the latest files anyway.
I have no plans to provide version number comparisons for two reasons:
1/ It's easier and faster to just say, "Re-upload all of the latest package's /core into your /core folder." (A lot of thought was put into making that possible... :P)
2/ File headers in Wedge are built in a way that they don't need to be updated if nothing changes in them. i.e., (a) the copyright info only specifies the starting date (2010), and specifying a date isn't even necessary, but I thought the starting date was okay, (b) files have no version number, because, once again, you're expected to have all of the latest files anyway.
1686
Off-topic / Re: Post count fever
« on January 31st, 2014, 05:31 PM »
When it comes to high post counts, you don't reach them with your hands but with your balls! 8-)
1687
Archived fixes / Re: Pretty URLs and Paths
« on January 31st, 2014, 05:30 PM »
If your site is still down, and it's a 'public' site, drop me a word here if you need someone to fix things for you.
1688
Archived fixes / Re: Pretty URLs and Paths
« on January 31st, 2014, 05:20 PM »
@Aaron Smith, I'm not 100% sure it's documented. However, it was (is?) my intention to automate this as well, so... I don't now.
The problem is that this htaccess file doesn't only contain references to pretty URLs (it's only at the end.) It also contains a lot of helpers that force some Apache or PHP settings if the script can't force them by itself.
What I COULD do, though, is, in the Pretty URLs admin page, have some explanation on why you need the htaccess there (if not found), and perhaps also use the opportunity to give more pointers for ngnix and lighttpd compatibility, for instance.
@Maxx> Yeah, I know, but I don't like getting errors during installation, because... Well, it gives you a feeling that it's gonna be a hell of a ride, right from the start... :lol:
Whereas the only reason I rewrote the installer was to make life easier for everyone; in the process, I broke stuff.
So, please confirm that the new installer fixes stuff. If you don't want to reinstall (which I'd understand!), just update these variables to the correct ones:
{db_prefix}settings.theme_url
{db_prefix}settings.images_url
{db_prefix}settings.smileys_url
{db_prefix}settings.avatar_url
{db_prefix}media_settings.data_dir_url
I think that should be all. Basically, it's everything in install.sql that's reset to {$boardurl} (just search for that in the file, including brackets.)
The problem is that this htaccess file doesn't only contain references to pretty URLs (it's only at the end.) It also contains a lot of helpers that force some Apache or PHP settings if the script can't force them by itself.
What I COULD do, though, is, in the Pretty URLs admin page, have some explanation on why you need the htaccess there (if not found), and perhaps also use the opportunity to give more pointers for ngnix and lighttpd compatibility, for instance.
@Maxx> Yeah, I know, but I don't like getting errors during installation, because... Well, it gives you a feeling that it's gonna be a hell of a ride, right from the start... :lol:
Whereas the only reason I rewrote the installer was to make life easier for everyone; in the process, I broke stuff.
So, please confirm that the new installer fixes stuff. If you don't want to reinstall (which I'd understand!), just update these variables to the correct ones:
{db_prefix}settings.theme_url
{db_prefix}settings.images_url
{db_prefix}settings.smileys_url
{db_prefix}settings.avatar_url
{db_prefix}media_settings.data_dir_url
I think that should be all. Basically, it's everything in install.sql that's reset to {$boardurl} (just search for that in the file, including brackets.)
1689
Features / Re: New revs
« on January 31st, 2014, 04:54 PM »
[Commit revision 09c96d3]
Author: Nao
Date: Fri, 31 Jan 2014 16:49:40 +0100
Stats: 1 file changed; +3 (insertions), -13 (deletions)
Author: NaoDate: Fri, 31 Jan 2014 16:49:40 +0100
Stats: 1 file changed; +3 (insertions), -13 (deletions)
- Fixed this huge installer bug that caused all paths to be wrong; it was simply due to a function being called too late in the process. Apologies to those affected. I guess a lot of support topics can be closed now, yay. (install.php)
- Removed some very, very old leftover code. If it makes you feel better (or me?), it's also still in SMF and Elk. Nobody seemed to bother that infile_css is just not used anywhere else in their codebase, so it happily lives on here, unaware that it's wasting your time on each install. (install.php)
1690
Importing into Wedge / Re: Importer tool
« on January 31st, 2014, 04:15 PM »
Anyway, here are my values...
theme_url
ttp://127.0.0.1/wedge/core/html
images_url
ttp://127.0.0.1/wedge/assets
smileys_url
ttp://127.0.0.1/wedge/assets/smileys
avatar_url
ttp://127.0.0.1/wedge/assets/avatars
(I removed the starting 'h' because otherwise it'd link to them. Now it reminds me of the good old 2ch days, ah ah...)
This is after a clean install + SMF reimport. (I'm thinking the import tool has nothing to do with this, so it should be on the other topic.)
Obviously, none of these are right, and I'm really, REALLY surprised that Wedge works so well with so many wrong paths... :lol:
Well, I guess I made it noob-friendly after all!
@Bun, well the good thing about this importer is that it's relatively forgiving with DB errors, but still, that's something to fix...
theme_url
ttp://127.0.0.1/wedge/core/html
images_url
ttp://127.0.0.1/wedge/assets
smileys_url
ttp://127.0.0.1/wedge/assets/smileys
avatar_url
ttp://127.0.0.1/wedge/assets/avatars
(I removed the starting 'h' because otherwise it'd link to them. Now it reminds me of the good old 2ch days, ah ah...)
This is after a clean install + SMF reimport. (I'm thinking the import tool has nothing to do with this, so it should be on the other topic.)
Obviously, none of these are right, and I'm really, REALLY surprised that Wedge works so well with so many wrong paths... :lol:
Well, I guess I made it noob-friendly after all!
@Bun, well the good thing about this importer is that it's relatively forgiving with DB errors, but still, that's something to fix...
1691
Features / Re: New revs
« on January 31st, 2014, 04:10 PM »
[Commit revision 9262e3f]
Author: Nao
Date: Fri, 31 Jan 2014 16:07:57 +0100
Stats: 2 files changed; +10 (insertions), -14 (deletions)
Author: NaoDate: Fri, 31 Jan 2014 16:07:57 +0100
Stats: 2 files changed; +10 (insertions), -14 (deletions)
- Fixing a minor error in the Reverse Proxy admin page. If you've previously supplied a list of IPs, make sure to visit the page and hit Submit again, so that your IPs can be stored in the new format. (ManageServer.php, QueryString.php)
- Now hard-coding template dir and URL into core/html. I'm not sure there'd be a reason to want to get them out of the core folder, really. I'll probably just eventually allow you to move the core folder somewhere outside, but even then, security-wise, does it matter? (QueryString.php)
1692
Archived fixes / Re: Pretty URLs and Paths
« on January 31st, 2014, 03:48 PM »
Okay, now that I've fixed the htaccess problem, I'm getting these 127.0.0.1 errors -- like, right now. Something's broken around here.
I'm *guessing* that Wedge was silently fixing these errors after installing, and that's why I didn't catch them when I rewrote the installer.
Sorry about that. I'm on it right now.
I'm *guessing* that Wedge was silently fixing these errors after installing, and that's why I didn't catch them when I rewrote the installer.
Sorry about that. I'm on it right now.
1693
Archived fixes / Re: Pretty URLs and Paths
« on January 31st, 2014, 03:46 PM »
I don't get where you get this address from.
The only place it shows up is in the 'dummy' Settings.php file for install purposes, but even this gets erased after installing.
Did you mess up with Settings.php at some point..?
Also, regarding PURL paths, I'm seeing nothing special on forums installed in the root, however I tried with one of my forums installed in a sub-folder, and it redirected me to the root one. So, I guess there's a bug in here somewhere... I'll have a look.
Nope... This was due to the fact that the forum's htaccess file wasn't correctly uploaded to its root. See, I have yet to move this one to the OriginalFiles.php code, so... No wonder it failed.
So, as a reminder:
If you're enabling pretty URLs on your forum, MAKE SURE that the .htaccess file is in your forum root!
Original location: /install/.htaccess
New location: /.htaccess
The only place it shows up is in the 'dummy' Settings.php file for install purposes, but even this gets erased after installing.
Did you mess up with Settings.php at some point..?
Also, regarding PURL paths, I'm seeing nothing special on forums installed in the root, however I tried with one of my forums installed in a sub-folder, and it redirected me to the root one. So, I guess there's a bug in here somewhere... I'll have a look.
Nope... This was due to the fact that the forum's htaccess file wasn't correctly uploaded to its root. See, I have yet to move this one to the OriginalFiles.php code, so... No wonder it failed.
So, as a reminder:
If you're enabling pretty URLs on your forum, MAKE SURE that the .htaccess file is in your forum root!
Original location: /install/.htaccess
New location: /.htaccess
1694
Archived fixes / Re: Log throws errors
« on January 31st, 2014, 03:39 PM »
Nothing here...
I tried enabling and disabling.
I tried entering comma-separated, and line-separated.
Never got any errors.
Can you post the data you have in that page..? Because it's probably very specific, I suppose.
Try replacing lines 535 through 539 (the ones that treat $_POST) with just this line:
Code: [Select]
Does it work now..?
I think it'll work. I think the 'bug' was related to supplying an empty block list where Wedge expected some contents. The quick fix would be to actually take the '' (two single quotes) at the end of line 535, and turn them into array() -- and voilà. But it still doesn't say why you didn't indicate any IPs in there... ;)
I tried enabling and disabling.
I tried entering comma-separated, and line-separated.
Never got any errors.
Can you post the data you have in that page..? Because it's probably very specific, I suppose.
Posted: January 31st, 2014, 03:27 PM
Try replacing lines 535 through 539 (the ones that treat $_POST) with just this line:
$_POST['reverse_proxy_ips'] = !empty($_POST['reverse_proxy_ips']) ? implode("\n", array_filter(array_map('trim', preg_split('~[\s,]+~', $_POST['reverse_proxy_ips'])))) : '';Does it work now..?
Posted: January 31st, 2014, 03:34 PM
I think it'll work. I think the 'bug' was related to supplying an empty block list where Wedge expected some contents. The quick fix would be to actually take the '' (two single quotes) at the end of line 535, and turn them into array() -- and voilà. But it still doesn't say why you didn't indicate any IPs in there... ;)
1695
Importing into Wedge / Re: MyBB Import
« on January 31st, 2014, 02:45 PM »
Pandos, I'm asking for the result of that query... not for the query itself... I'm not a SQL champ but I can still write those without help... I hope :lol:
Bun', I'm thinking this might be a problem with the mybb import script because the SMF version is working fine for everyone Herr...
At worst, you could always convert to SMF 2 and then use the converted again for Wedge...?
Bun', I'm thinking this might be a problem with the mybb import script because the SMF version is working fine for everyone Herr...
At worst, you could always convert to SMF 2 and then use the converted again for Wedge...?