Problem with Low Events and Better Workflow
Hi Low,
One of our clients is having a problem with Low Events and Better Workflow.
It seems as if Low Events is writing the date in the wrong format to the 'exp_ep_entry_drafts' table.
It is writing it in 12 hour clock mode, e.g. {"start_date";"2013-12-03";"start_time";"5:30 pm";"end_time";"8:00 pm";"end_date";"2013-12-03";}
Instead of 24 hour clock mode (how you store this in the channel data table).
Could you have a peek and see if this is a quick fix to remedy?
Thanks a lot.
Luke
Electric Putty (We develop BWF)
Replies
Low 6 Nov 2013 17:30
Hi Luke, I've never actually added BWF compatibility to Low Events, so I'm not sure what I should look at. Looking at the format you have now, that's not valid JSON, so it's probably straight from what was submitted by the publish form.
electriclabs 11 Nov 2013 16:20
Hi Low,
It is actually being stored in valid JSON (Luke didn't paste verbatim) but I believe it's something to do with the 'am' and 'pm'. When I look at your data in channel_data it doesn't appear to match up with what we are storing in our drafts table.
It might need Malcolm to clarify, but because BWF 'bypasses' the normal EE save process, any extra jazz you do to your field before you enter it into channel_data isn't being fired when someone saves a BWF 'draft' (or submits for approval), hence why the time is getting reset to 1am for these people.
There is a bit of code in our API docs -> http://betterworkflow.electricputty.c... under 'Simple Compatibility' which I think would probably resolve this issue.
Sorry if my explanation is terribad, but I'm more of a front-end dude and not the dev on BWF :)
Thanks again,
Rob
Low 12 Nov 2013 16:47
The LE fieldtype has a save() method that converts times to a 24h format, so I'm guessing BWF catches the data before LE gets to it.
Also, LE does use its own DB table, so it might need more than just "simple compatibility". It's been on my todo-list to add proper BWF compatibility to LE, and now that I've just released Low Search 3, I might be able to find the time to do just that. :)
electriclabs 13 Nov 2013 10:07
Hi Low,
That makes sense, and it would be awesome if you made it fully BWF compatible :)
Let us know if you need any help or have any questions
Thanks,
Rob
Malcolm Elsworth 14 Nov 2013 14:31
Hi Low,
We have looked into this further and found that the solution was to get BWF to call on your existing save method when processing our draft data. I know this won't update your tables but converting the data to the correct format does seem to have solved our previewing issues.
As we can't always call this method safely - many fieldtypes don't return anything meaningful from their save() method - we need something in your fieldtype to tell us its safe to use.
If you could add:
$this->ep_better_workflow_use_save_method = true;
in your __construct() method we will run a check for this and if we find it know its safe to grab whatever the save() method sends back.
I hope this makes sense.
Many thanks,
Malcolm
Low 14 Nov 2013 15:04
Have you considered doing a matrix/LV-like style of methods? You could do a bwf_save() method instead of the native save method, so it can receive draft-specific content. I could simply call the save() method from within it. Slightly better than using the public property, I think.
Malcolm Elsworth 14 Nov 2013 16:23
Hi Low,
Sounds like a better approach. I'll rework our field controller and come back to you with a method name.
Speak soon,
Malcolm
Malcolm Elsworth 20 Nov 2013 14:32
Hi Low,
Having though this through a bit more I think we might need to add a public property to achieve what we want here.
BWF already looks for a set of methods in a fieldtype and calls these if they are found. You can read a little around this here: http://betterworkflow.electricputty.c...
The idea behind these methods is they provide a way for fieldtypes which store their own data to update their tables in a way which won't effect the live entry. As in many cases these methods don't return meaningful data, often only a 'y' so the field will pass validation, we don't update our data with what they send back.
In this case we _do_ want to update our data with the return value from the called method. So, even if we used the same method, e.g. draft_save(), we'd need to know before we called it that we want to update our data with whatever comes back.
I can't see another way of doing that unless we look for a property in the fieldtype which tells us so. And, if we're going to add this property, we might as well just use the native save() method, as this already exists and does what we need.
Hope that makes sense. Be great to hear your thoughts.
Best wishes,
Malcolm
Low 26 Nov 2013 09:55
Any chance of sending me a copy of BWF to try and get LE working with it properly?
Malcolm Elsworth 26 Nov 2013 12:06
No problem - have emailed one to you.
Best wishes,
Malcolm