week of 24 jun

24 Jun 2019

24 jun

What will this week bring? Now that it’s been confirmed we’re pretty well in the clear for migrating our current site to a server with PHP 7.2 and upgrade to WP 5.2.2, I’m going to try to make sure everything I can test has been tested. Then I probably need to go back through my logs and files and see where I changed things. I didn’t make any real changes to code… most of my issues were due to filepaths (which shouldn’t change if we’re just copying from one server to the other?) or apache settings (which Jennifer will handle with ease).

Maybe today I can go back and forth between making sure those plugins are all upgradeable and php warnings are being handled and writing documentation?

debugging the error/notice logs

There’s this really annoying notice that won’t quit showing up, even when I haven’t refreshed the page: wp_enqueue_script and wp_register_script called incorrectly: styles and scripts shouldn’t be registered or enqueued until wp_enqueued_scripts, admin_enqueue_scrtips, or login_enqueue_scripts hooks.

I commented out the last few lines in ualib-functions.php that does the live reload thing for the dev environment and they stopped showing up, so I’m pretty sure that’s it. I’m going to turn down the DEBUG setting in wp-config.php because this is out of control.

There also seems to be something wrong with the Advanced Custom Fields plugin or they way we use it. I can’t pinpoint what exactly it is, but it’s a warning and not an error, so I’m going to leave it alone: Warning: Invalid argument supplied for foreach() in /var/www/html/wp-content/plugins/advanced-custom-fields/includes/acf-meta-functions.php on line 95.

All the other logs are either from the WP heartbeat (checking whether I’m an active user, if my token is still good, if I’m still logged in) or telling me I’m missing a link (no surprise there, I only partially imported some pages and no other content). I think we’re in the clear!

documentation

I’m a little fuzzy about how exactly to document this codebase, especially since it’s all about to change. I suppose I could document my docker container and see what coalesces from there?

I spent the afternoon double checking where things live, how things compile/build, what connects to what… it’s all very complicated, but I think I actually get it now that I’ve had to touch most pieces of it. I drew a “map” of all the important bits of the site (wordpress, webapps back/front-end, and databases). The angular/front-end apps really need their own map, probably. Their nature is complicated: the truly front-end apps are grabbing data from their respective API and spitting that out to a template that is then incorporated into the WP theme. The manage app on the other hand, does GET and POST requests in order to update the information those apps serve to their templates. How to explain that in a flowchart?

I also started documenting versions and timelines for upgrading all our languages, libraries, and dependencies. Yikes. There’s a LOT going on here. But the sooner we know what we’re dealing with, the better off we’ll be, right?

Tomorrow:

25 jun

It’s documentation day! Yikes.

All day of documentation. It’s really hard to organize something this giant and spaghetti-esque. But I’m figuring it out!

26 jun

Finished up the documentation!

I also found an amazing node CLI app: markdown-pdf. Does what it sounds like– converts markdown to a pretty HTML/CSS-styled PDF– and it is amazing. I was trying to figure out what to do about sharing this documentation. Since I’m married to editing everything in markdown via vim and version controlling it in github, I was pretty devestated to think I’d have to put this in a word doc that I’d have to update every time something changed. But not anymore! I put the docs in a private repo with instructions on how to create the PDF so I can update it in Box.

I guess the next permutation of this will be an auto script that any time I push to github, it automatically generates the PDF and pushes the PDF to Box… things to think about for the future.

Since I have about an hour left here today, I think I’ll finish up my digital map in figma.

27 jun

Finished up all the documentation stuff today, added it to WTD Box, and shared with the group.

Moved on to figuring out what’s going on with ‘manage submitted forms’ app. The error in the logs says that a specific line in formsAPI.class.php is exceeding our PHP memory capacity. I figured this is because the two databases it’s pulling records from have 12k+ and 355k+ records in them, so I rewrote the two SQL queries to only pull records from 2018 on. This did not fix the memory problem.

I’ve been using the “dev” version of the databases in the docker container, but the forms app is working just fine in my docker build, so I decided to do a mysqldump of the full live database so I can get the correct amount of records to deal with. This took some doing (not sure why it wasn’t showing up in my FTP client!), but once the full database was in the docker container, my logs started to match the live logs: memory exceeded.

I purged the database of all records that were older than a year. This did not fix the issue. In fact, cutting out all those extra records only saved me 1 KB in memory! So something else is going on here.

My new hypothesis: building the array for the JSON/API is causing the problem. I could be wrong, but that’s the line that’s having issues, so it’s worth a look.

28 jun

Friday! Lunch with the Sara(h)s and AL! :blush:

Yesterday on my way out, I talked to Jennifer about the SQL/PHP thing, and she suggested wiping the database of all but like two records per table, just to eliminate the database being an issue at all. I think it’s a great idea, so I’mma do that.

docker container version control

I was also thinking (again) about how I might version control this docker container. It’s got so much good stuff in it, but with the theme already a github repo, I’m going to have to figure out submodules. Adding complexity to that situation: I’ve modified many of the theme files to work specifically with this container and was planning on never running the grunt build ever again so those modifications never get wiped. :joy: I know, brilliant of me.

Instead, what if I pushed these changes as a branch to the roots-ualib repo and pulled that branch in as the submodule? I think that could work, but I’ll need to think through the Bower/Grunt automation stuff because none of the apps actually live in the theme repo… hmmmmm. :thinking:

I tried removing the roots-ualib .git directory and remote URL from one of the many docker containers I created during this process:

rm -rf .git
git remote remove origin

Then I created a new private repo on github and initialized a git repo following the instructions for creating a repo for an existing project. The main directory already had a .git directory, but when I tried git remote -v it didn’t return anything, so maybe that was wiped at some point? Did that happen with the previous rm -rf .git command?? Anyway, it all pushed to the new repo no problem… but the roots-ualib directory is a subdirectory somehow. :woman_facepalming:

I tried to investigate this submodule, but when I run git submodule status or git submodule summary, I get the message “Fatal: No submodule mapping found in .gitmodules for path ‘app/wp-content/themes/roots-ualib’”. So I tried going further up the tree, but no submodules there, either. So I tried editing something in the roots theme so I could see what would happen when I push it to the repo, but it doesn’t even recognize the changes! So that repo isn’t being tracked…

I’ve officially spent too much time on this for this morning and need to move on to a different project. This is one of those little issues that’s going to drive me crazy this weekend, so I’mma take my laptop home and try to figure it out, probably. Scott’s going to be busy working this weekend, so maybe I’ll join him in my quest to figure this out.

forms SQL/PHP memory issue

JK, Steven wants me to wait til Monday on this. We might just scrap the whole thing and use ninja forms plugin to recreate within the CMS.

future timeline

Instead, I’ll update the IT-Planning spreadsheet with our bower/npm dependencies.