When a client provides a standalone HTML file and asks to “just host it,” the request can seem simple—but it often isn’t. In this case, what appeared to be a basic upload turned into a more nuanced implementation involving external APIs, frontend dependencies, and WordPress integration best practices.
Instead of directly uploading the HTML file, the solution involved converting it into a secure, maintainable WordPress page template while preserving its functionality and external data connections.
Issue Background
A client requested help hosting a provided HTML file on their WordPress site. The expectation was:
- Host the HTML file on the server
- Make it publicly accessible via a URL
- No backend integration required
However, after reviewing the file, several important details emerged:
- The HTML file functioned as a dynamic class finder tool, not a static page
- It relied on a Google Apps Script API endpoint to fetch data
- The data source was a Google Sheet populated via Gravity Forms
- The page included:
- Search filters
- Map functionality (Leaflet.js)
- Dynamic rendering of results
Additionally, the site already had a separate system for a similar purpose, which raised questions about overlap and implementation strategy.
Diagnosis
Initial analysis revealed several key considerations:
1. Not a standalone HTML file
Although delivered as a single HTML file, the tool depended on:
- External JavaScript
- API calls to Google Apps Script
- A structured data response from a Google Sheet
Without data in the sheet, the tool appeared “broken,” even though it was functioning correctly.
2. Potential security concerns
Uploading raw HTML directly via SFTP can introduce risks:
- Unescaped user-generated content
- Inline scripts without sanitization
- Lack of integration with WordPress security layers
3. WordPress compatibility
Directly hosting an HTML file would:
- Bypass WordPress templating
- Limit maintainability
- Create inconsistencies with the rest of the site
4. Clarifying actual scope
After client clarification, the requirements became clear:
- This is a new public-facing class finder
- It is separate from existing systems
- It should live on the main WordPress site
- No backend development required
- Data is fully managed externally via:
- Gravity Forms
- Google Sheets
- Google Apps Script
Resolution Steps
1. Convert HTML into a WordPress page template
Instead of uploading the file directly:
- Created a custom template file in the theme:
tpl-class-finder.php - Preserved the original structure and functionality
This allowed the page to:
- Live within WordPress
- Be editable and manageable
- Follow theme and site conventions
2. Externalize and properly enqueue assets
- Moved CSS into:
/css/class-finder.css - Moved JavaScript into:
/js/class-finder.js - Enqueued assets conditionally via
functions.php
This ensured:
- No global conflicts
- Better performance
- Cleaner separation of concerns
3. Harden security and data handling
Several improvements were made:
- Sanitized all dynamic output
- Validated API responses before rendering
- Secured external assets (e.g., Leaflet) using integrity checks
- Removed inline JavaScript and wrapped logic in a scoped structure
4. Maintain external data flow
The tool continued to rely on:
- Google Apps Script endpoint for fetching data
- Gravity Forms submissions feeding a Google Sheet
No changes were made to:
- WordPress database
- Existing site infrastructure
5. Deploy to staging for validation
- Implemented on a staging environment
- Verified:
- Page rendering
- API connectivity
- Filter and map functionality
Since the Google Sheet initially had no data, the page correctly returned empty results until real submissions were added.
Final Outcome
The final implementation delivered:
- A fully functional class finder tool inside WordPress
- Clean integration with the existing theme
- No disruption to existing systems
- Secure handling of external data and scripts
- A scalable structure for future updates
Additionally:
- The page remained fully independent from other directories on the site
- Styling conflicts were avoided through namespaced CSS
- Performance was optimized with conditional asset loading
Key takeaway
If a client asks you to “just host an HTML file,” take a closer look.
What seems like a static page may actually be:
- A frontend application
- Dependent on external APIs
- Requiring proper integration and security handling
Handling it correctly upfront avoids long-term maintenance issues and ensures the tool works reliably within WordPress.
If you need help integrating custom tools, external APIs, or advanced functionality into your WordPress site, contact Freshy here:
