Class overall: I was excited to take this class because I knew it was going to be quite different than my other PR/CC classes. Overall, I’m coming out of class with a better understanding of the fundamentals of web development, and why it’s important for today’s marketing/communication professionals and journalists to be well versed in this field.

The first few weeks were overwhelming and a bit difficult to grasp everything. Coding is very detailed with so many moving parts, so when Greg told us to only concentrate on the bigger concepts — it was challenging. But, I’m happy Greg reiterated this throughout the semester – by learning the broad concepts and utilizing WordPress, you are capable of creating a customized website.

What I learned: My expectation of the class was to learn enough coding skills to create a website, as well as learn how to better communicate with developers – and I think this was accomplished. In addition to learning basic coding skills (HTML, CSS, PHP, JavaScript), I gained knowledge about how to actually setup a website. I never heard of MAMP, GitHub or CyberDuck before this class, so learning these applications was tremendously helpful. I had some WordPress experience prior to class, but now I feel much more comfortable with the Admin and Codex. I also learned that taking a class like this is going to be very frustrating at times, but I’m happy that I’m coming out of it with better problem-solving/troubleshooting skills.

Why it matters: Learning about web development is going to matter more and more as we progress in our careers. From the developer profile assignment, I learned that the working relationship between developers/designers and digital marketing/communication professionals is extremely important.

What I’ll do with the new knowledge/skills: I plan on drinking more wine so I can add additional content to my site 🙂 There’s also more customization that I’d like to do, such as incorporating a photo slideshow. The knowledge/skills gained from this class has already helped me in my current job and will continue to in the future. My department at work is implementing WordPress by the end of the year, and I will have a key role in the CMS/front-end. I don’t think I would be as excited about using WordPress at work if I wasn’t for this class. Clearly companies are catching on by investing in this platform, so it feels good to know that I have experience working with WordPress.

Thoughts on initial readings: I feel much more comfortable about the concepts explored in our readings from week one. The readings about “thinking” talked about looking at programming from a broader perspective… I can appreciate this idea much more having lived through creating a website. I also enjoyed re-reading the WordPress philosophy and really took to the 80/20 principle:

“The rule of thumb is that the (WordPress) core should provide features that 80% or more of end users will actually appreciate and use……That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.”

After the class ends: Although we covered a lot of different topics in class, I don’t recall learning about Python. I keep hearing that it’s the “latest and greatest” language to learn. Maybe I’ll check out a Codcademy lesson or tech blog to see what all the hype is about. After this class, I think there’s going to be a lot of that — reading industry blogs — to further my skills and knowledge.

The Agile manifesto and best practices video really hit home for me. Remember early on in class when we had all of those glorious ideas about what our websites were going to look it? I initially wanted to build a custom slideshow using JavaScript… and that clearly did not happen. It’s takes a lot of time to plan out and create a personal website, and being realistic about what you can and cannot accomplish in a given time period is critical.

I immediately thought of work while I was watching the Agile video. I work on a project management team that builds a variety of digital programs for various clients. One of the most difficult aspects is getting on the same page as the client, and delivering a product that they truly wanted in the first place. It’s a constant give and take between exceeding the client’s expectations and not going outside the statement of work (putting more time in than we are getting paid to do). The principles of Agile are key to ensuring you deliver a valuable product, on time and on budget.

One of the most intriguing best practices that Jay talked about in this video is how you should only have the team members who are working on the project provides the estimate. I could not agree with this more. At work, we are always running into issues with the sales manager promising things to clients that we simply cannot deliver.

At the end of the video, Jay talks about the definition of done, which takes me back to our class sites. While there is a shared opinion of what “done” means, Jay says that one of the core tenets of agile is that when the team declares the project done, it needs to be in a releasable state. I think this was the ultimate goal for class. Yes, we are never actually done with working on our personal sites — there’s always going to be content and customization to add — but having a site that is functioning and ready to launch means that we are DONE. And right now, that’s a good feeling.

Side note: I’m really happy we went through a critique phase for our sites. I appreciate all of the feedback I received! Getting user feedback is truly an important part of creating a website.

I can’t believe it’s already time to present our sites. In nine weeks, I went from knowing very little about web development to having a fully functioning website. Not only is the visible aspect of the site gratifying, but having knowledge about the “behind the scenes” coding and application part (MAMP, GitHub, GoDaddy and Cyberduck) is just as rewarding.

