Wedge

That's one of the many refinements that can be added, that when setting up the hooks, we test for file existence prior to registration.

I didn't particularly want to add it to loadAddonSource though since I didn't really see a need for it (much as loadSource doesn't)

*nods* Yeah, it's a valid concern and one that did need to be reiterated, but that I'm firmly against putting too much  support in for version checking.

In the case of PHP and MySQL, there are some functions whose behaviour varies between versions and can't readily be detected in any other fashion. (I mean, in some cases, you can imply a PHP version through looking for a function that only exists in a given release, but it's not particularly reliable when you need something that changed in, say, 5.3.2 vs 5.3.1)

From my point of view, it's the lesser of two evils, and I felt that the approach I'm adopting (i.e. changing the hook's name if you non-trivially change its behaviour) is a lesser evil than version dependence.

Note that file edits do have a version dependence and that's not likely to go away. Mind you, it's not encouraged anyway so hopefully it won't be a big problem...

Yeah, it's not there yet, but it is on my to-do list, like a lot of the functionality here.

I really don't want to get into add-ons having version dependency on each other if at all possible. I'm not sure addons are going to cross-support each other half the time anyway and those that do will almost certainly be using hooks anyway.

1 file, 4KB

Revision: 1018
Author: arantor
Date: 11:36:26, 21 September 2011
Message:
! Make sure the absolute path to add-on JavaScript files is passed to the cacher, not the relative path even when we had already figured out the absolute one. (Subs-Cache.php)
----
Modified : /trunk/Sources/Subs-Cache.php

It might be related, I certainly commented on things. But when I see someone whose skills are still pretty raw[1] proclaiming how easy something is, I really begin to despair.Some of them are absolutely natural, some of them are suspiciously close to what we've talked about here though.*nods* That's really why it was never much of an option for me. I'd rather go with ADODB as a connector before I touch PDO, though, because PDO doesn't rewrite queries to suit different DB engines.

1.	Even if he has come a very, very long way since a year ago, when he couldn't even come up with a DB query by himself.

So, someone pointed me at http://www.simplemachines.org/community/index.php?topic=453157.0 - it's not even officially by a current team member and yet it's still the closest thing to a guide for 2.1 that anyone outside the team has.

Funny, it's almost as if he read through Wedge's feature list, you know.

I mean:
* Database Support
* Browser Support
* CSS3 & jQuery Implementation
* Bloated Profile Fields

These are things we've actually done already in Wedge, almost word for word.

Then the other stuff that is listed is stuff that has been talked about here, and it seems there is a lot of common ground there, you know, almost as if he'd been reading the forum...

Though I think he's talking out of his ass with PDO. While, yes, PDO does offer some things, sanitisation isn't exactly one of them (though, there is a valid argument to be made that prepared statements can deal with it for the most part), moving it to use PDO "just because" isn't really a good idea - and less hosts have PDO installed. There is an argment for making it an object, which we did, and are likely to expand on in the future.

I take exception, however, to:I'm assuming that he's referring to the db_insert stuff where you have to state the column type. Unfortunately for him, he's actually wrong on at least two counts where it can't be determined safely by PHP, though I will admit both cases are fairly rare.[1][2]

That, and the fact that you do actually have to state the list of columns you're inserting anyway, unless you're inserting an exact row into the table with all values added, and all columns in the exact same order.


Last but not least, I can't see them ever adding ReCaptcha, not least because that's a third party service and they don't use third party services (ever) in the core, but that it's unreliable at very best. I prefer our CAPTCHA, in all honesty, and I'm not saying that because I wrote it.

Also if you want a laugh, they have a new board dedicated to discussion of what's in the next version. Took them long enough.

Mind you, there's still some absolute gems such as http://www.simplemachines.org/community/index.php?topic=375491.msg3165582#msg3165582 - if he thinks it's that simple, I'd love to see him write it.

1.

They are bigint and set/enum cases where the individual values are numeric. In the former case, PHP may munge the data if it's bigger than 2^52 and on a 32 bit setup, and in the latter, if provided as numeric it won't encapsulate the data and will likely cause a query error. In both cases, the data should be sent in quotes, you know, using the string type. Been there, done that.

2.

Mind you, if it were to assume that everything was a string instead and *always* quote everything in the SQL, which is perfectly valid in MySQL even for integers (which it isn't in other DB systems, which is why it's done the way it's done), you could skip specifying both, and just pass everything to the quote function, but that does have a slight performance implication on things that insert a lot of numbers, which is more common than you'd think.

Is there a bevel around the edges of the triangles (and is there supposed to be)? Just because I see a slight bevel look on the brown triangle on the left hand image, and I can't see the same on the right hand image, and as a result the right hand image looks flatter to me.