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 - Arantor
4681
Archived fixes / SMF bug 4870 (incorrectly capitalised month names)
« on February 29th, 2012, 02:56 PM »
I still don't get why SMF and Wedge don't just have the months set appropriately for language and use them rather than trying to mess around with ucwords...
4682
Bug reports / SMF bug 4851 (long posts being quoted can cause issues in Firefox)
« on February 29th, 2012, 02:52 PM »
Interesting solution. It's also potentially awkward if in a minor way - the post body is not trimmed as far as I can tell, which means there will be an extra space sent to the server. Which will then be 2 spaces if the post is edited... etc.
4683
Bug reports / SMF bug 4834 (no way to disable PM body being sent in notifications)
« on February 29th, 2012, 02:50 PM »
It can be added easily enough to the new PM settings page :)
4684
Archived fixes / SMF bug 4822 (composite strings cannot be translated properly)
« on February 29th, 2012, 02:44 PM »
The example given is the board index info center, where there is the case of 'x posts in y posts by z members' which can't be translated in components as originally given.
We've already done some stuff on this, tweaking strings, but there's plenty more to do yet.
We've already done some stuff on this, tweaking strings, but there's plenty more to do yet.
4685
Bug reports / SMF bug 4714 (replace GIFs with PNGs)
« on February 29th, 2012, 02:41 PM »
I can see some of the argument here - it's easier to restyle certain things when they're PNGs rather than GIFs, where animation is not a concern (e.g. standard UI stuff)
There are still quite a few GIFs hanging around (admin menu, some of the admin UI comes to mind) that probably should be replaced with PNGs - and nicer ones at that.
There are still quite a few GIFs hanging around (admin menu, some of the admin UI comes to mind) that probably should be replaced with PNGs - and nicer ones at that.
4686
Bug reports / SMF bug 4552 (inconsistencies with memberlist - search)
« on February 29th, 2012, 02:34 PM »
The search members page does not have sorting options, and has some other inconsistencies with its button use compared to other areas that do similar things.
4687
Archived fixes / SMF bug 4677 (star images need to be renamed)
« on February 29th, 2012, 02:25 PM »4688
Well, it's officially a plugin and has plenty to be done on it (no screenshots, sorry). Because of that, this post is going to be my todo list.
* SMF bug 4483 - SSI recent events doesn't handle future events, so a future events facility needs to be added.
* SMF bug 4483 - SSI recent events doesn't handle future events, so a future events facility needs to be added.
4689
Archived fixes / SMF bug 4956 (slash in cache key causes cache to fail)
« on February 29th, 2012, 02:17 PM »
As the example document indicates, this can actually affect Aeva so we do need to look into it, for cases where the file cache is used.
4690
Archived fixes / Fixed SMF bugs
« on February 29th, 2012, 02:16 PM »
As you may notice, there are quite a few(!) topics in this board now that represent SMF bugs that are suspected or known to exist in Wedge.
It's sort of a to-do list for me, and if no discussion results, I'll just merge the notice (with a note to confirm when it was fixed) into this thread to keep it tidy :)
It's sort of a to-do list for me, and if no discussion results, I'll just merge the notice (with a note to confirm when it was fixed) into this thread to keep it tidy :)
4691
Archived fixes / SMF bug 4920 (fixLongWords may not address items in quotes)
« on February 29th, 2012, 02:15 PM »
I don't know if this is still relevant to Wedge or not, knowing that the code has been changed slightly. Needs testing, but worth a bit of time to investigate as to whether it misbehaves or not. (Likelihood is that it does misbehave and will need fixing.)
4692
Bug reports / SMF bug 3702 (emptying file cache when changing cache settings)
« on February 29th, 2012, 02:12 PM »
I like the idea, needs to be nothing more than a checkbox that triggers clean_cache().
It might even be worth then removing the 'clean the file cache' button from the maintenance/routine tasks and leave it solely in caching. (Plus, that makes it searchable. The other maintenance tasks are not, IIRC, a state which probably should change sometime)
It might even be worth then removing the 'clean the file cache' button from the maintenance/routine tasks and leave it solely in caching. (Plus, that makes it searchable. The other maintenance tasks are not, IIRC, a state which probably should change sometime)
4693
Bug reports / SMF bug (untracked) where subscription end date is set to December 2005
« on February 29th, 2012, 02:08 PM »
http://www.simplemachines.org/community/index.php?topic=422730.0 and others.
There are several reports of this sort of behaviour, very little of them in common other than using paid subscriptions. Need to investigate why the date can be identified incorrectly when setting up the subscription (as it seems to be purely on SMF's side, and not incorrectly being set up by PayPal)
There are several reports of this sort of behaviour, very little of them in common other than using paid subscriptions. Need to investigate why the date can be identified incorrectly when setting up the subscription (as it seems to be purely on SMF's side, and not incorrectly being set up by PayPal)
4694
Bug reports / SMF bug 4961 (no index.php or .htaccess file when new attach folder made)
« on February 29th, 2012, 02:03 PM »
This is an interesting one, if you use a new folder to store attachments in.
I don't know if Aeva does anything like that when making a new album folder, but it might be interesting to note whether it does or not. If it does, the .htaccess file is going to be different.
In fact, now that I think about it, that's not a bad idea even for Aeva - provided there is a rule to determine between thumbnails and regular files: thumbnails do not need to be blocked from being served but regular attachments probably should (so they're pushed through the code layer instead)
I don't know if Aeva does anything like that when making a new album folder, but it might be interesting to note whether it does or not. If it does, the .htaccess file is going to be different.
In fact, now that I think about it, that's not a bad idea even for Aeva - provided there is a rule to determine between thumbnails and regular files: thumbnails do not need to be blocked from being served but regular attachments probably should (so they're pushed through the code layer instead)
4695
Bug reports / SMF bug (untracked?) re invalid transaction types/not handling cancellation
« on February 29th, 2012, 02:00 PM »
http://www.simplemachines.org/community/index.php?topic=455570.40
First up, I dispute the assertion that it is txn_type = subscr_cancel that causes it to fail, because it isn't. Following the logic as best I can (bearing in mind I glanced rather than studied in depth, vs what the IPN variables list says), the reason it fails where it does with the error it does is because of the check made in Subscriptions-PayPal.php's paypal_payment::isValid() routine.
Specifically, it's failing there because the email address given in the admin panel no longer matches the one PayPal was using (you know, like the reporter said), and fails at that hurdle. So we need to update isValid() to be able to return bool true for successful, or any other value as a text string to identify exactly what failed.[1]
There IS a fault also that txn_type = subscr_cancel isn't handled. The correct solution is to have an isCancelled() method, which checks the txn_type, and returns that to the subs handler. As I understand it, subscr_cancel is to cancel further subscription payments and as such all it has to do is flag the subscription as 'do not auto-renew'.
First up, I dispute the assertion that it is txn_type = subscr_cancel that causes it to fail, because it isn't. Following the logic as best I can (bearing in mind I glanced rather than studied in depth, vs what the IPN variables list says), the reason it fails where it does with the error it does is because of the check made in Subscriptions-PayPal.php's paypal_payment::isValid() routine.
Specifically, it's failing there because the email address given in the admin panel no longer matches the one PayPal was using (you know, like the reporter said), and fails at that hurdle. So we need to update isValid() to be able to return bool true for successful, or any other value as a text string to identify exactly what failed.[1]
There IS a fault also that txn_type = subscr_cancel isn't handled. The correct solution is to have an isCancelled() method, which checks the txn_type, and returns that to the subs handler. As I understand it, subscr_cancel is to cancel further subscription payments and as such all it has to do is flag the subscription as 'do not auto-renew'.
| 1. | Because that's half the battle: understanding what's actually wrong. |