Last week I felt pretty good about my site – the functionality was complete, all I had left to do was add some content via my custom post type (CPT). When I began adding posts, however, I quickly realized that my site was not “calling” my CPT posts – it was only calling the generic posts built into the theme. After some good-old Codex research and collaborating with Charlotte, we discovered that we needed to add a filter that would “get my CPT posts.” Four lines of code later, we got it to work – but I wasn’t out of the woods yet.

In addition to creating my CPT called ‘wine,’ I created two custom taxonomy categories (region and year). The plan was to have each post searchable by year or region. While my CPT and taxonomies were showing up just fine in the Admin for last few weeks, I realized this weekend that only my ‘region’ taxonomy works properly in the actual posts. This was very frustrating because I created the region and year taxonomy the Exact. Same. Way. Trust me, I looked at this code for about two hours yesterday.

At this stage of the game, I decided to delete the ‘year’ category and just roll with the ‘region’ category. I plan on troubleshooting the problem again because having the ‘year’ category would be nice, but since our sites are due today, I decided it’s better to have the site working without the additional taxonomy than having a malfunctioning site.

Looking back at my initial pitch, my site is pretty much on par with what I set out to accomplish. But, now that I know substantially more about coding/programming than I did back then, I wish I had time to do more. I’m looking forward to further developing my site, but for now, I’m at happy place.

Excited to see everyone’s sites on Tuesday!

Advice for next time: Always check that your theme is supported by ALL browsers. I learned the hard way that my theme (Magazine Basic) is not supported by Chrome, so please view in Firefox or Safari.

My goal this week was to finish the main coding aspects for my site, which consisted of creating a custom post type (CPT) for “wine” as well as custom taxonomies for “region” and “year.” For every wine post I add, I’d like to associate the region and year of that wine. Last week, I attempted to create the CPT as a plugin and also in my functions.php file – both attempts failed (the CPT would show up on my local site, but not my real site).

This week, I took another shot at creating a CPT plugin and also adding custom taxonomies. After doing a little bit more research in the Codex and reading the Smashing Magazine CPT article, I finally got it to work by dragging the plugin file I created into Cyberduck! I initially tried to upload the zipped plugin file through the WordPress Admin, but I got an error message. I’m always quick to use the Admin, but in this case, dragging the file into Cyberduck was the only way it worked. I’m very happy to finally have my CPT and taxonomies showing up on my live site. As Ice Cube would say, today was a good day.

The reason for adding custom taxonomies was not only so I could sort my wine posts, but so visitors of my site could also have an easy way to sort through various posts. For example, if someone is only interested in wine from Napa Valley that was produced in 2008, they could choose those custom taxonomies and the site would generate all posts relating to those specifications. (This is assuming I had a variety of posts that met the criteria.) Simply creating a CPT/custom taxonomy plugin, however, wouldn’t automatically display the taxonomies in each post – this required more coding changes. Thanks to a little guidance from Greg, I determined that I needed to write a simple conditional statement in my content-footer.php file so that the custom tags (region and year) would be visible in each post. Another small victory when this actually worked for me!

My overall tip is to take the time to understand what and why you are changing something in the code. The possibilities of what to change in the code is endless, so it can be very overwhelming. For this project, I decided to concentrate on one major change (create a custom post type/custom taxonomies plugin) and try to understand everything there is to know about that plugin…what the code is actually doing, etc. I’m still no expert, but I hope that by having a good idea about what my first custom plugin is doing will help me make future coding changes – faster, easier and with less headaches.

This weekend I was determined to create a custom post type (CPT) for my wine website. My initial plan was to create the CPT as a plugin, since that’s what Greg recommended. It turns out that’s a little more complicated than I thought it was when we went over the concept at 9:15 p.m. last Tuesday. I browsed the Codex for a refresher and did many Google searches, but unfortunately I couldn’t figure it out. So I moved on to plan B and placed the CPT code into my functions.php file. Once that step was complete, I connected to my local server and checked my WordPress admin panel. It was a miracle…my new “Wine” CPT button was added right below the comments button.

This was a great accomplishment, but having the CPT only display on my local admin won’t do me any good in the future when I want to add content. So I decided to commit/sync and drag my updated functions.php file into Cyberduck in an effort to get my CPT to show up on my web admin panel – piece of cake, right?

Wrong. After Cyberduck was finished downloading, I refreshed my website… and screamed because the screen turned white with a fatal error message. This was the first time I received an error message of this magnitude, so I was freaking out. But instead of throwing my laptop across the room, I deleted the functions.php file from Cyberduck, and that apparently fixed the problem. But, I’m still without the CPT on my web admin menu.

Sidenote: I found this handy “Common WordPress Error” resource page in the Codex, which I will now be bookmarking.

