Refining my Process (Part 2)
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.