Day 11!

After some frustrating trial and error and searching through docs with lots of words I don’t quite understand, Dave Wasmer kindly helped me figure out how to get Ember Objects (the results of Ember data queries) in a format I’m used to working with: Something that looks like a regular array of objects, or “POJO” as Dave said.

The solution ended up being calling the map method on the array-but-not-really-array and toJSON on each item in that. Then I get something back that looks like [{name: ..., startDate:...}, {...}]

model.plants.map(c => c.toJSON()); 

This allowed me to render the charts with Ember Data stored in Firebase.

Tomorrow: Digging back in to D3’s update pattern and getting the chart automatically updating when adding a new plant. Dave’s helpful suggestion was to look into the “data down, action up” pattern.

Thanks, Dave!

Day 10!

I had a conversation on Twitter with Sam Selikoff and Ilya Radchenko, then later on Slack with Ilya and Dave Wasmer about using Firebase + EmberFire + Ember Data vs GraphQL + Hasura (Sam’s suggestion) vs GraphQL + Fauna (Ilya’s suggestion) for my data needs. I appreciate their inputs and arguments, but I ultimately went with Firebase + EmberFire for two reasons:

1. I don’t want to set up and maintain an API server for this project. That knocks out Hasura.
2. Fauna looks cool, but I don’t know either Ember Data or GraphQL that well, so I’ll have to learn one. Firebase + EmberFire + Ember Data is a little more battle tested and there is more documentation and search results for it vs Fauna, so I’m going to stick with that. I don’t want to be stuck in the dark on this project or constantly bug Ilya or Dave about stuff I don’t know. I do that enough at work.

So that means I set up Firebase and EmberFire today. It was surprisingly easy! The quickstart guide was solid. I was saving Ember Data to Firebase and retrieving it in my routes in no time.

I modified my Add a Garden form to save to Firebase, then transitioned to the Edit route where I passed along the ID of the garden I just created an retrieved the garden record’s data in the route. Then I read the Ember Data relationships docs and was able to both save and retrieve a garden’s related plants.

Then I got stuck: I tried to pass the plant data to the calendar component to render the chart and I can’t get it to work. The data isn’t coming through as I expect. I assume it has something to do with relationships in Ember data as promises, but haven’t quite figured the solution out yet. So that will be tomorrow’s project.

I feel like I’m making progress, though! It was super satisfying to see my collections and documents appear in Firebase.

Day 9!

• My problems with yesterday’s ember data store not being recognized magically disappeared when deleting node_modules and running yarn to install them again. Node, man. So good, but so frustrating sometimes.
• I got plants and gardens showing up in the ember data store after form submissions, which I verified with the Ember Inspector plugin.
• I added a form for creating gardens.

I thought I’d be able to get it all working locally before setting up EmberFire and Firebase, but after seeing that IDs for Ember Data are usually assigned on the server and having a talk with with Dave Wasmer and Ilya Radchenko, it sounds like I might be better off setting up Firebase now instead of trying to get Mirage to work. That is a little more than I have time for today, so that will be tomorrow’s goal.

Day 5! I didn’t think I’d make this much progress today, but I’m happy I did.

Today’s progress

• Built reusable form components (button, input, form, label) with the help of EmberMap
• Updated the chart
• Integrated a color picker addon ember-pickr
• Discovered and fixed a bug with the way I was calculating the scale.
• I didn’t realize how much stuff I thought was just regular Ember in our app is actually addons. A bunch of things I use at Crash every day didn’t work at first in plant-gantt until I tracked it back to an addon. For example: ember-truth-helpers and ember-decorators

The scale bug: You see here that blueberries are going off the right side. This is because I was calculating the scale based on the last plant in the list, which isn’t always the one that will be harvested last, only the one that will be planted last.

Instead, I had to use d3.max and offset to create a custom function to look at all of the plants and see which one would be harvested last:

let lastToHarvest = maxIndex(sortedData, d =>   timeDay.offset(new Date(d.start), d.daysToMaturity) ); 

Today’s commits:

1. upgrade ember, add form components, add some helpers
2. updates to chart with form data
3. get the color picker working
4. fixed end data calculation bug

Here’s how it works so far!

Tomorrow’s goal:

• Improve the form UI
• Use D3’s update() to update the chart instead of destroying and redrawing it
• Show a different screen on the first time you land instead of showing the mocked out chart
• Break the components apart

