week of 01 jul

01 Jul 2019

Before I lose it, this article on checking PHP memory usage was super helpful: How to check how much memory your PHP scripts use: a tutorial with examples

01 jul

Sleepy Monday, but time to get back on that grind.

The items on my to-do list are not necessarily related, so I think I’ll spend the morning working on this docker version control issue, then pivot to the intranet stuff after lunch. I’m still waiting to hear about the outcome of the forms issue before I spend any more time debugging that app (in case we decide to scrap it entirely).

vc’ing that docker container

Where I left off: I thought I’d wiped the git configuration of the roots theme repo before pushing it up to github, but it ended up as a submodule anyway.

I’m going to try:

We’ll see what happens!

I think I did it! Took a few tries, but here’s what worked:

Success???

The good news: the submodule is working. The bad news: now I have to figure out how to run the grunt build and pull in the vendor libraries without overwriting all the filepath changes I made. Maybe a challenge for another day?

I’ve spent a good while trying to undo the dumb-dumb mistake I made in this new docker container. I’m glad I’m trying this out in a test repo and not using the repo/container with my actual stuff in it! Learned a lot about git reflog and git reset, but I can’t figure out how to unstage the changes I made in my submodule without deleting it and starting again. Which might be a good idea? That didn’t work either for some reason. Getting the error “wp-content/themes/root-ualib already exists in the index”. Tried some git rm --cached roots-ualib and removing of git submodules and stuff, but it ain’t working. So I’mma delete the whole thing and pull it down fresh. BOOOOO

When cloning from the repo with the submodule already in it, don’t forget to cd to the roots directory, then git submodule update --init so it will clone the submodule files and set the commit/remote/whatever.

Lesson learned: don’t try to set the WP theme to roots until you’ve run the grunt build. You’re gonna have a bad time.

All in all, a successful day with the version control and git setups. I also did some ticket work/troubleshooting on LibCal, so it was sort of in and out of learning this stuff and handling that.

02 jul

Today, I’m focusing on the migration of the intranet from drupal to WP. Things I need to figure out:

UA WP theme

I think UA Strat Comm must keep its theme locked down to an extent because there’s no option to update the theme from the backend of WP. I went to their site and there was a page for download, so that’s what I did. We have v1.5.6 installed on our center for the book blog (who knows where else), but the latest version is 1.7.4, so there’s probably lots of changes.

I installed it and Rudaina’s child version and activated the child theme. Our nav bar is not what I expected it to be? So there must be some settings I need to investigate. The good news is it’s not entirely broken.

Turns out yes, there are plenty of settings that need to be set for this theme. I’m going through them currently, but I need to start putting in content for it to look like anything, so I’m going to leave off on that until I have more direction on content.

Plugins for auth

The two auth/login type plugins we already use:

Peter’s redirect plugin only redirects specific users/roles to a page on login, so might not be super useful. But! I do find it annoying that logging in to WP takes you to the dashboard… so maybe that will come in handy to redirect people back to the blog/intranet page.

The Simple LDAP Login plugin seems to be working on our website and blogs. It’s somewhat worrisome that it hasn’t been updated in 3 years, but it seemed to be working in my docker PHP 7.2 tests, so maybe we should just roll with it and wait and see?

In my research, I found two other candidates for auth plugins:

3 jul

At our meeting yesterday, we decided to roll with the current LDAP plugin and see what happens. Jennifer is not sure we’ll be able to set it up differently for a site under the multisite settings. The plugin on the multisite is set up to auth against the full university LDAP, but we want the plugin to use just the library active directory, and it’s unclear if we can do that on an individual site basis under a multisite install. That’s what I’ll be testing in the next few days!

forms app

Before I get to that, though, I want to tie up the forms app loose ends. It was determined during our meeting that no one is actually using the forms app or else we would’ve heard it wasn’t working months ago. So fixing that SQL query/PHP memory issue is no longer a priority. Instead, I’ll be adding a message to the app front-end alerting users to contact us if they need help with form data. Should be easy, but I haven’t actually updated any of these angular apps before, so it should be fun!

I had forgotten how painful it is to change things on the website… :joy:

Here’s what I’mma have to do:

Learned something new about our workflow today! In the dev site, to pull in changes made to a repo, user bower update <name of dependency> (so I used manage). Then run grunt to compile.

Liiiiike I’m glad there’s a system, but this seems like a bit much to change a template.

I TOTALLY FORGOT: The WebApps icon has never been in the toolbar on my dev build. How did I get that to show up?? I absolutley don’t want to deal with this today.

New plan, so I don’t fall down this rabbit hole: I will poke around and see if the webapps stuff is even set up in the dev version (I feel like it has to be somewhere since these files eventually get pushed to live??) and if so, what’s blocking it (probably the wwwdev2 stuff in functions or functions-ualib.php). Even then, though, I’d have to add myself to the dev userGroups and all the admin tables for those databses… blergh.

