[EventCalendar] Small post saving buglet/ other notes

[David Nutter]

On Sat, Sep 02, 2006 at 08:03:52AM +0100, Alex Tingle wrote:

> On Thu, 24 Aug 2006 16:49:50 +0100
> David Nutter wrote:

*snip*

> > add_action('save_post',         array(&$ec3_admin,'save_post')); 
> > add_action('edit_post',         array(&$ec3_admin,'save_post')); 
> > 
> > In the case of a pre-existing post, _both_ these actions are executed,
> > resulting in two calls to save_post. This isn't a problem when
> > UPDATEing an existing event schedule entry, but INSERTing a new one
> > occurs twice, leading to duplicate schedule entries. Creating a
> > brand-new post doesn't call edit_post actions, so the solution is
> > easy, just comment out the second line. 
> 
> This doesn't work for me. Without the second line, I can't change the
> schedule date of a pre-existing post.

Curious; I can. I'm using WP 2.04 with PHP5 and MySQL 5, plus my
original modifications to EventCalendar. I'll experiment further with
the new beta you have released and see if I can pin down exactly
what's happening here. Matters would be made easier if the
circumstances in which wordpress called its various hooks were better
documented.  

> Perhaps we could count the number of times save_post() is called, and
> ignore all after the first?

That's a good compromise, though the addition of further global state
to manage the calls isn't ideal.


> Yes. I'm not sure what to do about this one. I agree with the idea, but
> I don't like having a new button on the options screen forever.
> 
> Perhaps we could delay the upgrade, and have a special 'pre-upgrade'
> options screen.

Yes, that would be fine. 

> 
> 
> > Secondly, adding a config option to turn the content filter which adds
> > the schedule to the post body on and off. This is for users who want
> > more flexibility in designing their templates. 
> 
> As I said elsewhere: I disagree. I want to keep the options as simple as
> possible.
> 
> If you are comfortable with editing your template to such a degree, then
> you should be comfortable with calling remove_filter() in your template.
> We need to add it to the documentation as a hint.

Fair enough. I shall endeavour provide a README patch tomorrow which
covers templating issues and the post upgrades. Can't promise I'll
have time to knock up some code for the "pre-config" screen though. 

> > Finally, I've updated the schedule entry dialog box to be more "user
> > friendly".
> 
> Yes, brilliant!
> 
> I've modified your code extensively, but don't take umbrage. Here's a
> list of the main things I did:

Not at all.

> 1. Coding standards compliance.
>    Max 80 cols. No tabs. Braces on lines of their own.

I have belatedly discovered the Wordpress coding standards docs. I'll
make sure that anything I produce in future adheres to them

> 2. Cut out repetitive prepare_XYZ() code, and replaced it with
>    a generic function driven by array data.

Brilliant. Those functions were left over from when I was
experimenting with different ways to enter the data (e.g. pop-up
calendar windows and similar extravagances) and should've been removed
before I made the patch. 

> 3. Reorganised save_post() to make it terser, and more similar to the
>    original. Broke some of it out into a subroutine.
> 
> 4. Improved the implementation of implode_assoc() and retrieve_date()
>    (and get_month_days() in the JavaScript.)
> 
> 5. Corrected the JavaScript to handle events properly, so that it works
>    in IE.
> 
> 6. Corrected the JavasScript so it now updates the DAYS field when YEAR
>    is changed. (Previously it would allow 2006/02/29).

Great. Apologies for the low quality of the Javascript; it's the first
time I've ever had to deal with the wretched stuff and consequently
I'm not au fait with the numerous browser quirks. I look forward to
experimenting with the new version.

Regards,


-- 
David Nutter <dnutter at lincoln.ac.uk>	Research Assistant
MHAC MC3102, Brayford Pool Campus
University Of Lincoln, 
LN6 7TS