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
1441
Plugins / Re: Birthdays
« on February 16th, 2014, 08:31 PM »
Regarding the other problem...
The birthday_email help popup uses a link with two entries that must be treated with a sprintf() call to replace the URL with the current one. It's silly.
I remember removing this feature long ago because it didn't make sense to do a sprintf on a feature used only a couple of times in SMF, so I removed it all, and removed the links. $txt['help_xmlnews_enable'] in German still has a link (Pandos, did you translate this file from scratch or did you take it from SMF...? Because this was removed so long ago..? Not that I'm judging!), and the Birthday plugin also still has it, I'm afraid.
The simple fix is to remove the link, ah ah... Or just replace the first % with <URL>, and remove the second because it's not used.
The birthday_email help popup uses a link with two entries that must be treated with a sprintf() call to replace the URL with the current one. It's silly.
I remember removing this feature long ago because it didn't make sense to do a sprintf on a feature used only a couple of times in SMF, so I removed it all, and removed the links. $txt['help_xmlnews_enable'] in German still has a link (Pandos, did you translate this file from scratch or did you take it from SMF...? Because this was removed so long ago..? Not that I'm judging!), and the Birthday plugin also still has it, I'm afraid.
The simple fix is to remove the link, ah ah... Or just replace the first % with <URL>, and remove the second because it's not used.
1442
Plugins / Re: Birthdays
« on February 16th, 2014, 08:18 PM »
Looking into this.
Look easy enough to fix.
In Birthday-Scheduled.php, at line 79, replace $emaildata['body'] with $body -- and tell me if this works better. ;)
Posted: February 16th, 2014, 08:17 PM
Look easy enough to fix.
In Birthday-Scheduled.php, at line 79, replace $emaildata['body'] with $body -- and tell me if this works better. ;)
1443
Plugins / [Plugin] Re: Facebook for Wedge
« on February 16th, 2014, 05:19 PM »Thanks, college and job has kept me busy but I do read and lurk around here often.Quote from Nao on February 16th, 2014, 02:45 PM Yay! Dragooon is out of lurk mode! Welcome back!
:)
1444
Plugins / [Plugin] Re: Facebook for Wedge
« on February 16th, 2014, 02:45 PM »
Yay! Dragooon is out of lurk mode! Welcome back!
1445
Archived fixes / Re: Pretty URLs causing 404s
« on February 16th, 2014, 01:58 PM »
Okay, so here's what happened...
*If your Wedge forum is installed in a sub-folder*
And
*If your server is Apache 2.2.16 or better*
Wedge is falling back to the FallbackResource /index.php line in the htaccess file.
However, /index.php is an absolute URI, and thus it redirects to your www root's index.php, rather than your Wedge root's.
I used to do index.php without the slash, but it actually uses the current requested path as relative path, instead of the htaccess file's path. What does it mean..? Well, doing /wedge/profile/me/ will attempt to load wedge/profile/me/index.php, instead of wedge/index.php...
The solution (which I applied to eolith's forum):
Well, err... As stupid as it sounds, just get rid of the FallbackResource lines. And the version testing lines. Basically, below the "# Pretty URLs" line, just keep this:
Code: [Select]
It obviously takes more time than just FallbackResource... :-(
Now it all comes down to the fact that I've been working on making Wedge create the htaccess file automatically.
If I can't get the Apache version number (eolith's server doesn't disclose it >_<), I'd have to print the above code instead of the easier FallbackResource. But what if you then upgrade your Apache server..? You could then use the faster FallbackResource, but Wedge wouldn't know. Well, I guess you could 'simply' remove your htaccess file from time to time, and Wedge would recreate it with the latest available code, but... Anyway.
Sometimes, a compromise has to be found between ease of use and ease of development... Hmm.
*If your Wedge forum is installed in a sub-folder*
And
*If your server is Apache 2.2.16 or better*
Wedge is falling back to the FallbackResource /index.php line in the htaccess file.
However, /index.php is an absolute URI, and thus it redirects to your www root's index.php, rather than your Wedge root's.
I used to do index.php without the slash, but it actually uses the current requested path as relative path, instead of the htaccess file's path. What does it mean..? Well, doing /wedge/profile/me/ will attempt to load wedge/profile/me/index.php, instead of wedge/index.php...
The solution (which I applied to eolith's forum):
Well, err... As stupid as it sounds, just get rid of the FallbackResource lines. And the version testing lines. Basically, below the "# Pretty URLs" line, just keep this:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* index.php [L]
</IfModule>It obviously takes more time than just FallbackResource... :-(
Now it all comes down to the fact that I've been working on making Wedge create the htaccess file automatically.
If I can't get the Apache version number (eolith's server doesn't disclose it >_<), I'd have to print the above code instead of the easier FallbackResource. But what if you then upgrade your Apache server..? You could then use the faster FallbackResource, but Wedge wouldn't know. Well, I guess you could 'simply' remove your htaccess file from time to time, and Wedge would recreate it with the latest available code, but... Anyway.
Sometimes, a compromise has to be found between ease of use and ease of development... Hmm.
1446
Archived fixes / Re: Weirdness
« on February 16th, 2014, 01:51 PM »
(Yes, it's solved. As my clicking the Solved button implied. :P)
1447
Off-topic / Re: Soundwave 2014
« on February 16th, 2014, 10:53 AM »Yea I know was just too lazy... I'll get to it ...looks like a real nice site!
I use FF most of time, got hooked on moz from Netscape Navigator days, yes I'm that old, bought their first version, cause I did not like Ie and still don't..
I'll have a look at your site, too, but right now I'm busy rebuilding my tab list, because Opera crashed on me and then decided that it didn't want to keep my tab list... -_-
1448
Importing into Wedge / Importing member fields into members.data?
« on February 16th, 2014, 01:11 AM »
This is mainly for @TE...
I'm looking into moving some {db_prefix}members columns into {db_prefix}members.data, where they'll be serialized and stored with other variables.
A few reasons for that...
- Well, there are 60 or 70 columns in that table... Not exactly EASY to browser through.
- I think I could save about a dozen (or at least half a dozen) columns by moving them to data.
- Basically, anything that (1) doesn't have an associated index, (2) doesn't need to be updated for anyone but the current user.
For now, I've moved 'mod_prefs' to data['modset'], and 'secret_question/secret_answer' to an array called secret_qa.
What I've been doing is: enter this into my new Upgrade script (not yet committed), where Wedge will get the existing entries, then convert them to data variables, and then remove the columns when it's done.
I guess it works fine if you're on a current install of Wedge: the upgrade script will pick it up, and then upgrade your table automatically.
But what if you're installing a new version..? The upgrade script won't run, because the database is in the new format, and it doesn't need to run. So... What to do?
(a) Leave the database with all these extra fields, because it's only annoying when browsing through phpMyAdmin, but 10 less fields won't make a big difference in either convenience or performance. (I'm not saying it won't; I'm giving you an opportunity to say whether you think it will.)
(b) Leave the database as is, at Wedge install time. Also set the database version to zero, basically... And let Wedge process it. But this means the import process needs to be done immediately after installing. Ouch... (Because, otherwise, Wedge will then start the upgrade process, and then delete the columns after it's gotten zero results on secret_* etc.)
(c) Add some code in the import script to make it possible to easily import an member field into the members.data field.
What do you think, guys..? (Especially Thorsten!)
I'm looking into moving some {db_prefix}members columns into {db_prefix}members.data, where they'll be serialized and stored with other variables.
A few reasons for that...
- Well, there are 60 or 70 columns in that table... Not exactly EASY to browser through.
- I think I could save about a dozen (or at least half a dozen) columns by moving them to data.
- Basically, anything that (1) doesn't have an associated index, (2) doesn't need to be updated for anyone but the current user.
For now, I've moved 'mod_prefs' to data['modset'], and 'secret_question/secret_answer' to an array called secret_qa.
What I've been doing is: enter this into my new Upgrade script (not yet committed), where Wedge will get the existing entries, then convert them to data variables, and then remove the columns when it's done.
I guess it works fine if you're on a current install of Wedge: the upgrade script will pick it up, and then upgrade your table automatically.
But what if you're installing a new version..? The upgrade script won't run, because the database is in the new format, and it doesn't need to run. So... What to do?
(a) Leave the database with all these extra fields, because it's only annoying when browsing through phpMyAdmin, but 10 less fields won't make a big difference in either convenience or performance. (I'm not saying it won't; I'm giving you an opportunity to say whether you think it will.)
(b) Leave the database as is, at Wedge install time. Also set the database version to zero, basically... And let Wedge process it. But this means the import process needs to be done immediately after installing. Ouch... (Because, otherwise, Wedge will then start the upgrade process, and then delete the columns after it's gotten zero results on secret_* etc.)
(c) Add some code in the import script to make it possible to easily import an member field into the members.data field.
What do you think, guys..? (Especially Thorsten!)
1449
Off-topic / Re: Soundwave 2014
« on February 16th, 2014, 12:59 AM »Madhat to Madman > I'll need to check these out later, I tried to register, but I got drafted before I could learn French, it was the second language in those days :)
1450
Features / Re: Language revs
« on February 15th, 2014, 11:37 PM »
[Commit revision 0e50a32]
Author: Nao (Signed-off)
Date: Sat, 15 Feb 2014 23:35:48 +0100
Stats: 2 files changed; +2 (insertions), -2 (deletions)
Author: Nao (Signed-off)Date: Sat, 15 Feb 2014 23:35:48 +0100
Stats: 2 files changed; +2 (insertions), -2 (deletions)
- Typo. Not mine! Translators, no need to bother. (Security)
1451
Archived fixes / Re: Problems with Edit Subscriber - Donation
« on February 15th, 2014, 09:38 PM »
Everything good, now..?
1452
Off-topic / Re: Soundwave 2014
« on February 15th, 2014, 09:34 PM »
http://fox.noisen.com
Trivia: I wrote Aeva Media 2 specifically so I could post these foxy old rock songs to my website. Or rather, I wrote stuff, and then I backported it into what I called AeMe 2.0.
Trivia: I wrote Aeva Media 2 specifically so I could post these foxy old rock songs to my website. Or rather, I wrote stuff, and then I backported it into what I called AeMe 2.0.
1453
Features / Re: Language revs
« on February 15th, 2014, 02:48 PM »
[Commit revision 3583baa]
Author: Nao (Signed-off)
Date: Sat, 15 Feb 2014 14:47:58 +0100
Stats: 12 files changed; +1 (insertion), -12 (deletions)
Author: Nao (Signed-off)Date: Sat, 15 Feb 2014 14:47:58 +0100
Stats: 12 files changed; +1 (insertion), -12 (deletions)
- Getting rid of version numbers in the last few language files that had these in their headers. Also fixing a ManagePaid string that was too hastily updated. (ManageBans, ManagePaid, Media, Security)
- And yes, it's looking like I'm playing with version numbers today, ain't I..?
1454
Features / Re: Plugin revs
« on February 15th, 2014, 02:45 PM »
[Commit revision 1aa3656]
Author: Nao (Signed-off)
Date: Sat, 15 Feb 2014 14:44:10 +0100
Stats: 3 files changed; +8 (insertions), -11 (deletions)
Author: Nao (Signed-off)Date: Sat, 15 Feb 2014 14:44:10 +0100
Stats: 3 files changed; +8 (insertions), -11 (deletions)
- github: Updated readme to match the recent webhook overhaul at GitHub. And the plugin rename I forgot to match in a comment. (github.php, readme.english.txt)
- Version number tweaks. (github/github.php, calendar/Calendar.php)
1455
The Pub / Re: Logo Madness
« on February 15th, 2014, 08:46 AM »
Bump for Xarcell (you have yet to explain yourself).