I want to revisit plan A – creating the CPT as a plugin – but I plan on doing some additional research before experimenting again on my site. For now, I will continue making style changes in the css and gathering content that I plan on incorporating.

Command Line
I have to admit, I was a little skeptical about learning command line. Isn’t clicking easier than typing? But after actually going through the motions in class and browsing the readings, I understand why command line could be very useful in some situations. In my job, I often have to convert image files to different formats. Sure, clicking a button or two to convert one image is definitely faster. But, what about 1,500 images… in a short period of time? Typing a command that’s a few lines long would be much more efficient.

It was great having Andy come in and speak to the class. While I didn’t grasp every single thing he was talking about, I now have a better understanding of the capabilities of WordPress. His discussion about child themes was especially useful for me. I’m happy he listed the 3-4 parent (and very basic) themes he recommends for creating child themes. I initially was thinking about using a very complex theme for my site, but I have now decided to go the more simple route with a theme called magazine basic.

After downloading my new theme, I spent some time looking through the various code and browsing the admin section. Since I’m creating a child theme, I know I definitely will have to create a new directly that includes a style.css file. But what about the other parent theme folders? Do I only drag the ones I want to edit into the child theme directory? I know I want to create a custom post type, which will be done through code, but what file do I create the code in?

I also spent some time trying to understand the differences between the local server and the web server, and how they “talk” to each other – for lack of a better word. I successfully connected to my local server and starting making very minor changes through the Admin section and was able to instantly view the changes on my local site (which was pretty cool!). But I’m having difficulty being able to view the changes on the web (even though I commit/synced files on GitHub and successfully connected to Cyberduck). Is it because I made changes through the Admin and not the code? My new theme is showing up, just not the text changes I made.

Ah.. so many questions still… but finally feel like I’m starting to comprehend what I’m doing.

Theme that is. I’m happy we had a few reading assignments this week to get more acquainted with WordPress themes and plugins. After reading the Child Themes section, I think it makes sense to create a child theme for my site – primarily because it is the easiest way to modify an existing theme.

This concept of modification reminds me of the “refactoring” term (from our first class), which refers to changing internal code without affecting the external meaning or behavior. For my site, I want to use a lot of images (maybe even a slideshow with captions!). So finding a theme that already supports this seems like the best option. But what if I only want three photos to rotate instead of 5, which the parent theme came with? I could easily make that change to fit my needs by altering the code, but the change is minimal enough that it will maintain the original look.

The “refactoring” term is also very prevalent at my job. We build a lot of custom emails/newsletters for clients. They are sold as “custom,” but let’s be honest, there’s only so many ways you can put together an HTML email template. So, we are frequently reusing templates and making minor changes to fit specific clients’ needs. Why go through all of the steps every time if you can simplify it, right?

Side note about class in general: I feel like I have learned so much in these last five weeks, and it’s very exciting. However, I don’t think I have a solid grasp on everything I’ve learned. I’m particularly concerned about remembering the actual logistics of setting up my self-hosted website. From MAMP to GitHub, and Go Daddy Domains to Cyberduck, I’m still confused about how all of these elements work together. I hope we can go over the process again next class.

I’m happy to report that this week was much easier for me compared to last week. I breezed through the two jQuery lessons, which was a good self-esteem booster because I actually felt like I knew what I was doing. I’m not sure if jQuery is easier than JavaScript, or if completing the JavaScript tutorials last week helped me better understand the jQuery lessons. Part of me wishes we would have started out with jQuery because it seems a lot simpler to wrap your head around, and then go into learning the basic concepts of JavaScript. But who knows what the best approach is? I think you can argue it both ways.

In last [Tuesday] night’s class, I thought it was helpful that Greg walked us through the take-home assignment of adding captions to our galleries. I also appreciated that he assured us that the objective here is not to memorize the code, but to grasp the overall concepts. This morning, one of my colleagues said something about JavaScript that really resonated with me. He said, “I’ve never really written any JavaScript, but I sure do manipulate it.” What he was getting at was that he knows enough about the overall concepts that he can edit or change existing JavaScript code to make it do what he wants. Looking back, this seems to have been the goal of the gallery assignment.

I’m excited that we are now in the process of setting up our hosting site for our final projects. (But who knew there were so many steps involved!?) I wanted to mention one thing about purchasing your domain from GoDaddy.com. Last night I created an account and added my chosen domain to my “online cart,” but I didn’t actually purchase it. This morning when I woke up I had an email from GoDaddy saying that if I complete my order by July 2, I can use this special promo code to get 30 percent off. So… in case you haven’t purchased your domain yet, this is one way to save on the cost!