Bekah Sealey

• Categorized: Workflow
• Tagged: PHP Programming Tools Linux Sublime Text Composer
• Comments

Isn't synchronicity funny? I ended the last post with my attempt to make myself a dashboard widget that would give me a reminder message to append my hosts file, which I am surely going to forget to do if I don't put a message to future me somewhere. I have a textbook about plugins I've just started, but it was late and the book was downstairs, so I thought I could quickly find a tutorial and copy over code. Which didn't work. And, thus, as it was late, I set it aside for another day.

The following day, I had to run my daughter to a dentist appointment, so I needed a task that I could accomplish on the go. Looking through my RSS reader, I realized I had over 50 starred articles, that I had marked in order to come back to later. Later never arrives. Except that, that seemed like an ideal task to work through on such a day. I have my pinterest board set up to divide Development articles into subcategories so I can easily find resources for given topics of interest. It's more navigable than a random collection of starred articles (and slightly more frequently referenced). I set about saving the links into pinboards.

Lo, and behold, I found a set of articles on linting PHP, primarily for WordPress. Thinking of my recently abandoned attempted plugin, and the many new and wonderful things I would be designing in the future, I realized that this could be a great way to up my tooling and coding game and relieve me of the need to manually edit my code for WordPress standards. No, it won't fix broken code, but it will definitely help keep my code tidier.

Proceeding through the complete tutorial went off without a hitch. Then the following day, I realized that the process as designed, would require me to install the sniffer in every project folder, then run the commands from terminal. First problem, the command used the directory path to execute it, which was less than memorable. Second, I don't need extra build steps or duplicate extraneous directories in all my projects. I needed to streamline the process, ideally within my Sublime Text editor.

Maybe I should rename this blog, "Confessions on Code." The following will display the degree of my ignorance of my own tools I have chosen. These are my breadcrumbs for myself, so when I find myself in similar circumstances in the future, I can recall what worked before and get myself back on track. If you cringe at novice coders making ignorant mistakes, this is your cue to look away now.

I thought that setting up my sniffer in Sublime Text would be as easy as setting up the plugin, distributed by the same folks that developed the PHP_CodeSniffer, Squizlabs. I opened up the settings, went over to my terminal to run which phpcs, only to find nothing. I have nearly no composer experience. I didn't yet realize the command would only run downpath from where composer installed the sniffer. I attempted to use the phpcs command, and terminal gently informed me that I didn't have the package, but I could install PHP_CodeSniffer to access it. So I did. Which was a big mistake.

With a system wide access to the commands, which phpcs worked! So, I edited the settings file to provide the right path to the commands.

Now I needed to reinstall the WordPress standards, which is what this whole project was about. The tutorial I used initially didn't tell me how to set up the WordPress Coding Standards outside of composer. Google directed me to another tutorial which described how to install the WordPress standards. However, since I installed the commands through apt, I couldn't clone the repository into the bin directory. I dropped it in my home directory and attempted to configure the package using that path. Which failed. And gave me errors about not writing to certain files. Which I overrode with sudo as one is wont to do when confused. Then I returned to the Sublime PHP_CodeSniffer plugin settings and tried to set the standard to WordPress. I ran the plugin and nothing happened. I tried it on another file and nothing happened. I ran the linter through terminal, and got a set of error messages. Great!

At least, error messages produce something to Google. Error messages are my friends. Things that do nothing and produce nothing are the problem.

The subsequent course of events are a little foggy at this point. They involved trying many things. I recalled that I had gotten several errors about not being able to write to files that should not have needed a sudo command. I had just upgraded my OS a week before and had had a few issues with packages that didn't upgrade quite right, or dependencies that got locked, etc. I wondered if my permissions were off. I reset my home directory permissions to be sure.

I also thought that maybe I should follow more of the tutorial in which I used to install the WordPress Coding Standards and use those plugins. That lead me to discover I had a much larger problem. I could not get Sublime Package Control to install anything. I had not used Package Control to install the PHP_CodeSniffer plugin, so I didn't discover this earlier.

I found the Package Control Troubleshooting guide and followed the steps for Purging and Reinstalling Package Control. After that, the plugin would install, but disappear on restart. I found a way to turn on those all-important error messages, by turning on debug mode in Sublime Linter. This showed me that the plugin was being removed during set up because Sublime was not finding the gutter theme files.

I installed separate gutter theme files. Nada. I reinstalled Sublime through the package manager. I uninstalled and reinstalled...I complete uninstalled and reinstalled. Nothing worked. Finally, I discovered a comment in a forum to revert Sublime to a Freshly Installed State. It couldn't hurt. The instructions stated to move the data folder. It took another couple searches to confirm that "data folder" was in fact, the entire Sublime Text 3 folder within the .config directory and not a folder within it as the instructions suggest. That worked! I could get the plugin to install and stay!

