I started off planning on using Google Calanders to store my clockin information. I was doing this for one main reason: Its important that how I store the information is standardized in case I attempt to export my plugin to node.js or another platform. But there is a problem I ran into that I realized may turn very annoying or worse.
this will create an awkward situation once the refresh tokens run out and the website owner is forced to login and authorize again
And as a minor inconvienience
Perhaps this is a problem on WordPress side more than googles in the way they setup their admin. Essentially I’m forced to create a plugin url that is independent from the direct flow. Making either the user Leave the admin interface conpletely or doing it through a popup. Then Instead of storing it in WordPress Options, we’d be storing it in a seperated SQL table to avoid loading wp-load.php. These are definitely managable, though not entirely preferable. If I’m using a content management system, I’d rather feel as though I can do everything in a very sexy and clean manner. Rather than go through hoops.
nonetheless I will continue to make the plugin as is simply for experience sake. Though I recognize this is definitely not final version
Update: What Killed using Google API as a web service was the fact that I am forced to use give my webserver an key file. This will not make future installations happy for random people. As a Result, I’m going to drop google calander from the design spec and move onto something else. This isn’t necessarilly Google Calanders Fault, but rather a design philosophy Flaw. I wanted to Use Google Calanders as My database, but I didn’t want to have to make installation a hassle. as a result, I gotta move on.
I’ll go with what is important
- Start DateTime
- Duration in seconds
- Github User
- Github Project