Day 4!

Today’s progress

• Sorted vegetables by start date
• Updated the data model to calculate the harvest date by the days to maturity
• Changed the scale to start 15 days before the first planting and end 15 days after the last harvest to save space on screen. This also allows things to start before January and end after December.
• Made the chart responsive

Making the chart responsive took me down a weird rabbit hole. I tried using a computed property and then a bunch of different addons, but none of that worked. So I went the old-school route and wrapped the chart drawing in a function and then added an event listener to remove the chart and redraw it. There is probably a more elegant way to handle it, but I don’t know what it is.

window.addEventListener('resize', function() {   selectAll('svg').remove();   drawChart(); }); 

Today’s commits:

1. change tick format to months and sort data
2. move to relative scales
3. responsive chart

Tomorrow’s goal:

• Add a form to add new elements and update the chart

Day 3!

Today’s progress

• set up pods because that is what I’m used to working with at Crash
• configured Tailwind in Ember
• successfully rendered yesterday’s D3 mock inside a component
• Talked to my first user (my wife!) and got feedback about the chart. She says vegetables should be sorted by when you plant them by default, not when you added them to the chart.

Resources that helped me:

• A guide to using Tailwind v1.0 and Purge CSS with EmberJS by chrism
• EmberMap’s Using D3 with Ember
• ember-template-component-import
• Ember Project Layouts to learn how to set up pods

Today’s commits:

1. configure tailwind, move to pods
2. add calendar component and add D3 mock to it

Tomorrow’s goal:

