Welcome to my latest labor of love, the NextJen Mobile Redesign!
I worked on this on and off for about 2 months, and really struggled through some weird issues. Even though I’ve made notes, I do not remember all of the issues, and my notes are rather cryptic. Oops…
This site was designed using Material Design (MD) principles and the Material Design Light (MDL) classes, though last I knew, Google is trying to move from MDL to integrated Material Design, only.
I re-built the site from its half built (Angular2) state, in Laravel + PHP. I’ve been wanting to really learn Laravel, and though I’ve taken a couple classes, I don’t ever feel like I’ve really learned a language or framework until I build something with it.
First thing I learned that I won’t do again, is use the material design classes of either the light or full version. I found the documentation lacking, implementing was confusing, and a lot of the functionality, you can get from using CSS grid or Flexbox with Bootstrap instead. I will probably still use the Material Design tools to be able to capture the ideas and principles behind MD without using the actual framework. High contrast colors, simple icon design, and the general accessibility to the end user is what drew me to it in the first place, but carrying those principles into your design doesn’t have to be through use of the confusing and frustrating MD framework.
I absolutely would recommend the Resizer tool though. It is a neat tool that allows you to see your (or whatever site you put in the url box) site at different breakpoints all at once, or individually. In the mobile portion, you have several different sizes you can choose from. I’ll definitely will be using this tool again.
Another design element that I use in this site (and am a big fan of) is the sticky footer. It stays nicely where it’s supposed to be and doesn’t get in the way of the content. I always struggle with them, though, and refer to this article frequently, if I don’t remember what I did the last time.
The next thing I learned is that I freaking love Laravel. It can be convoluted at times, and I definitely am not a tried and true expert (yet) but after re-designing and re-building this site over the summer, I built a volunteer sign up site for a friend of a friend who was running for office using Laravel. I learned even more building that, as it involved log ins, etc, but more on that in a future post.
This brings me to the next thing I learned, which is that it is possible to publish a Laravel site on a shared server. It’s not always the easiest thing to do, but you can do it. I might write more about it later, though I have the advantage of living with my server admin, so I definitely have more access than most on a shared server instance. This is a cPanel server, and I know that, like with PHP, people like to shit on it. But, I like it (and PHP) so if you want to give me grief about it, don’t @ me. I also see a lot of people asking about cPanel servers and Laravel, so I’m not alone.
Completely switching gears now, let’s talk about the software I used to build it. JetBrains continues to kill it with their toolbox, and I use PHPStorm daily in my development at work and at home. One thing you may have noticed this summer though, with the 2018.2 update is that you start to get weird Composer errors for ext-curl and other things you may use implicitly in your app. To solve this you just need to add “ext-curl”: “*” (or whatever it is that its throwing an error on) to your composer.json and re-run the composer commands. It will make the error go away, and no one could give me a satisfactory answer as to why. Someone may have found one and published it since I made this note I’m referring to in July 2018, but it works, and to be honest, that’s all that matters to me at this moment.
I have four more notes to cover from my Trello checklist for this post, but given that I waited almost 8 months to write this post, I don’t remember exactly what they are referring to, so I’ll list them here and hope that I remember what were referring to at some point. ¯\_(ツ)_/¯
- Paging WordPress (I used the WP-API to pull in blog posts)
- .htaccess breaks if missing on WP-API (I’m guessing this has something to do with the myriad of .htaccess issues I had once I published the site)
- rewrite condition (This may be a reminder to make sure that you have your rewrite for your public folder in your Laravel app or nothing will work)
- use config() instead of $_ENV when accessing .env variables (this, I believe, has to do with accessing the WP-API on LIVE vs local, but I’m not positive. I’ll come across it when I break everything again, though!)
This post got a little rambly, but I had a lot to cover, and trying to martial my brain to remember 8-10 months ago development is a lot harder than I expected it to be! I’m really happy with how the site turned out, and I will be (hopefully) more frequent with my blog posts. Especially as I catch up on what I’ve been doing the last few months outside of work, and continue to add features to this site!
✌🏻
Leave a Reply