Week 10 Project, Part 1: More JavaScript…

No New News Here – I’m Behind!

I’m way behind on my “52 Weekly Websites.” Sigh. I hope to do better going into the new year (2019). I started this venture in October… of 2016! I’ve actually been working on this project – on and off – for a couple of months now. A non-trivial project mixed with a lot of learning apparently takes time.

An Actual Project This “Week”

So, last “week,” I was tinkering with creating content (and menus) using only JavaScript. I learned a lot and I’m happy with the results, so I thought I’d continue with JavaScript for the next project, which is an actual app that I want to be able to use to track business miles in my vehicle(s).

This week’s project will also use the localStorage (or Web Storage) or maybe the IndexedDB features of HTML5 (or maybe both – but I’ll probably start with localStorage). For this project, I want to be able to input data about trips, both local and long distance – date, time, mileage, vehicle, and a short description. I don’t want to have to use a back-end database on a website somewhere for the data storage, so I plan to store it locally in the browser, and then export it to a file that I can use to track business miles.

A Couple of Realizations (Finally)

Woo-hoo! The DOM is a collection of objects! Well, yeah, everyone except for me realized that already. After all, DOM stands for Document Object Model. I guess I just never quite put together that the elements in the DOM for an HTML page were also child elements, which in turn could have child elements. This became important when both sorting the divs for the trip records (but it didn’t dawn on me then) and when creating, harvesting, and destroying the divs for the data entry/edit form (finally, the reality began to seep into my consciousness).

Also, the CSS3 “important!” tag is sometimes, well, important. I spent more time that I should have trying to figure out why some of my styling wasn’t being applied to a specific element. I pored over the styles for the element using the browser’s developer tools, and making changes on the fly to get the result I wanted, but nothing worked. I finally broke down and just used the important! tag and, voila – success.

Details Begin Next Week

Well, that’s the plan. I sure hope I make it. This project will be split up over at least 3 weeks of posts, but not more than 5. Stand by…

Week 6 Project: Update a page with a “push” from the server – Part 1, WordPress

This week’s project will be broken down into multiple parts – it seems too big to do all in one week. The end goal is to have a process that runs on the server and outputs updates to a <div> on a web page in real time without user intervention, and without reloading the browser page. I also would like to avoid using AJAX so that there is minimal impact on the user’s performance. Finally, I hope to be able to do this in such a way that the user could close the page/browser, log off the site, and then come back at some later time, log in, visit the appropriate page, and continue getting real-time updates if the process is still going, or get a final status if the process has finished.

The primary motivation for this project is because I want to be able to write code to load a text file (probably a .CSV file) into a database, get the process status (however that is defined), and not be required to leave the browser page open for the entire time the process takes (in case it takes a really long time (thinking in terms of many hours or maybe even in terms of days)). This is necessarily a simplified version of the requirements, and I’ll fill in more details in each of the upcoming blog posts that deal with this project.

This project will need a database, an authentication and authorization mechanism, and a way to easily create pages with forms to control the upload of the text file and the parameters of the database loading process. A basic WordPress site will provide all three and is easy to set up. So, I’ve set up a WordPress play site and configured it with the theme I like to customize (Colinear by Automattic), the child theme I use to do the customization (Colinear-KC by Kobayashi Computing), and a couple of plug-ins that I use on most sites.

You can see the results of this week’s work by going to the project site, clicking the “Projects” drop-down and choosing “Week 6 (2017-02-22)” or you can go directly to the WordPress play site.

Week 5 Project: Bootstrap Carousel

This is Week 5 of the “52 Weekly Websites” challenge (see http://dev.kobayashicoding.net), which was supposed to be published at noon on February 15, 2017. The update to the project website was uploaded before the deadline, but this blog post was neglected. So, here it is, a little late…

This week’s project is pretty recognizable and straightforward: a sliding carousel of photos for a website. The Bootstrap framework provides the capability for this, and it just needed to be customized a bit. Ho hum.

The impetus for this particular project was a request from a client to add a carousel to a page on their WordPress site. So after getting the Bootstrap carousel function to work quickly and easily on the project site, I thought, “how difficult could this be to integrate into WordPress?” Well, as these things often go, it took longer to get it into production than it should have.

I had already used some Bootstrap functions on this particular site, so the WordPress “header.php” in the child theme (more on that next week) already had the code to include the Bootstrap CSS and JavaScript files, as well as the required JQuery files. So – working on the development site, not the production site – I copied the appropriate WordPress page to a new temporary page, added the HTML to it, saved it as a draft, and then clicked the “Preview” button. Success! Worked like a charm. I needed to tweak the image sizes and padding a bit, and also apply the style to round the corners of the photos, but the carousel functionality was working. After the aforementioned tweaks, I saved the draft again and checked the preview version again. Perfect! Time to publish the temporary page just to be sure everything worked correctly and looked good.

Oops… in the “published” version the carousel did not work – the first photo was displayed properly, but it never changed. Hmmm. I changed the status of the page back to “draft” and previewed it again. Again, it worked flawlessly. Clicked the “Publish” button again, checked the result – carousel not working. After much head-scratching and investigation with both Firefox’s and Chrome’s built-in developer’s tools, I finally figured out what the problem was.

The problem turned out to be that when I’d originally added the code to include the files required for Bootstrap, I had used relative paths. Yes, I know, stupid mistake (but aren’t they all once you find them?). Even though I had used Bootstrap functions for the front page of the site, it worked there because the “root directory” was effectively the “working directory” for the front page. However, WordPress adds the short name of the page to the end of the URL when displaying a published page; it does not do this when previewing a draft page. Changing the header.php file in the child theme to use full paths for the Bootstrap-related files solved the problem.

I won’t make that mistake again.