#Start with security, not the framework

The first step wasn't touching Vue. It was reviewing what in the repository could cause harm right now:

• A Google Maps API key written into index.html, for a map that wasn't even displayed. It was removed from the code, but since it's still in the public git history, the only real fix is to rotate it and restrict it by domain.
• A PHP contact form with no validation or protection. The Vue component already sent data to a different backend, so the PHP was dead code and a liability at the same time.
• An integration with the Twitter API v1.1, shut down years ago.
• The dist/ folder checked into git, plus two .zip files with copies of the project.

All of that can be cleaned up in an afternoon and doesn't depend on any migration. If the project stalls halfway through, at least it's left more secure than before.

#A phased roadmap on a separate branch

I wrote the plan in a Markdown file inside the repository itself, with checkboxes to track progress. The phases were:

The key was working on a migration/vue3 branch while master kept serving the old site. No "big bang."

#Vue 3 without rewriting components

Vue 3 still supports the Options API, so almost every component moved over with minimal changes: new Vue() became createApp(), filters disappeared, and the eventBus (an empty Vue instance in Vue 2) was replaced with mitt, which does the same thing in 200 bytes.

What actually took work was everything jQuery did through core.js, the original template's script: the page loader, the header that pins on scroll, the mobile side panel, and the project modal. Each one was rewritten as Vue behavior:

// App.vue — header pinned once you scroll past the top bar's height (jQuery's job in core.js before)
mounted() {
  document.body.classList.add('loaded')
  this.setHeader()
  window.addEventListener('scroll', this.setHeader, { passive: true })
},
methods: {
  setHeader() {
    const topBar = document.getElementById('top-bar')
    const limit = topBar ? topBar.offsetHeight : 0
    document.body.classList.toggle('sticky-layout', window.scrollY >= limit)
  }
}

With that, jQuery, Bootstrap JS, Masonry, Owl Carousel, and Isotope all left the project at once.

#What replaced each Vue 2 dependency

This was the most entertaining part. The rule: if a plugin wasn't updated for Vue 3, find the smallest possible replacement, and if what it does fits in twenty lines, write it yourself.

That last row is the most important one: half the dependencies in an old project usually aren't used. Before migrating anything, check whether it's actually imported anywhere.

#Vite instead of Webpack 3

The original toolchain (Webpack 3 + Babel 6) broke on Node 17 or newer because of OpenSSL changes. Upgrading Webpack from version 3 to 5 was almost as much work as switching to Vite, so I went straight to Vite:

// vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import { fileURLToPath, URL } from 'node:url'

export default defineConfig({
  base: './', // relative paths for GitHub Pages
  plugins: [vue()],
  resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } }
})

The result: vite build finishes in a few seconds, producing 240 kB of JavaScript and 306 kB of CSS. The CSS is still large because the original template loads all of Bootstrap 3; trimming it is the next phase.

#Automatic deployment

With Vite, publishing became the easy part: a GitHub Actions workflow installs dependencies, runs npm run build, and pushes dist/ to GitHub Pages on every push to master. The dist/ folder stopped being tracked in git.

#What's still pending

• Move the template's SCSS into the Vite pipeline and remove unused CSS.
• Replace icon fonts (FontAwesome, Themify) with inline SVG.
• Run a Lighthouse audit: performance, accessibility, and SEO.

#Frequently asked questions

#Should I migrate to Vue 3 or rewrite with a different framework?

If the design and components still hold up, migrating is cheaper: Vue 3 keeps the Options API, and most of the code moves over unchanged. Rewriting only makes sense if the design is changing too.

#How long did the migration take?

Phases 0 through 3 (security, cleanup, Vue 3 + Vite, and dependency replacement) were completed over a few work sessions spread across a handful of days, because the plan was written up front and every task was small.

#What do I do about an API key that's stuck in git history?

Rotate it. Deleting it from the current code doesn't help if the repository is public: anyone can read the old commits. Generate a new key and restrict it by domain (HTTP referrer) in the provider's console.

#Is it worth keeping the Options API in Vue 3?

For a migrated project, yes. The Composition API is better for complex, reusable logic, but changing components that already work purely for style adds risk without immediate benefit.

#Conclusion