If it doesn’t look like it’s going to work after an hour, I will just push this to github and live and let live. All the changes were made to the backend, so even if it messes something up (highly doubtful, since I made the change to the template in docker and it was fine), it shouldn’t mess with the website itself.

None of this would be an issue if I had spent a few more hours working on the gruntfile changes for my docker build. The problem is that if I rebuild things in docker, all of the changes I made to make the apps work will be overwritten. Sigh… maybe Friday??

Only made it half hour before I realized: I probably won’t be able to access anything, even on the wwwdev2 server, because I’m on localhost. Duh! And I just double checked the wwwdev2 wordpress build, but it doesn’t have the WebApps admin bar icons, either. So I won’t be able to see if what I fixed broke anything in the backend, but at least I’ll be able to double check it hasn’t broken anything user-facing.

So I ran the grunt build and the grunt live build and both were successful. I can see on my local dev build that the scripts_bower.js added my changes successfully, but the wwwdev2 version doesn’t have my latest changes even thought I pushed them to github and pulled them in with a PR. Maybe it just needs a minute? I’m not sure how often that hook runs. I keep deleting the cache and reloading in hopes that it will show up there, but it hasn’t yet.

4 jul

Did about an hour of work from home today since I had some friends visit my office for quite a while yesterday afternoon.

Steven was pretty worried about the emails the about npm vulnerabilities after I pushed the manage_ui changes upstream. Every single repo we have has some crazy number of vulnerabilities– manage has 120.

I pulled down the repo to my little chromebook and ran npm audit. I then ran npm audit fix for the 9 vulnerabilities it could do, but like 96 of the vulnerabilities were semver breaking changes, so I had to run them manually. Which I did. After each dependency update, I ran grunt to make sure it was building everything without issue. Never had a problem with any of the updates, and committed after each one, just in case I needed to roll something back.

There are now 6 vulnerabilities left. The issue with them is that these packages haven’t been updated in years and are likely abandoned, so they won’t be getting updated any time soon. I could go to each pacakge, fork it on github, add it manually to our project, then update the dependencies (lodash and bower) to the safe version, but a) that will take a good amount of time, and b) who knows what that will break. Since these are solely dev dependencies, I’m inclined to not worry about this too much since we’ll be moving away from grunt/bower when we migrate sometime this year.

5 jul

First thing this morning, I had a KACE request to add a message to the ILLiad page. I do not have any idea how to access the ILLiad stuff and Drew didn’t leave behind any notes on ILLiad outside of document delivery, so that should be a fun mission today.

I’m also trying to hunt down why the dev site doesn’t match the github site. I checked the response headers, and they think the last time bower_scripts.js was updated was April 22, 2019. I thought that was odd, so I deleted the cache (again) and still it’s telling me April 22. To veryify, I got in filezilla and went to the roots directory and… it thinks the theme folder hasn’t been updated since April 22. :sweat::weary: So. What’s wrong with the github action/hook that’s supposed to push new changes to the server? Or what step did I not follow during my pull request?

Okay. I fell down a deep rabbit hole about github hooks (of which I can find zero in our repo) and deploy scripts. I actually found the deploy script on the dev server, so YAY! But I don’t understand it or how it’s being invoked. /roots-ualib/deploy-config.php, for future reference. It’s not in my local repo or even on github because it’s listed in the .gitignore. Of course. Instructions can be found in this repo: markomarkovic/simple-php-git-deploy.

I’m having a really hard time verifying whether this deploy hook is set up correctly because I can’t access the repo settings. I’m going to have to ask Steven to make me an admin or something so I can check on that. Until then, I guess I’ll just move on to something else.

I’m owner of the repo now, so I can do whatever I want with the webhooks. I’ve spent the past hour trying to figure out what exactly is going on here, and I don’t have a clear answer. The short answer is there’s a timeout on the payload. Unfortunately, I have no idea what that means. The payload service timeouts started when I added a branch for my docker project as a submodule… I don’t think this specific commit or anything in it is directly related to this issue, but it’s weird that it hasn’t sent any of the other payloads since then.

After another hour of googling and looking and being confused, I decided to try sending the payload via Postman as suggested in a stack overflow. It sent! My changes are now live on dev! I guess we’ll have to wait and see if the same issue happens with the next time I push something to dev, but at least I have a workaround for now. Here’s what I did:

The good news is that nothing is broken on the dev site, as I expected. I can’t actually see the changes I made sense the WebApps interface isn’t available in the dev site, but just knowing the changes I made didn’t actually break anything else makes me feel better about pushing to the live server. Since it’s now Friday at 4pm, I will not be doing that today… :joy: But Monday, I’ll send the PR.

WP multisite

I wrote this on Wednesday and just kept pushing it down my log thinking I would get to it, but I did not. This will be up next on Monday after submitting the PR for the forms change.

So here’s the deal: I’m going to install a new WP site in the multisite /blogs directory. It’s been a few years since I’ve handled a mutlisite install, so this could take some time to research. I’ll be working on the dev server in case I blow something up.