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.

After breezing through this weeks Codecademy PHP lessons, I thought I was well on my way to building my own site. Although we didn’t seem to learn anything too complicated, and I’m not quite sure how I will be practically using arrays and loops yet (I’m not going to create all of a 500 word post by typing “This”, “is”, “my”, “post”, and then echoing a loop, and I’m not going to spend too much time counting to 100 by 10s), the concepts and syntax were simple enough to follow.  Much of it had the same JavaScript syntax; always include semicolons, use brackets or curly brackets to tell the computer what to actually do or print out.

Reading through the codex for WordPress, however, I started to come across some foreign concepts and potential problems that I didn’t realize could happen. While child themes make a lot of sense (I always wondered how the site would be able to update and stay compatible with WordPress without breaking completely), as well as plug-ins to save time, and I realized that different post types could be formatted differently, I never thought there could be so many naming conflicts and additional things to worry about like hooks. I’m not sure what hooks are, or what they are supposed to do, but if I’m making a custom post template, WordPress assumes I already know what they are and offers me the best one to use.

It also bothered me that not all themes did not support all post formats, which I thought would be a benefit of using WordPress. I guess this means that some posts are just more complicated than others and that some themes are too simple, but I assumed that this all could be modified to work in some way. I guess I still have a lot to learn about the way WordPress’s templates, themes, infrastructure, and modification coding all work together.