Migrating a legacy project isn't one big task but many small ones: security first, then cleanup, then scaffolding, then dependencies. Writing the plan into the repository and working on a separate branch made the process predictable and kept the site running the whole time.

#Why static, and why cPanel

A personal blog doesn't need a database or an admin panel. With HTML files:

• There's nothing to patch or update on the server (no more "WordPress needs updating" warnings).
• The page loads in milliseconds, because Apache only has to serve files.
• The content lives in git, as plain text, editable with any editor.

And cPanel, for all its age, has exactly what's needed: an Apache server that serves folders, supports .htaccess, and accepts FTP uploads.

#Writing: Markdown with front matter

Each post is a file under posts/<lang>/ with a metadata header (front matter) and Markdown content:

---
title: Post title
description: 140-160 character summary for Google and social.
date: 2026-09-10
category: Tools
tags: [cpanel, ftp]
cover: /assets/img/my-cover.jpg
keyPoints:
  - First key idea.
  - Second key idea.
---

Content in **Markdown**…

The URL comes from the file name: posts/en/2026-09-10-my-title.md publishes at /posts/my-title/. If the file has draft: true, it isn't published. A command (npm run new -- "Title") creates the file with the template ready to go.

#Generating: a framework-free Node script

The generator is a single file, build.js, that does three things: reads the .md files, converts them to HTML with marked, and inserts them into HTML templates with a minimal variable engine ({{ title }}, {{#if}}, {{#each}}). The output goes to dist/:

dist/
├── index.html                  homepage (paginated at /page/2/, /page/3/…)
├── posts/<slug>/index.html     each post
├── posts/<slug>.md             the same post as clean Markdown
├── category/<name>/            category listings (categoria/<nombre>/ in Spanish)
├── assets/                     css, js, images
├── sitemap.xml · rss.xml · robots.txt · llms.txt · 404.html
└── .htaccess                   Apache configuration

No Jekyll, Hugo, or Astro. I have nothing against them, but for a blog with a custom design (the same one as the portfolio) it was faster to write 500 lines of JavaScript than to learn each tool's templating conventions. And npm run dev spins up a local server that mimics Apache to preview the result before uploading.

#Configuring Apache: the .htaccess file

This is where it differs from a modern CDN: on cPanel, everything is configured with an .htaccess file that the generator writes automatically into dist/. The essentials:

Options -Indexes
DirectoryIndex index.html
AddType text/markdown .md
ErrorDocument 404 /404.html

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
  <FilesMatch "\.(html|md|txt|xml)$">
    Header set Cache-Control "public, max-age=300, must-revalidate"
  </FilesMatch>
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript
</IfModule>

Clean URLs (/posts/my-title/) work on their own because every post is a folder with its own index.html. CSS and JS carry ?v=<build-id> in the URL, so they can be cached for a year without risking stale versions.

#Publishing: incremental FTP with a manifest

Uploading all of dist/ on every change is slow over FTP. Instead, the deploy script stores a .deploy-manifest.json file on the server with the SHA-1 hash of every uploaded file. On the next deploy:

1. It downloads the manifest and computes the hashes of dist/.
2. It uploads only new or modified files.
3. It deletes from the server files that were in the manifest and no longer exist (say, a deleted post). It never touches files it didn't upload itself.
4. It uploads the updated manifest.

Fixing a typo in a post means uploading two files (the HTML and the .md) plus the feeds, not hundreds. The FTP client is the Node package basic-ftp, and the credentials live in a .env file that isn't versioned:

npm run deploy:dry   # connects and shows what it would upload, without touching anything
npm run deploy       # build + incremental upload

#SEO and AI assistants

Since the HTML is fully generated, it's easy to include everything search engines expect: canonical tags, Open Graph, JSON-LD structured data (BlogPosting, BreadcrumbList, an automatic FAQPage from the FAQ section), sitemap.xml, and RSS.

And for AI assistants (ChatGPT, Claude, Perplexity), which send more and more traffic every year, the blog publishes:

• /llms.txt, a site index in the llmstxt.org format.
• /llms-full.txt, with the entire content in a single Markdown file.
• Every post at /posts/<slug>.md, linked from the HTML with <link rel="alternate" type="text/markdown">.
• An "In summary" block at the top of every article with the key ideas.

#Frequently asked questions

#Does this work on a subdomain, or only at the root?

Both. The generator has a configurable basePath per language: empty if a language lives at blog.mydomain.com, or /es if it lives at blog.mydomain.com/es/. All internal routes, the .htaccess, and the sitemap adjust automatically.

#What if the hosting doesn't support FTPS?

The script works with plain FTP, explicit FTPS, or implicit FTPS; it's chosen with an environment variable. If the hosting's certificate doesn't match the server name, another variable lets you accept it anyway.

#How do I add images to a post?

Copy them to assets/img/ and reference them as /assets/img/file.jpg. Keep covers under about 250 KB. If you replace an image, use a new file name: images are cached for a month.

#Can I use this system with a different design?

Yes. The templates live in layout/ (header, footer, post card, post page) and the styles in a single framework-free CSS file. Changing the design means editing those files.

#Conclusion

Shared hosting isn't a limit on having a fast, well-ranked, easy-to-maintain blog. Markdown for writing, a Node script for generating, .htaccess for configuring Apache, and incremental FTP for publishing: four small pieces that are easy to understand in full.

#1. An API key in the HTML

The index.html had a Google Maps <script> with the API key written right into the URL. The map wasn't even shown: the div that held it was commented out. But the key was still there, in a public repository, available to anyone.

What I did: delete the script. What still needs to happen: rotate the key. Removing it from the current code isn't enough, because git history keeps every previous version of the file. The new key should be restricted by domain (HTTP referrer) so it only works from the site.

Rule of thumb: if a secret ever touched a public commit, it's compromised. Rotate it.

#2. A PHP contact form nobody used

The project included contact-form.php, the script that shipped with the original template to send emails. The Vue contact component already posted data to a different backend, so the PHP was dead code — and dangerous at the same time. It was still deployed and reachable by URL.

A script like that, with no validation or rate limiting, is a spam relay waiting to happen. What I did: delete it, and while I was at it, remove the entire contact section, which was the only reason jQuery Validate was loaded.

#3. An integration with a dead API

There was an api/twitter/ folder with code for the Twitter API v1.1, shut down years ago, complete with its own token configuration file. Dead code doesn't throw errors, so nobody reviews it — but any servable PHP file is attack surface, and any configuration file is a candidate for leaking credentials.

What I did: delete the whole folder. If it's ever needed again, it's in the git history.

#4. Build artifacts and zips inside the repository

The dist/ folder (the compiled output) was checked into git, along with a dist.zip and a src.zip. Three copies of the project, each with its own dependency versions and potentially secrets already "deleted" from the source code.

What I did: git rm -r --cached dist/, delete the zips, and make sure .gitignore excludes them. Deployment should generate the build, not read it from the repository.

#5. jQuery 1.12 and an audit that surprised me

jQuery 1.12 has known vulnerabilities and no longer receives patches. The obvious reaction is "remove it," but first you need to know who actually uses it. The audit gave a curious result: out of all the code, only the template script (core.js) and the form validation depended on jQuery. The Vue components didn't.

Once the contact section was removed (point 2), the only remaining use was in core.js, which got replaced by Vue behavior during the migration. The lesson: before auditing or replacing a dependency, measure its actual usage; it's often smaller than it looks.

#A checklist for your next legacy project

If you're picking up an old frontend, this review fits in an afternoon:

#Frequently asked questions

#Do I really need to rotate a key I already deleted from the code?

Yes. In a public repository, anyone can recover the previous version of the file with git log -p. Even in private repositories, clones and forks retain history.

#How do I know if an old PHP file is still reachable?

If it's inside the hosting's public folder (public_html or equivalent), it's reachable by URL even if nothing links to it. Delete it or move it outside the public folder.

#Is npm audit useful for a 2016 project?

It's useful as an inventory, but it will produce hundreds of warnings, many for dependencies that aren't even used. Prioritize the ones actually imported in the code and the ones that run on the server.

#Conclusion

None of these five problems required migrating the project to fix. They were addressed before touching Vue, in a separate branch, with small commits. Starting with security makes the later migration simpler, because there's less code to move, and it guarantees the effort is worthwhile even if the project stalls halfway through.