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
1516
Bug reports / Re: SMF bug 3009 (duplicate meta information)
« on February 21st, 2013, 09:26 PM »
Quote
(Heck, it it were me, I'd just dismiss the meta description tag entirely... :^^;:)
That is not an option.
Quote
160 bytes is usually a bit short for a regular conversation
Well, that's the limit Google uses normally. And I guarantee that it is easier to market Wedge if it has decent SEO (at least, decent given the nature of the beast!) out of the box.
Posted: February 21st, 2013, 06:56 PM

Regarding the hellip, using a straight ... would be better there if possible. Maybe an option for westr::cut?
1517
Features / Re: Quote to PM
« on February 21st, 2013, 06:57 PM »
I did wonder whether it should be a plugin, but it could be a useful core feature too :)
1518
Archived fixes / Re: Minor Quick Edit Bug
« on February 21st, 2013, 06:55 PM »
It never got fixed.

I fixed most of the issues by re-forcing westr::safe with ENT_QUOTES on some of the places, notably quick reply, full reply in some other cases, but I forgot that.

As far as I'm concerned we should just be forcing it on save regardless. Safe by default, and damn the byte cost for once.
1519
Features / Re: New revs
« on February 21st, 2013, 06:11 AM »
(11 files, 3KB)

Revision: 1938
Author: arantor
Date: 21 February 2013 05:10:34
Message:
! Quick one from me. Not properly tested though I don't think I broke anything. Includes free harmonisation of forum_name to FORUMNAME and removing a duplicate language string from index + Post into EmailTemplates since there's the only time it's really used, most of the time it was already loaded and for the one time it wasn't, no biggie. (ManageMail.php, ManageNews.php, Profile-Actions.php, ScheduledTasks.php, Subs-Post.php, language files: index, Post, EmailTemplates)

! Scheduled emails looked like they were using very much the wrong language strings. Not tested but using a variable you did set up previously as opposed to a loop castoff has to be better. (Probably remains in SMF though.) (ScheduledTasks.php)
----
Modified : /trunk/Sources/ManageMail.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/Profile-Actions.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs-Post.php
Modified : /trunk/Themes/default/languages/EmailTemplates.english.php
Modified : /trunk/Themes/default/languages/EmailTemplates.french.php
Modified : /trunk/Themes/default/languages/Post.english.php
Modified : /trunk/Themes/default/languages/Post.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
1520
Features / Re: New revs
« on February 21st, 2013, 05:45 AM »
(5 files, 2KB)

Revision: 1937
Author: arantor
Date: 21 February 2013 04:43:48
Message:
! SMF bug 4947 - improper validation of $reservedVars. (Profile-Modify.php)

! SMF bug 4811 - legacy function call not needed. (RepairBoards.php)

! For some reason my JavaScript for the anti spam Q&A page started doing template weirdness. (Admin.template.php)

! SMF bug 4974 - misleading advice for regexp validation on CPF. (Help language file)

! SMF bug 4968 - register hook should expose more useful variables. (Subs-Members.php)

----
Modified : /trunk/Sources/Profile-Modify.php
Modified : /trunk/Sources/RepairBoards.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Themes/default/Admin.template.php
Modified : /trunk/Themes/default/languages/Help.english.php

@ It isn't often I check up on SMF bugs that need fixing, but I'm going to try and do it a bit more often. I do not check whether they are fixed in SMF or not, merely whether they are fixed in Wedge mainline.
1521
Features / Re: Micro feature: escliteral type
« on February 21st, 2013, 05:27 AM »
Nope. It would mysql_real_escape_string the vars.

Consider a query I fixed today, which is what prompted it.

Code: [Select]
wesql::query('
DELETE FROM {db_prefix}bans
WHERE ban_type = {string:id_member}
AND ban_content IN ({array_string:users})',
array(
'id_member' => 'id_member',
'users' => $users,
)
);

The whole reason for id_member is so that 'id_member' gets passed into the string with proper escaping. Except on original commit I actually forgot the variable injection. This sort of thing is used in a lot of places in Wedge.

