So I submitted my first plugin to pMachine’s ExpressionEngine plugins list.  It’s the JS Calendar for the frontend- a really simple plugin.  Why I hadn’t submitted any before now is a post in itself.  Why I’m rounding up a few to submit now- well, if you’re guessing it’s part of my not so secret SEO plans, you’d be right.

Should have submitted a long time ago- because I learned a few things in the process.  Stupid, simple things I probably should have already known.  But I didn’t- and now I do.  So figured I’d share them.  If you’re not a code monkey, skip this one.  If you are, it’s worth a quick read.

Read on....

Paul went over the plugin- he does it for any that will be included- and there were a couple of things that needed tweaking.  Word to the wise, do this right the first time and save yourself possible trouble later on.

1.  Make sure your editor is set to use UTF-8 encoding.  Did I even know you set the encoding on scripts?  Er- no.
2.  Likewise, set the line break type to Unix (LF on my Dreamweaver setup).
3.  Make sure you know what you’re doing with the $TMPL->fetch_param().

Basically, the $TMPL->fetch_param() is used to grab any parameters you may allow in your plugins and modules- see EE developer docs.  How’s it work?

If the parameter was not set in the opening tag, then the function will return FALSE, which allows the module developer to easily set default values or add conditionals.

Cool- so I was writing my conditionals like:

$form_id = ($TMPL->fetch_param('form_id')) ? $TMPL->fetch_param('form_id') : 'entryform';

So- if there’s a parameter ‘form_id’ (not FALSE), then $form_id equals that value.  Otherwise, it equals ‘entryform’.  Seemed like nice, tight code to me.  So when Paul asked me to change it to:

$form_id = ($TMPL->fetch_param('form_id') !== FALSE) ? $TMPL->fetch_param('form_id') : 'entryform';

I asked him why.  (Politely, but of course!) Turns out, the revised code is simply more precise- and precise is good with php.  As Paul pointed out: For example, a value of zero would make your original conditional FALSE as PHP equates 0 with FALSE.

4.  MySQL 5 is going to make me go through all of my old code and make sure it doesn’t break.  No- this wasn’t a lesson learned with this plugin, but since I’m writing them up, I’ll put it here where I can find it.

I knew this was on the horizon, I’ve just been blithely ignoring it.  Really- I need to get a dev. account on php5 and MySQL 5- which would make me be more aware of version issue.  However, in this forum thread a problem was reported with the DynoCat plugin.  That’s the plugin I REALLY rely on for my main site.  Which this is not.

So for the record, as Derek laid it out in simple terms (see MySQL docs for not simple terms):

MySQL starting with version 5.0.12 parses JOIN syntax differently than prior versions, supposedly to make it more compliant with SQL:2003.  It now has precedence over other operators so:

SELECT * FROM a, b LEFT JOIN c ON a.id = c.id

is now parsed as:

SELECT * FROM a, (b LEFT JOIN c ON a.id = c.id)

JOIN now has precedence over the comma operator so the JOIN statement only has access to tables within the JOIN syntax portion.  There are two workarounds, one is to not mix the comma operator and the JOIN, but one that seems to make more sense to me as it reads well, and works across all MySQL versions is:

SELECT * FROM (a, b) LEFT JOIN c ON a.id = c.id

Gross, eh?

Gross indeedy, as I now need to plow through my old scripts.  Oh well- need to go switch out the encoding and line endings anyway.

Got new defaults set, though.  I won’t be making these mistakes again.