week of 03 jun

03 Jun 2019

03 jun

Learned all the WordPress things! Since we’ve decided to focus on rewriting our apps as plugins for WP, I’m going to abandon the 5.5->7.2 testing for now. It might come in handy later, but if I’m going to move all (or most) of the apps to WordPress anyway, it doesn’t make sense to spend the time figuring out whether or not they’ll work on the new server if they won’t even live there.

Friday and Monday were spent learning (or relearning in some cases) the WP template hierarchy, custom post types and taxonomies, plugins, and WP REST API. I’m pretty excited about the possibility of moving all of this under one umbrella, but I’ll definitely need to take a look at what that means for all the data in the databases… can they be imported to a WP database that the plugin uses? Would the plugin then serve that data to the API? It’s all kind of fuzzy right now, but I’m sure it will make more sense as I explore further.

04 jun

I’d really like to keep going on my WP journey, but I need to spend a significant amount of time on LibCal and room displays today. Our room booking team has another meeting next week, and I’m not any closer to having the answers to the questions posed in the last meeting.

My assignments from Tom:

Steven wants the study room displays to be the top priority here, so I think that’s where I’ll start today. Once I get that sufficiently nailed down (maybe a beta?), I can move on to ability to handle hours in general, which I think will be trickier than I originally thought it would be.

room displays

The timetables app I worked on that first month I was here should work for this. As I poked around in it this morning, it’s clear that it pulls info from the LibCal API and serves it to a static HTML page. I obviously don’t want to have 25ish separate static pages serving their own info… so I need to think about how to dynamically pull the room number from the meeting minder and have it grab just that room’s booking info. Or if there’s a routing option that only pulls info from the API based on room number.

For example, Bruno Study Room 13… could maybe be /timetables2/Bruno13 and somewhere in the routing, it could also set that route as an environment variable or something so it knows only to get that info from the API.

But right now, the “app” is very simple. No framework, no routing, nothing. Could vanilla javascript do this, or would I need a server?

I may not like it, but angularJS is a completely client-side option with routing built in. According to the $route documentation, I should be able to pull this off without too much hassle (…she said optimistically/naively).

As of 11am, I have a single room being pulled from the group API and displaying on its own page, so that was as easy as I thought it might be. We could stop here and just make an individual static page for each room that does exactly this and it would be done. OR I could try to get fancy so we wouldn’t have to manually update all 25 pages when something changes.

I will leave this for now until I check in and get further guidance.

managing library hours

After some digging around in their “hidden” API, it looks like we’ll be fine using this API for our current hours app. It will take some significant tweaking, but it will eliminate the need for the user authentication system we’re running.

shifting gears

New marching orders: back to testing the 5.6 apps in 7.2. Working on being cheerful about constantly shifting priorities.

05 jun

Today, I’m back at testing apps in docker. At least now I know which apps we’re actually using, so I can focus on getting those working.

I’ve been sort of bebopping around a few different containers and settings this morning, trying to figure out why some of these apps work and others don’t.

While I was testing the erCarousel app, I realized that the /slides/active endpoint loaded sometimes but never consistently, while the /slides endpoint would never load. Finding this behavior odd, I decided to swap to the musicsearch app to see if any of those endpoints work. Lo and behold, the /genres endpoint loads every time! The /showall endpoint does not load.

My next task: figure out what is different about the endpoints that are loading and the ones that aren’t. Is it user groups? Some other auth? Some config? Some function that’s getting blocked?

I’m in the process of trying to crack the individual functions in the musicSearchAPI.class.php. Because they’re protected functions, I can’t var_dump them from index.php, but when I changed them to public functions, everything vardumps just fine. If everything is dumping fine, that means there are no 7.2 errors. Then what’s the holdup in the endpoint? Even when I leave the functions public and try to hit the endpoint, I’m still getting a blank screen.

Hokay, so I went through each piece of the showall() function and had it spitting out data via both index.php AND the endpoint with echo and var_dump statements in it. So WHYYY am I getting a blank page when I request that endpoint when I should be getting a fully populated array? The array exists, and I can get it to vardump, even when the function is protected, but I CANNOT get it to return JSON data. Something bigger must be going on in another file or something.

Now to figure out where the data is converted to JSON, I suppose.

I’m not sure why it’s happening, but in sGP/API.class.php, when I use var_dump on the json_encode step of the response/request (line 99), it returns a string for the endpoints that return data, but returns bool(false) for all the endpoints that are blank pages. Did I finally stumble onto the main issue? I hope to find out tomorrow!

06 jun

I’m bound and determined to figure this out today. There has to be a value set somewhere that’s messing with this JSON data… and I’mma find it.

The _response() function in API.class.php uses the php function json_encode(), which according to the php manual returns a string on success or FALSE on failure.

After googling why a json_encode might return false, there were lots of suggestions to use the function json_last_error() and json_last_error_msg() to figure out what went wrong. On both musicsearch and erCarousel, I’m getting the error Malformed UTF-8 characters, possibly incorrectly encoded.

Now I have two options, I guess. Try to figure out where this malformed UTF-8 is coming from (not set properly in the database, possibly?) or maybe just not encode the JSON. It looks like that was an option previously, based on the code. There’s an in/else statement built in that goes if($this->JSONencode) do the encoding, else just serve the data. Why not just skip the encoding?

Y’all. It’s fixed. Used this function:

$data = mb_convert_encoding($data, 'UTF-8', 'UTF-8');

And now all the blank page endpoints are serving JSON. I could cry. Instead, I’ll probably treat myself to a frosty later. :tada::tada:

all tested

All the apps are now in the docker container. All endpoints that aren’t behind a “usergroup permissions wall” have been tested and are working. Even some of the ones with permissions associated were tested by commenting out the parts of the code checking authentication.

I’m confident that these apps will run just fine in 7.2.

I’m less confident that I will be able to figure out how it all fits together to ensure it’s running properly. My nightmare scenario right now is that we get everything moved to a new server, everything looks like it’s working fine because the endpoints are serving data, but then no one can update the content in/via the apps because I couldn’t figure out how to make them work.

I’ve only tested GET requests at this point. The POST/DELETE methods will be hard to test without really knowing what they do… so I’m going to drop these all into my wordpress docker container and see what I can break.