I'm proposing it would become:
Code: [Select]
wesql::query('
DELETE FROM {db_prefix}bans
WHERE ban_type = {escliteral:id_member}
AND ban_content IN ({array_string:users})',
array(
'users' => $users,
)
);
1522
Archived fixes / Re: SMF bug 4859 (Text limit not necessarily enforced properly)
« on February 21st, 2013, 02:19 AM »
All committed in r1936. Bye bye fulltext. Hello huge posts. Not a massive revert if we so desire but I'm comfortable without worrying about it personally.

Bad me, I should have waited for feedback but this is something I was eager to get done.
1523
Bug reports / Re: SMF bug 3009 (duplicate meta information)
« on February 21st, 2013, 02:18 AM »
OK, so I've set this to 160 characters as that seems to be a sane guideline figure from what I can tell.

There is no meta description for the board index or home page yet. Not sure how best to approach that yet either.
Posted: February 21st, 2013, 12:30 AM

Committed in r1936.
1524
Features / Re: New revs
« on February 21st, 2013, 02:17 AM »
(19 modified, 1 deleted, 5KB)

Revision: 1936
Author: arantor
Date: 21 February 2013 01:16:57
Message:
! Big home for text is big. (install.sql, ManagePosts.php)

! Spacinazi. Yup, I got there first! (ManageNews.php)

! Commenazi. (ManageSmileys.php)

! Trim meta descriptions to 160 characters. (Display.php, MessageIndex.php)

! Remove likes when a message is permanently removed. (RemoveTopic.php)

! Remove the likes a member made when they are deleted. (Subs-Members.php)

! Missing parameter in clean-up query. (Subs-Members.php)

- Death to the weird-ass hidden parameter introduced in 2006 that outside of a bugfix, no-one appeared to *ever* have encountered in any form whatsoever. (Search2.php, Search.template.php)

- Death to teh fulltexts. (ManageMaintenance.php, ManageSearch.php, ManageSearch.template.php, detailed-version.php, SearchAPI-Fulltext.php, language files: Help, ManageMaintenance, Search)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/ManageMaintenance.php
Modified : /trunk/Sources/ManageNews.php
Modified : /trunk/Sources/ManagePosts.php
Modified : /trunk/Sources/ManageSearch.php
Modified : /trunk/Sources/ManageSmileys.php
Modified : /trunk/Sources/MessageIndex.php
Modified : /trunk/Sources/RemoveTopic.php
Modified : /trunk/Sources/Search2.php
Deleted : /trunk/Sources/SearchAPI-Fulltext.php
Modified : /trunk/Sources/Subs-Members.php
Modified : /trunk/Themes/default/ManageSearch.template.php
Modified : /trunk/Themes/default/Search.template.php
Modified : /trunk/Themes/default/languages/Help.english.php
Modified : /trunk/Themes/default/languages/ManageMaintenance.english.php
Modified : /trunk/Themes/default/languages/ManageMaintenance.french.php
Modified : /trunk/Themes/default/languages/Search.english.php
Modified : /trunk/Themes/default/languages/Search.french.php
Modified : /trunk/other/xml/detailed-version.php
Modified : /trunk/root/install.sql
1525
Features / Micro feature: escliteral type
« on February 21st, 2013, 02:10 AM »
So, we have escaped strings, e.g. we use {string:blah} and that's going to look for a variable 'blah'. Surprisingly often that will turn out to be 'blah' in the parameters, e.g. we needed the content to be as is, but merely string escaped for queries.

So I'm wondering, is it worth having the case where we define {escliteral:string} to have 'string' appear in the query properly escaped?

Primarily wondering what the coders are likely to make of it... Nao, Dragooon, live, thoughts? It's just a convenience feature really.
1526
Bug reports / Re: SMF bug 4938 (attachment maintenance can fall foul of the security timeout)
« on February 21st, 2013, 12:31 AM »
OK, so I was thinking about this earlier while out walking.