• change the calendar component to be responsive
• sort the vegetables
• Change the data to be closer to user-input data (plant date and duration, not just plant and harvest dates
• watch more embermap videos to learn how to update with changes to user input data

Day 2! I woke up excited to work on this and spent an hour on it before work.

Today’s progress

Figured out the basics of the D3 implementation for Plant Gantt:

• Learned how to use Observable
• The week-based X axis
• Stacking each plant similar to a horizontal bar chart and starting the bar at the correct start date
• Lining the labels up correctly

Here is the Observable notebook.

Tomorrow’s goal

Get back into Ember land and figure out how to incorporate a chart with mocked out data in an Ember component.

Last week I updated three large WordPress sites for Praxis from PHP 5.6 to 7.2. Here is the process I used on all three to make it a smooth transition.

Note: I do contract work and can help you figure this upgrade out. Reach out if you are interested in getting a quote.

1. Figure out the scope of the problem.

First you need to know how much time you should plan to spend doing this work. A quick way to find the scope of the problem is to run the PHP Compatibility Checker plugin. It checks your themes and plugins, spitting out errors, warnings, and filenames/line numbers of the offending code so you know where to start.

• Small theme upgrades?
• Plugin updates?
• Massive refactoring of custom code?

Even if you get a 100% clean pass with the compatibility checker, I suggest going through the rest of my list. The compatibility checker isn’t perfect. You don’t want to roll those downtime dice. Fool me one time, and all that.

2. Test the upgrade locally.

Copy down your current theme and database into your local development environment. This is important. Don’t use the version you have from work you did a few months ago. Stuff changes on the server all the time. Pull down a copy to be safe. Configure your local environment to use PHP 7.2. If you are unsure whether or not you are on 7.2 locally, you can always use a WordPress plugin like Debug Info to check. Also make sure to turn on error reporting in your php.ini.

Don’t have a local development environment yet? I like Valet.

While you are at it, I suggest upgrading your WordPress core to the latest version (5.1.1 as of this writing) and updating all of your plugins. Rip that bandaid off. On the plus side, it will probably make the PHP upgrade process easier, too.

3. Find, diagnose, and solve any issues.

This is either the easiest or hardest step. If your site looks fine and everything functions as it should, great! You won the lottery.

It is probably worth double checking that you actually are on PHP 7.2 with the debug plugin mentioned above. Also worth clicking all around your site and checking everything. Sometimes most of the site will load, but you’ll get weird inline error messages like this:

Warning: Use of undefined constant Y - assumed ‘Y’ (this will throw an Error in a future version of PHP) in /nas/content/staging/creativecourse/wp-content/themes/business-pro-theme/page-archive.php on line 70 

If you navigate to the site locally and all you see is a sea of errors like I did on one site, you have some work cut out for you. Here are some tips:

• If the errors include wp-includes or wp-admin in the file paths, you need to update your WordPress core.
• If the errors include wp-content/themes/ in the file path, and you don’t have any custom work done on the site, the quickest fix is to upgrade your theme or find a new one.
• If the errors include wp-content/plugins/somepluginname/ in the file path, find that plugin and disable it or update it and try again. You should still be able to get to your /wp-admin/ dashboard even with a broken site because the most recent core works with PHP 7.2.
• If your site includes a bunch of custom code and the errors are happening with the custom code, you have more work to do. If you are comfortable debugging and fixing it, great! If not, you might need to call the person or company who wrote it. Or decide if you can do without it. Hopefully you followed conventions and put it in a child theme.

Keep track of the changes you make. I keep a running list in my favorite notes app. Theme updates, core updates, plugin updates, and code changes. Write it all down. Better yet, version control it with git and commit along the way.

If you have any premium plugins that require activation keys, make sure that you contact the developer to get two extra development keys for local testing and production. Most will provide those to you at no extra cost. Some platforms give you 5 keys per purchase anyway just for this reason. I decided to roll the dice and not get keys for one plugin, and ended up crashing my production site with the upgrade because I didn’t test that plugin. Don’t be like me.

All three of my sites needed some work done, even the newest of the three. One didn’t load at all until I made some theme updates. One plugin crashed a site and had no updates available, so I had to do without. Some custom code I had written needed updates, too. It took me a few afternoons to sort it all out.

4. Deploy to a staging environment on PHP 7.2 first.

Once you have everything sorted out locally and you’ve triple tested everything, go ahead and push your work up to a staging environment. Good hosts like WPengine make having a production and staging environment easy. You can control the PHP versions independently. I use WPengine’s git deployment to move my local updates to the staging server. SFTP works, too. If you need database changes, you’ll also need to do a database migration. Core and plugin updates will need a database migration (Don’t forget to change the site URL or you won’t be able to log in!) If you need to do a database migration, use the instructions here

My preferred workflow is to copy the full production site (code + database) to staging, push my code changes, then do the core and plugin upgrades on the server (they often involve database changes), which is when my change list above comes in handy. I don’t like doing database migrations unless I absolutely have to, because with lots of users logging in to the site, data is bound to get out of sync with my local version in a matter of hours. Getting back in sync is tricky, so I choose to avoid the problem altogether by only moving code, keeping my change file, and replaying the steps on the staging server.

If you don’t have a staging environment and can’t get one with your host, or you can’t upgrade the PHP version yourself on your host, then you need a different plan. You’ll need to set up another site on another host that uses PHP 7.2, then put the updated copy of your site there. If you do this,proceed to the alternate #5 below.

Don’t assume everything works. Test it! Use different user account levels (admin, editor, author, contributor, and subscriber). Try every critical function on your site.

Only move on to the next step when you are certain everything works like it should.

5. Deploy to production.

Before you do anything else here, make a back up of your site and your database. Good hosts like WPengine make this easy. If you are doing this manually, verify the backups work locally. You can to be able to roll back if there is an issue.

I planned a maintenance window with my users a few days ahead of time. If you have users who rely on the site, you should, too.

Update your production environment to PHP 7.2, then copy the staging server to the production server. If you are confident that there were no users updating content in between the staging copy above and now, you can copy database and all. If there are changes you don’t want to lose on the production database, you’ll need to use my method and only copy over the theme code, then do core and theme updates on the production site. This is when planned downtime comes in handy.

Alternate deploy (no staging)

If you set up a separate site on 7.2 (not a staging environment of a production site) and it works, then you are ready to cut over to the new version. Configure that new site to use your domain (URL field on the setting page), then point your domain’s DNS records at the new server. If you need to do a database migration, use the instructions here.

6. Verify everything works

Don’t assume everything works. Test it! Use different user account levels (admin, editor, author, contributor, and subscriber). Try every critical function on your site. Use the Debug Info plugin to verify that the PHP change took.

If there are any issues, you might need to roll back to an earlier restore point and PHP version (or point your domain back to your other server), or do some real-time debugging. If your production and staging servers mirror each other in every way except PHP version, you shouldn’t run into anything unexpected. If you do, figure out where the difference is and go back to #3 above.