However, the plugin wouldn't run. I realized that the way I had PHP_CodeSniffer installed, and the WordPress Standards installed, was conflicting with the plugin's functioning. I decided to completely uninstall PHP_CodeSniffer and the WordPress Standards from everywhere and call it a night.

Something magical happens when the brain rests over night. I woke up and knew exactly what to do, and within 15 minutes of waking up, before taking children to school, I had the PHP_CodeSniffer installed globally, the WordPress Standards cloned into the directory and everything running in terminal again. I used the same Sublime Linter tutorial I had used before, but using the proper Linux commands, as on this guide to globally installing PHP tools with Composer. I added the directory to Path, as instructed on the guide, with one mistake I would discover later on.

The Sublime Linter plugin installed. The accessory phpcs plugin also installed, and properly accepted my path and WordPress standards. Finally, I decided to try and reinstall the original PHP_CodeSniffer plugin, and that worked as well. I am currently running both because the one places markers in the files and the other creates a verbose output that explains what the error is.

The final hiccup I discovered after a restart. I didn't understand what the guide meant by saving the PATH to the bash profile. So, the PATH was only good for that session. Once I restarted my computer, the PATH to my composer/PHP_CodeSniffer installation was removed, and everything failed again. Thankfully, I had a suspicion and quickly found the solution with instructions on stack overflow, How to place the ~/.composer/vendor/bin directory in your PATH.

Now that I have a better idea of how Composer and Sublime Text plugins both work, I'm excited to add a few more tools to my workflow. Here's to hoping next week actually results in the production of something useful.

• Categorized: Workflow
• Tagged: PHP Programming Tools Linux Sublime Text
• Comments

As my youngest is only three years old, my business load has been low-volume, the majority of which is the maintenance of current clients. Building out new sites has only been one at a time. Given that, I didn't give much thought to setting up my environment, other than setting up a locally hosted WordPress for the sites on which I run WordPress, and a cross-platform capable text editor (my hardware consists of an iMac, out of family traffic, and a laptop running dual-boot Windows and Linux Mint installations, for portability and diversity of OS).

I am expanding into WordPress Plugin development. Knowing that occasionally Themes and Plugins do not play nicely together, I wanted to create a set up into which I could install as plain a starter theme as possible, and keep it purely plugin focused. It wasn't until after I set up the second local WordPress, that I realized I had a pain point that would amount to a large scaling problem once I try to kick my business into second gear. Until now, I would set up a new project on the existing installation, add new posts and pages that reflect a particular client's needs, install the theme or build it up, customizing it as I go. New client, all the previous gets reset, and the new project begun.

Obviously, this is completely unworkable for working more than one site at a time. On the occasion that I have had to return to a project to make adjustments, it is a large hassle to manually revert everything the way it needs to be for that project. I often end up making some modifications directly to the live site, then save them back to my github repository, which is a hazardous way to develop. It leaves me wondering and second guessing whether I remembered to update my repo properly. Thankfully, I have not yet had a crisis, but it really is only a matter of time.

I began pondering my current set up. What if I could set up a project and leave it set up? What if I could just spin up a new install for each new client/project? Duh! That is a multisite environment. Ah-ha.

I have never worked with multisite and set about to figure out how to install it. I discovered that decisions needed to be made right off the bat. Do I want subdomain structures? Or subdirectory? The first would complicate set up, but the second seemed prone for more confusion down the road. The first would require a fresh install, while the second would allow me to continue using my existing set up. The first would require me to look up more tutorials on how to set it up, since the tutorials I had found tended toward the second (to avoid the rabbit trail of Apache customizations). In the event I had multiple sites open at once (always), I want the URLs to be obvious at a glance, so I went with the first.

There are really only a few steps: 1. edit the Apache hosts file, 2. install a fresh WordPress and turn on multisite, 3. select the subdomain option, and 4. insert a new subdomain into hosts for every subdomain. The fourth one can be set up to be automatic in older Linux environments, using wildcard DNS, but it looks like my newly upgraded Mint, running on Ubuntu 16.04, doesn't have a simple way to do that. Another problem for another day. I found both these tutorials helpful,

How to Setup a Localhost WordPress (Sub-domain Multisite) Environment and The Ultimate Guide to WordPress Multisite. I found a slight complication in my personal set up, because I do not solely work in WordPress. On my Linux system, my local Apache folder contains other sites in addition to my WordPress installation. I originally had WordPress in a secondary directory. That set up did not work with the subdomain installation, although it worked just fine with the subdirectory based multisite. Once I chose the top level directory for the installation point for WordPress, the steps proceeded smoothly. I combined all my non-WordPress projects into a new directory, which I can still navigate on my localhost, and step out of the WordPress environment.

Since I had an existing WordPress installation, I found this tutorial to help guide my process through converting that site into the new multisite set up: How to Move a Single WordPress Site into a Multisite Network.