It occurred to me that it could be done by way of setting each stage to be carried out as a form of imperative scheduled task. That way it wouldn't necessarily require the admin to be present.

Needs more investigation.
1527
Archived fixes / Re: SMF bug 4859 (Text limit not necessarily enforced properly)
« on February 21st, 2013, 12:04 AM »
Oh now I remember why I didn't do it. You can't use a fulltext index on mediumtext fields, though if you were using InnoDB you couldn't anyway[1] and invariably a custom index would outperform fulltext anyway.

I was going to remove fulltext but for some reason I didn't - http://wedge.org/code/6838/removing-fulltext-indexes/ - but it seems my concern was primarily about memory usage.

It does not reserve the full size per row (as proven with drafts which have always been mediumtext anyway but never had to be searchable)

So unless there are any objections, I am going to proceed with this, and drop fulltext indexes anyway - even if InnoDB supports them going forward, it doesn't on the size of field we're using and a custom index is better anyway. Note that fulltext is not even enabled by default anyway so no qualms about that.
 1. It's an option in MySQL 5.6.
1528
Bug reports / Re: Profile field values lost when edited
« on February 20th, 2013, 11:53 PM »
There is a *perceived* problem with more queries. And to a degree there is a valid issue - if you have to make too many queries per page, something is wrong.

I don't usually have an issue when the number caps at about 20 per page when it's a complex page.[1] Or it's got lots of plugins. But I see issues when you get into 50+ queries per page, like vB 5 betas that make 60 just to get a single topic. Without modifications.
 1. 20 queries to get the front page of a fresh WP install is another matter.
1529
Bug reports / Re: Profile field values lost when edited
« on February 20th, 2013, 10:52 PM »
Quote
Yes it is a bit of an odd setup. When I was first looking for the values I was looking for profile field tables; putting it into themes is bizarre!
It has two practicalities.

Firstly, there's no additional queries to get the data for the user's profile area - it will automatically be loaded for the user.

Secondly, the themes table already holds per-user information of indeterminate amounts, as that's where preferences are set. Given its heritage as a mod-that-became-a-core-feature-because-the-original-author-later-became-a-dev, it is not really surprising.
Quote
Maybe a rough and dirty 'fix' then is to make it clear that the values cannot be amended once used. At the minute the help says:
No, it should really be done properly or not at all. It's on the list.
1530
Bug reports / Re: Mini-menu implementation
« on February 20th, 2013, 08:13 PM »
Quote
I don't know how you can keep up, AND do long speeches at Elk and SM boards...!
Practice and good time management ;)
Quote
Yes, which is why reuploading the file will fix the problem, but not emptying the cache... Because the original CSS/JS files will keep their original date ID.
But surely if you empty the cache you're forcing everything to be rebuilt from whatever the current 'master' is?
Quote
Although I think we should consider changing some of our reply/quote/whatever icons.
How about I look through Fugue and see if I can find some suitable replacements?
Quote
I don't understand what you're trying to say about the ternary fix...
Anyway, that one is just me trying to push short code into a single line when it's spread over 4 lines... That's just me.
Shorter code is not always ideal. Had I written that from the off, it probably would have been a ternary but originally it was a two-line affair and became a four line affair; refactoring to a ternary just never occurred to me at that point.

Also, the issue I'm referring to is there should be a space either side of the : in the ternary and there isn't ;)
Quote
This would basically allow us to show the action menu on any screen width, and then ensure that smaller screens get an action menu when it's too much for them.

I don't know if I'm going to implement this immediately, but what do you think of it..?

I think the main (only?) drawback to this method is that if JS is disabled on your browser -- you don't get to see any option at all... This is why Wedge currently shows the two most important settings (quote and modify) as regular links, not part of the menu.
I'd argue that the Quote/Modify buttons serve a higher purpose than merely being available if there's no JS - they also exist to be prominent and easily accessible being the most common actions you're going to perform.

But if they can remain accessible without being forced into the action menu, that should be sufficient.