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
1861
Other software / Re: Discussing Elkarte on wedge.org
« on January 19th, 2013, 02:55 PM »
Really up to you. They seem generally happy doing their own thing - not even jumping into the Elkarte thread on sm.org that was started by the SMF team (and it got some less than enthusiastic responses)
1862
Features / Re: New revs - Public comments
« on January 19th, 2013, 02:45 PM »
Great minds think alike :)
Actually, yeah, it would be better to pass things in through an array - in fact you could pass in everything other than message that way if you really wanted.
Actually, yeah, it would be better to pass things in through an array - in fact you could pass in everything other than message that way if you really wanted.
1863
Other software / Re: Discussing Elkarte on wedge.org
« on January 19th, 2013, 02:44 PM »1864
Other software / Re: Discussing Elkarte on wedge.org
« on January 19th, 2013, 02:18 PM »
I gave emanuele the fix I originally did for Wedge since I still care about SMF... Any changes other than that (e.g. As public discussion) are fair game, no? You did discuss the fix where you pointed out issues in it and IIRC that was public.
They don't have SVN access either.
They don't have SVN access either.
1865
Features / Re: New revs
« on January 19th, 2013, 06:06 AM »
(1 file, 1KB)
Revision: 1859
Author: arantor
Date: 19 January 2013 05:06:06
Message:
! A variable was getting cleared too early which could cause errors. (ManageBoards.php)
----
Modified : /trunk/Sources/ManageBoards.php
Revision: 1859
Author: arantor
Date: 19 January 2013 05:06:06
Message:
! A variable was getting cleared too early which could cause errors. (ManageBoards.php)
----
Modified : /trunk/Sources/ManageBoards.php
1866
Features / Re: Ordering sticky topics
« on January 19th, 2013, 05:53 AM »
Well, that's the thing, it's very much one of those 'once it's done, it's done' operations, both for pinning and ordering.
1867
Features / Re: Ordering sticky topics
« on January 19th, 2013, 05:42 AM »
That's pretty much what I concluded, yes :)
And now it's committed and done, so I can move onto the next thing :)
Also, get better soon!!
And now it's committed and done, so I can move onto the next thing :)
Also, get better soon!!
1868
Features / Re: New revs
« on January 19th, 2013, 05:32 AM »
(10 files, 19KB)
Revision: 1858
Author: arantor
Date: 19 January 2013 04:31:11
Message:
! A few more $scripturl removals. (MessageIndex.php)
! I didn't really want to commit this yet but other changes to Display.php forced my hand somewhat (I don't like partial commits of files or any such nonsense.) So here's the first code that sets up for Disemvowelling bad users' posts. It relies on a new parameter being available to the bbc parser, but one I've talked about doing before, it's just that now I'm actually doing it, though in a very slightly different manner to before. The vowel stripping is particularly nasty and I don't have a smarter way of doing it at this stage. (Display.php, Subs-BBC.php)
! Bug in previous/next topics not taking into account pinned topics, ordered or otherwise. (Display.php)
! Allow for reordering of pinned topics. Not all of this was necessarily in the best places, but it seems to make some kind of sense. (JSModify.php, MessageIndex.php, Pin.php, Post2.php, Post.template.php, language files: index, Post, Errors)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/JSModify.php
Modified : /trunk/Sources/MessageIndex.php
Modified : /trunk/Sources/Pin.php
Modified : /trunk/Sources/Post2.php
Modified : /trunk/Sources/Subs-BBC.php
Modified : /trunk/Themes/default/Post.template.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Post.english.php
Modified : /trunk/Themes/default/languages/index.english.php
Revision: 1858
Author: arantor
Date: 19 January 2013 04:31:11
Message:
! A few more $scripturl removals. (MessageIndex.php)
! I didn't really want to commit this yet but other changes to Display.php forced my hand somewhat (I don't like partial commits of files or any such nonsense.) So here's the first code that sets up for Disemvowelling bad users' posts. It relies on a new parameter being available to the bbc parser, but one I've talked about doing before, it's just that now I'm actually doing it, though in a very slightly different manner to before. The vowel stripping is particularly nasty and I don't have a smarter way of doing it at this stage. (Display.php, Subs-BBC.php)
! Bug in previous/next topics not taking into account pinned topics, ordered or otherwise. (Display.php)
! Allow for reordering of pinned topics. Not all of this was necessarily in the best places, but it seems to make some kind of sense. (JSModify.php, MessageIndex.php, Pin.php, Post2.php, Post.template.php, language files: index, Post, Errors)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Sources/JSModify.php
Modified : /trunk/Sources/MessageIndex.php
Modified : /trunk/Sources/Pin.php
Modified : /trunk/Sources/Post2.php
Modified : /trunk/Sources/Subs-BBC.php
Modified : /trunk/Themes/default/Post.template.php
Modified : /trunk/Themes/default/languages/Errors.english.php
Modified : /trunk/Themes/default/languages/Post.english.php
Modified : /trunk/Themes/default/languages/index.english.php
1869
Features / Re: Ordering sticky topics
« on January 19th, 2013, 05:19 AM »
Well, here's the quandary. I could have it so that mods can pin/unpin topics (sticky/unsticky for those not yet familiar with Wedge terms) but not be able to reorganise them, or I could have it so that people who can pin/unpin can also arrange them too.
I'd assume that anyone who can pin can also arrange them, and that's how I wrote the code, but it's really no hardship to change it, it's two lines of existing code (one for the menu item, one for the permissions check in the main function) then just adding a new permission.
I'm happy with that to be honest.
There is a fringe issue that I'm not yet sure whether it bugs me enough. I'll relate it and see what folks think. Essentially, when you pin a new topic, it won't necessarily go to the bottom of the list of pinned topics - it will typically go one above bottom, if you've already organised them in the past, that is. All bets are off if you haven't previously reorganised them at all.
Do I care about this or do I forcibly ensure that a given pinned topic ends at the bottom of the list? I'm inclined not to care at this time of day about it (it's not a *huge* deal, it just means writing a query to bump everything up when pinning one, and another to unbump when unpinning, but there's several places this has to happen)
Admins before now didn't have the choice whether to care, it was just a mash of topics in whatever order. I'm assuming now that they'll fix it to place it wherever they want, or if they don't care, it'll just be wherever it ended up before.
In other news... happy <festival day>, have some screenshots.
I'd assume that anyone who can pin can also arrange them, and that's how I wrote the code, but it's really no hardship to change it, it's two lines of existing code (one for the menu item, one for the permissions check in the main function) then just adding a new permission.
I'm happy with that to be honest.
There is a fringe issue that I'm not yet sure whether it bugs me enough. I'll relate it and see what folks think. Essentially, when you pin a new topic, it won't necessarily go to the bottom of the list of pinned topics - it will typically go one above bottom, if you've already organised them in the past, that is. All bets are off if you haven't previously reorganised them at all.
Do I care about this or do I forcibly ensure that a given pinned topic ends at the bottom of the list? I'm inclined not to care at this time of day about it (it's not a *huge* deal, it just means writing a query to bump everything up when pinning one, and another to unbump when unpinning, but there's several places this has to happen)
Admins before now didn't have the choice whether to care, it was just a mash of topics in whatever order. I'm assuming now that they'll fix it to place it wherever they want, or if they don't care, it'll just be wherever it ended up before.
In other news... happy <festival day>, have some screenshots.
1870
Archived fixes / Re: Previous/next topics don't work properly
« on January 19th, 2013, 04:31 AM »
OK, I think I fixed this and will commit in my next commit. I think I was the one who broke this originally, years ago :o
1871
Archived fixes / Re: Previous/next topics don't work properly
« on January 19th, 2013, 02:53 AM »
OK, just to really confuse matters, my terminology is wrong. The left link is actually 'previous', not next, and the right link is actually 'next' in the code terms. At least I know which query does which now...
1872
Archived fixes / Previous/next topics don't work properly
« on January 19th, 2013, 02:37 AM »
The query logic is actually very broken - but it's taken me this long to notice it. Part of the problem is understanding what desired behaviour is and what we actually get.
Against a board of non pinned posts, there's no problem, and there's never been a problem. But when you cross the pinned barrier, it all goes to hell.
For example, 'When can I download Wedge?' is the most replied to pinned topic in /pub/, last reply Jan 12th.
The 'next' topic is the one next chronologically on from it, which is about half way down the board, while the 'previous' topic is quite rightly the previous sticky topic.
Now I pick an unpinned topic from earlier. The 'next' topic is correct, but the 'previous' topic is the pinned topic that happens to be the most recent one prior to the date of the topic in question, if that makes sense (I picked a post from mid December, which pre-dates When can I download Wedge's last reply, but is after Read This First's last reply)
And this is even before I apply non-1 values to is_pinned >_<
It sort of depends on what the behaviour should be, I'm guessing when you reach the most recent topic in a given board that is non pinned, the next one *should* be the oldest/bottom-most pinned topic?
As in, previous/next are effectively traversal up the message index as presented?
Against a board of non pinned posts, there's no problem, and there's never been a problem. But when you cross the pinned barrier, it all goes to hell.
For example, 'When can I download Wedge?' is the most replied to pinned topic in /pub/, last reply Jan 12th.
The 'next' topic is the one next chronologically on from it, which is about half way down the board, while the 'previous' topic is quite rightly the previous sticky topic.
Now I pick an unpinned topic from earlier. The 'next' topic is correct, but the 'previous' topic is the pinned topic that happens to be the most recent one prior to the date of the topic in question, if that makes sense (I picked a post from mid December, which pre-dates When can I download Wedge's last reply, but is after Read This First's last reply)
And this is even before I apply non-1 values to is_pinned >_<
Posted: January 19th, 2013, 02:32 AM
It sort of depends on what the behaviour should be, I'm guessing when you reach the most recent topic in a given board that is non pinned, the next one *should* be the oldest/bottom-most pinned topic?
As in, previous/next are effectively traversal up the message index as presented?
1873
The Pub / Re: Looking for volunteers to test the Wedge private alpha!
« on January 19th, 2013, 12:43 AM »
Nah, there's nothing inappropriately forceful there at all. I can understand where you're coming from. It doesn't help that I find myself feeling *very* protective of Wedge at present for reasons that I'm sure are fairly clear, it's stuff I shouldn't have to be doing, and I don't have to do it, but if I don't, I don't see who else is... >_<
1874
The Pub / Re: Looking for volunteers to test the Wedge private alpha!
« on January 19th, 2013, 12:32 AM »
I haven't even really looking at the applications thus far, if I'm honest. I just saw that a bunch of people had posted, I just reiterated what I'd already said.
The last few days I've been wrangling with a lot of stuff, some of which has been laid bare >_<
But a lot of what I've said still stands - I would personally rather have people who contribute along the way and demonstrate a commitment to contribute rather than who request access to test it as it was at a fixed milestone; if you're just interested in seeing the software... we run it right here. There's little that an alpha could show you that you can't see here, because pretty much every new feature that's in Wedge and not in SMF is visible here, either from screenshots or it's user facing.
If you're seeing it as 'just replying to every thread', you've missed the point somewhat, I feel. It's not about gaining trust, it's demonstrating some commitment to actually contribute meaningful feedback - as you may or may not have noticed, already several people who got access didn't bother to reply much, not even to say 'hey, still here just busy'.
I deliberately go out and ask for feedback as new things get added, to gauge what users want and how beneficial it will be to them.
The last few days I've been wrangling with a lot of stuff, some of which has been laid bare >_<
But a lot of what I've said still stands - I would personally rather have people who contribute along the way and demonstrate a commitment to contribute rather than who request access to test it as it was at a fixed milestone; if you're just interested in seeing the software... we run it right here. There's little that an alpha could show you that you can't see here, because pretty much every new feature that's in Wedge and not in SMF is visible here, either from screenshots or it's user facing.
If you're seeing it as 'just replying to every thread', you've missed the point somewhat, I feel. It's not about gaining trust, it's demonstrating some commitment to actually contribute meaningful feedback - as you may or may not have noticed, already several people who got access didn't bother to reply much, not even to say 'hey, still here just busy'.
I deliberately go out and ask for feedback as new things get added, to gauge what users want and how beneficial it will be to them.
1875
Features / Re: Template edits
« on January 18th, 2013, 07:46 PM »- I think that message lists are an excellent candidate for a 'special case' where we inject a mini-skeleton into the game. This doesn't have to be complicated...
But yes, the principle of being a mini skeleton is important.
- As for hooks, Wedge already has _before, _after and _override blocks available for anyone wanting to add some template code to an existing block. I don't see anything that can be done through hooks but not through block overrides...?
- I'd love to be able to say "we can also print a block to a temporary output buffer, then send it to a hook for post-processing, then send that buffer to the proper output buffer". It even makes a lot of sense, come to think of it... But I'm afraid that performance might be hurt by this process, especially in the Display pages (if we end up implementing the mini-skeleton.)