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
6526
Features / Re: Public & Private Groups?
« on September 7th, 2011, 09:00 PM »
It's not been stated in big letters but a search for importer does show it mentioned in the FAQs in several topics ;)
6527
Off-topic / Re: MySQL Optimization question
« on September 7th, 2011, 08:55 PM »
Once you've got that numeric field, with an index, you should find life gets easier. After that, the next thing to do is to EXPLAIN the queries to see how MySQL attempts to process the query.
6528
Off-topic / Re: MySQL Optimization question
« on September 7th, 2011, 07:37 PM »
Need more specifics. How variable are the field contents? Or is it literally "iPad", "Desktop" and so on?

Reason for asking is that the datatype seems wrong, namely that if the contents aren't that variable and are reasonably discrete, you should switch it to a smallint (if there's more than 255 variations) or tinyint (if there's less) because it'll save space per row, then you just index that field, which will be a lot faster and more useful in terms of indexing (indexing varchar fields are hard work based on content)
6529
Off-topic / Re: MySQL Optimization question
« on September 7th, 2011, 07:19 PM »
What's the content of device? I know it's a varchar (20) but more info on its content would really help.
6530
Features / Re: Template skeleton!
« on September 7th, 2011, 06:39 PM »
Quote
I don't know, I thought new themes used default images by default... (i.e. if no images folder was found, the default images folder was used.) Isn't that the case...?
No, it isn't. A new theme as created by the admin panel is a copy of all folders from the theme's directory, plus index.template.php.


OK, idiot question time, because I'm not seeing how the one thing that is quite important to me is covered.

I see there is the sidebar_feed item inside the sidebar. How do I go about adding a new item in sidebar, preferably doing it before sidebar_feed, and doing it dynamically because I don't want it every page?
6531
Features / Re: Help page as FAQ page
« on September 7th, 2011, 02:07 PM »
Quote
I'm not sure what you guys plan on doing with the help page
We removed it entirely. It's been a matter of some considerable debate both for us and for SMF during their migration to it being a placeholder page.

Fact is, it's not that commonly used.

For most sites, it's also incomplete, as I don't know any mods[1] that actually puts information into the help area. Even the largest mods do not do that (SimpleDesk talked about doing it but by the time we got round to considering it, SMF had already pruned their own.)

All things considered, it's actually more practical in a lot of ways not to bother, of which the two most important are:
1. If the interface needs an explanation in how to use it, it's broken and should be fixed. Glossing over the problem with a manual is all well and good but you should only need the manual in specialised/rare circumstances, not general ones.

2. Most users can navigate round to post something, and in every single community I've ever seen that offers any kind of features other than the most absolute basic, people talk to each other and ask each other questions, which is a subtle way of getting a community interacting.

There is a third quite important reason too:
3. Most people don't read the manual. I know I already mentioned this, but it is quite important, important enough for me to bring it up again. sm.org, for example, is replete with information. Many aspects[2] are well documented but yet most people just don't even try and find that information.


Far better would be for us to not bother doing anything like that in the core and making it a good mod where its functionality can be consolidated rather than us doing a half-assed job in the core. Especially since that allows the administrator and similar contributors to set the tone and content to suit a given community.
 1. Other than the one whose sole purpose is to reinstate the original help pages.
 2. Other than the ones that are really quite broken and/or unintuitive, such as permission profiles in 2.0.
6532
Plugins / Re: Converting WedgeDesk
« on September 7th, 2011, 02:55 AM »
Well, the hooks part was pretty easy to change over, the DB stuff was almost entirely automated, I'm currently working through the templates to convert them to Wedge coding but that's a bit tedious, and I'm also rewriting a number of things as I go, like making use of weToggle instead of half-baked hacky versions of the same thing.

Getting it all to play nicely is why I wanted to do it this way, so I know when I start using the proper add-on manager, that I make absolutely sure I'm hunting down add-on manager bugs and not WedgeDesk ones.

Right now there is still a fair bit that's fragile, but it is coming together and the parts I have tweaked (like the screenshot, putting the relationships and notifications blocks into the sidebar) look the better for it. I'm debating dropping some of the existing layout and heading towards a bit like the normal topic display does, with the poster info on the right... but we'll see, that's not finalised yet.
6533
Features / Re: Public & Private Groups?
« on September 7th, 2011, 01:12 AM »
Quote
Speaking of, will Wedge allow us to port over SMF database information such as member information?
Yes, there is already an importer of such data, I'm fairly sure that was covered in the FAQs somewhere though...
6534
Features / Re: Template skeleton!
« on September 7th, 2011, 12:32 AM »
Quote
I mean, why would a mod modify the theme URL right in the middle of the page? Did SMF implement that after they noticed the variable being abused?
Oh... ooh, I looked at this again. The code is a little bit different to how it was when I documented it - it's now much clearer as to what it's doing, as opposed to my creative interpretation back then (a year ago!)

If a theme indicates that the default images should be used, and that the theme is indicating that it uses the default templates, reset the theme dirs to the master default directory. I don't recall a theme ever setting it, however, not even the default theme. I see no reason, really, why that actually needs to remain.

Mind you, there is some creative variable abuse inside SMF, like $scripturl, which can actually be redefined after creation depending on circumstance, so don't take it for granted that it is what you will expect it to be...
6535
Plugins / Re: Converting WedgeDesk
« on September 6th, 2011, 10:10 PM »
And SD 2.0 made great use of hooks, so much so that it was far more compatible than 1.0 was (out of curiosity I tried it, heheheh)
6536
Features / Re: Template skeleton!
« on September 6th, 2011, 10:10 PM »
No, the long standing question of themes and mods being compatible.

For the record, file edits are going to be supported and with no less functionality than on SMF (I.e. Install on custom themes, as well as updating custom themes later on if you install mods) but the preferred method will be hooks simply because it's cleaner and more likely to be compatible.
6537
Plugins / Re: Converting WedgeDesk
« on September 6th, 2011, 06:02 PM »
Hmm, I think ticket layout is mostly done now. (Attachments... hmm, haven't done that, is going to be broken in a variety of fun ways.)
6538
Features / Re: Template skeleton!
« on September 6th, 2011, 05:38 PM »
Quote
Never said it did
*ahem*
Quote
Then again, how do we do that without eval()?
That's just me being facetious at this point because I don't think there is a good way to do it that doesn't involve either eval, or using fun functions everywhere.

There is where you're getting into semantics. As far as I'm concerned, #content is used to represent the content, and thus it encapsulates all of it. Surely, then, the ideal place is the layer that surrounds the page content, which would be the body layer?

I see what you're getting at, and you're probably right. As I said, a lot of this stuff is mostly hypothetical from my perspective; I don't make themes, I only know how I'd want to interact with things as a modder, and do so in a way that doesn't foul up themes.
6539
Features / Re: Template skeleton!
« on September 6th, 2011, 05:15 PM »
Quote
"extract the following string, make sure it's a valid function, and we call it.
Yes... but it absolutely does not require eval at all ;)

I thought the whole point was that the skeleton would dictate which parts to call and in what order, nor intermixing the order with the content therein...
Quote
I don't know... Something that basically tells Wedge whether to start a layer or a sub-template at that point. Or it could simply recognize whether <footer> is stand-alone function, or a layer... Etc.
How is that different to now, then? A layer is an array in the template list, a standalone function is a string item.
6540
Features / Re: Template skeleton!
« on September 6th, 2011, 05:07 PM »
Quote
Then again, how do we do that without eval()?
Variable functions are a truly wonderful thing. :P

Code: [Select]
$skeleton = "header, sidebar, content, footer";

$list = explode(',', $skeleton);
foreach ($list as $item)
{
  $item = trim($item);
  $item();
}

It's faster than eval though naturally not as fast as calling the function directly, but you don't really have a lot of choice at this point, and it would go through the normal template execution flow anyway, meaning that the buffer process is essentially unchanged, since to a degree this is how template layers themselves work.

The one thing that seems critical to me is that the list of items can be manipulated, and ideally more easily than fudging around with a string; that's one thing I like about the current setup is that you can add new items cleanly to an existing content area.
Quote
I renamed template_header() and template_footer() to start_output() and finish_output()
Works for me.