Unfortunately, I have not had a chance to dig into my new environment, set up all my clients' sites, and pat myself on the back about my own brilliance. In the process of trying to make myself a little reminder dashboard plugin, so that weeks down the road when I can't figure out why my new site won't come up in the browser, and then remember that I have to add the new subdomain in hosts, I stumbled into a much larger issue, with more adventurous rabbit holes, that stoked the "maybe I really should get a Comp-Sci degree" fire, because then maybe I'd be able to understand what the heck happened. Continued in Refining my Process (Part 2).

• Categorized: WordPress
• Tagged: PHP programming plugins
• Comments

Working with a longterm client today, I rediscovered an odd behavior in WordPress. Her business is seasonal, with varying locations and itinerary, so she needs to be able to turn pages on and off, adding or removing from the menu as necessary. She has been taught to set unneeded pages to "private." After doing so, that page was still visible in the menu and accessible even to logged out users!

It is easy enough for me to simply remove the page, and then later add it back in via the custom menu tools. However, this is a problem I wanted to solve in a way that didn't require extra steps every time a menu item needed to be made invisible. I started with looking for a plugin. Usually, behavior like this is a solved problem, and I expected to quickly find something and implement it. The only solutions I found either didn't work, or required accessing menu items directly to control their visibility. This client needed to be able to continue to perform the single action she was used to, without having to remember additional steps (who does?).

Google turned up some CSS solutions, which is less than ideal. The data is still being received, it just ends up being hidden. While the situation here is not particularly sensitive, there is no need to send data that isn't intended to be received.

Finally, I discovered a way to programmatically remove private items from the menu itself, following a stack overflow thread.

The reason (I think) that private or non-published items show up in menus is that the menu items are themselves posts and have their own post status. That means that in a situation where a page is marked private, the menu item for that page can still be set to publish, and is displayed. I wrote a filter callback for the wp nav menu objects hook which looks at the post_status for the object that the menu item stands for, and removes it from the menu if that object is private. - user jjaderberg

I edited the code a bit to suit my use case, and turned it into a simple plugin to avoid editing my client's theme files directly.

  function nmo_hide_pages_from_menu ($items, $args) {
    foreach ($items as $item => $list) {
        if (get_post_status ($list->object_id) == ('private') || get_post_status ($list->object_id) == ('draft')) {
            unset ($items[$item]);
        }
    }
    return $items;
}
add_filter ('wp_nav_menu_objects', 'nmo_hide_pages_from_menu', 10, 2);

The plugin is available on my business site http://nmomedia.com/services/web-services/products/wordpress-plugins/hide-menu-items/. Future development goals are to add plugin options, like whether to show items in menus to logged in users, or certain user roles.

• Categorized: Troubleshooting
• Tagged: HTML CSS PHP programming
• Comments

Troubleshooting code is one of my favorite things. No, really! I find great pleasure in taking something broken and making it work again. I am challenged to employ my personality traits of dog-headed persistance, logical analysis and puzzle-solving ability. Of course, with any worthy endeavor, there are frustrations. But, the exhilaration of finding that missing tag, or misspelled word, or rewriting a function with fewer lines of code, is satisfying. But the main reason I enjoy troubleshooting is that it causes me to learn more.

When I begin to learn a new language, one of the first things I want to understand are the tools to troubleshoot my programming. Throughout my schooling, the most frustrating language I learned was ASP .NET. Having recently picked it back up again, I realized why I struggled. The textbook we used placed troubleshooting at least two-thirds of the way through the text. We covered the text chronologically, so for many, many weeks, if I encountered a problem with my code, I was limited in what I could do to resolve it. More than once, I simply scrapped the page (which is also not easy to do in Visual Studio) and started again. I felt that I was being robbed of the learning that results from identifying and resolving an error, no matter how insignificant that error might have been.

Recently, I have had the pleasure of encountering a variety of problems to troubleshoot. A long-time client finally had a failure of an elderly WordPress plugin that hadn't been maintained in four years. While devising a new work around to solve the problem in the quickest and least expensive way possible, I also discovered the server was still running an ancient version of PHP. Note to self: when doing website maintenance updates, also check PHP version. I'm not sure if the plugin would run with the updated PHP, but access to this particular website is critical at this time, as the organization has an impending conference. We are still working out little kinks, but we are mostly back in business.

The other issue was an HTML/CSS bug in a website I regularly follow. I was able to help interpret what was going on technically to other users, and offer some workarounds until the site owner was able to repair the problem. While I didn't implement any coding myself, the exercise in interpretting technical issues for a non-technically literate audience was worthwhile. As a freelancer, I cannot take my users level of knowledge for granted, and am always challenging myself to explain things in as simple a manner as possible without insulting people's intelligence.

I'm not going to go into the technical aspects of trouble-shooting in this post (hint, Google is your friend!), but rather offer encouragement that finding your own solutions is rewarding beyond having a functioning website, function or script again. When people ask me how to get better at coding, my basic answer is to break stuff. Making mistakes is inevitable. Being able to fix them shows you are well on the path of mastering the skill.