DR Website Data
When I started my role as a developer at a marketing agency specializing in dental and medical practices, one of the biggest challenges I faced was finding the correct credentials and other site-specific data I needed whenever a client’s website needed work.
The problem was that the company had been growing for close to a decade, and a number of different developers and content managers had worked on client websites during this period, while utilizing several different hosting and DNS providers. What’s more, while all the websites were running WordPress, some of them had themes with certain features that myself or another colleague (for example, the SEO strategist) needed to know about, but there was no convenient way to determine the version name or number of a theme without manually checking a site.
WP login, SFTP credentials and similar data were stored in database, but over the years many of the fields had not been correctly updated when a site changed hosting, or when a static IP address used for FTP access changed.
As a result of all this, in order to work on a website, I often spent a lot of time simply figuring out the proper credentials, and matching them up with the correct hosting account.
Creating a solution
In order to simplify and automate the process of finding the right hosting information, as well as provide an automatic way to find site theme data at a glance, I decided to build a simple dashboard application using React and Node.js.
Having worked through manually setting up a React 16 project using Webpack a few times while learning, I opted instead for bootstrapping a new app using Create React App, to reduce overall project complexity until I decided I needed it.
Then, I set up and tested a series of API requests to the main sources of information that would be needed.
- Cloudflare: Since virtually all the sites the company manages have their DNS routed through one Cloudflare account, I decided to use this as the first source of “truth” that could supply me with a complete list of all the domain names. Cloudflare offers a pretty comprehensive interface via their API but for my purposes just getting a list of domain names that I could then iterate over to match up with other data was a good starting point.
- WPEngine: The hosting provider for all but a few company websites. Right as I began this project, they released a beta version of their API, which exposed a limited amount of data about each site, but enough to provide useful information including the CNAME, IP, and PHP version of each install.
- Codebase: A few years before I came onboard the company contracted a design firm to create a set of WordPress parent and child themes for their Dental clients, called “Codebase”. One helpful feature built into the parent theme was as a scheduled bi-weekly Cron job that sent the parent and child theme names and version to a “Versions” database. So I simply created a WP plugin for the “Versions” site that itself exposed the current version of this database by adding a custom endpoint to the built-in WordPress REST API.
Project Structure
Server
- Node.js, using an Express server to define API routes that the client can call
- Each route returns the response from an external API request
- Codebase: a WordPress REST API endpoint that exposes theme data returned from ongoing curl requests running on each of our websites that run Codebase themes
- WPEngine: the WPEngine REST API (beta), exposes a limited amount of account data
- Cloudflare: the cloudflare REST API gets a list of all Cloudflare zones and associated DNS data for each
Client
- React components
- Top level component queries the backend server via fetch requests to the Express endpoints defined in server.js (for now – they should be moved to separate files), then saves the response data in state and passes it down as props to child components
- Some components may need to send their own API request for performance reasons (only want to request the latest data X from a given site when the user loads that site’s dashboard instead of querying all 200 sites at once – for example, data from the WordPress API for a specific site)?
Next Steps
- Update the API requests to use a single promise.all invocation
- Refactor state object to eliminate repetition
- Add authorization (not yet needed as this is only deployed internally, but I play to add Firebase auth when this is deployed to Heroku or a Digital Ocean droplet)
- Compile data into single page dashboard, remove extra working tabs (in progress)
- Add unit and integration tests
This is still a work in progress, but myself and some of my coworkers are already using it to quickly find data we need. The finished version will have a cleaned up dashboard and much more data for each website that will be pulled from the WP REST API for that specific site.
Current source: https://github.com/Dchyk/dr-website-data