Why did I reconstruct a working website?
The situation was simple: From a technical point of view, everything was fine with the site., but as soon as I entered WordPress admin, I was in the mood to touch anything.
The site did well in search engines, it was user-friendly, but the backend – here I mean the WordPress admin interface – You were the catastrophe. There is a saying that shoes always have holes in them. In my case, it was no different.
The problem? 36 active plugins, an opaque code base, and an admin interface where I was afraid to touch anything to keep it from falling apart.
The idea: Complete reconstruction
I wanted to write more articles on the site, create fresh content on a regular basis, and be present at all. But As soon as I entered the admin, I lost my temper..
I'm a member of some WordPress communities where a lot of people blink about what it's like. Minimum number of plugins They managed to create a page. And while I know it's irrelevant from a customer's point of view (the customer is looking at how it works, not how many plugins it has), There is a huge difference in my workflow..
That's why I decided: I'll clean the side. I'm off to a clean slate.
The problem of the plugin jungle
36 active plugins He was on the side. That was untenable for me.
What happened? Since people don't usually have time for their own things, I often do too. ‘on the fly’ I've solved things. The result was that what could have been done with custom code with a bit of time, I put in a plugin.
Double standards
Of course, I do not do this for clients – they pay for it, I plan every project thoroughly. But No one pays for my site..
The problem, however, is that This page is what you see for the first time.. If that's bad, they don't vote for trust anymore.
That's why I forced myself to go through every little thing and Clean the Page Thoroughly.
Choosing the right stack
The end result? I reduced the number from 36 plugins to 21 – and I want to reduce it further in the future.
What did I keep?
Only plugins that:
- They provide real functionality (cannot be replaced by simple code)
- Actively developed and supported
- Optimized for performance
What's left?
Of these 21, 6 have one. Free and a pro version. The free version is required for pro to work – chess is matte. But the point is, what I know, I'm still going to liquidate.
Code cleaning: From BEM to Utility classes
I have run into it several times "how" – I wanted the code to be as clear as possible.
CSS framework switching: Automatic CSS → Core Framework
Previously on all projects Automatic CSS I used it. Now, however, the the Core Framework I switched. Why is that?
- I wanted to immerse myself in it exercise consciously
- Easier to set up the important things
- Seems "easier" – Clearer structure
BEM Naming Convention
I followed it during development. the BEM Naming Convention (getbem.com/namingIt worked very well on the first two pages.
But after page three, I realized: There will be a lot of repetitive elements on the site, because a little more sales I wanted the wording – a lot of recurring formulas, the same layouts, the same sections.
Utility Class approach
That's why I switched: I started thinking in Utility classes (Tailwind CSS Philosophy).
Why is that good?
The Core Framework specifies the basic settings:
- Spacing
- Padding, margin
- Font size
- Colors
- etc.
But my My recurring elements don't require separate classes on each page.
Template Bundle approach
I made a template bundle, which practically means:
- I created all layouts on one page (arrangement) what you need on the entire website
- I set everything up at class level – colours, dimensions, spacing
- That's what gave me the whole page. ‘stuffed up’
Thanks to global Utility classes If I wanted to change something, I just I rewrote it at 1 place, class level – and voilà, the spell was done.
Outcome: 107 Utility class
I build all sides with this approach, but here the goal was to Minimize all CSS classes and thus the size of the code base.
I ended up with 107 Utility classes., With which I covered the whole page.
At the end of the work, the queried and deleted unused CSS classes – making the code even clearer.
Custom Post Types
I use it on my side as well. custom post types:
- References
- Contacts
- Information pages
- Glossary
I fixed these, too. All that's left is what you really need.
Database Optimisation – Unseen Work
Because it's a close 6-Year-Old Page (in 2016, by the way, I just had to completely re-draw it), a lot of plugins, settings, themes, code, cache files and everything else came and went.
The database is quite ‘saturated’ It was.
Manual cleaning
In many cases, cleaning can be done with an extension, but there are cases when the data Eat Yourself Into the Database, It needs to be cleaned manually.
Now, this work is still going on.
I'm thinking of something like this:
- Website Auditor found more CDN broken links, Remaining from an old cache.
- I had to mine and clean them manually.
- Plenty of plugins create folders according to your preference – I had to find out and eliminate them too
The work is still going on. Meticulous, but necessary.
The case of emojis – SVG conversion
I hate emojis. Or at least I hated them until I understood their role.
Many people know, love and use it. The website (technically) does not like.
Why did I want to use them?
Because people Knowing and Recognising Immediately – if they come up to the site, the emojis immediately a familiar sight This can be a good basis of trust.
The technical problem
Yes, but all of them To be uploaded as SVG, because otherwise:
- They may be banned
- Some language plugins don't like to translate them
- It's useless to enter it with the appropriate HTML entity (W3Schools emoji reference)
So you had to upload an SVG version of each one. to the side.
Checkmarks ✓, X-s ⁇ , question marks ⁇ are not replaced everywhere yet... That's a good job.
Linguistics: Polylang → Web-T
Here I would turn to the languageisation on the subject.
Although I work primarily for the Hungarian market, I would like to open a bigger one foreign market towards it. That is why, as in the past, I thought it was important to: Also available in English Let it be the side.
Why did I switch from Polylang?
Previously on Polylang plugin I have solved this, but I do not like ‘classic’ language extensions because Duplicates are created.
Optimal case I need two of everything in the case of a Hungarian-English site:
- Page 2
- 2 pictures
- 2 templates
- Form 2
- 2 all
He's a hell of a job. Even if you do it nicely, you still have to translate the content. It's so boring and time-consuming.
Is it worth it?
Who knows. If suddenly there are two foreign orders that do not pay according to the Hungarian market trends, then maybe. But not like this.
From an SEO point of view? The Hungarian market is already saturated, and the foreign market is booming. So I let go of SEO from that point of view.
I'd rather focus on if a foreign interested party comes in via a contact, You can see what I do and how I do it.
Web-T: The European Union's solution
I wrote it this way because it Developed by the European Union Web-T plugin I use it on the site instead of Polylang.
What's he doing?
- Automatically translates the page
- Moreover, the metadata translates
What don't you translate?
- URLs
- Prices
- Emoji
But he's not so bad at it. Enough to make myself understood by an inquirer – I am better verbally.
For this reason, and because I had little time, I used auto translate, Which saved me a lot of time.
There are still small things on the site (a couple of emoji and forint prices, form) that I have to solve, but The solution is there. For now, it'll be fine.
Lessons learned and next steps
Overall It was a tough ride, But now I feel like doing it.
What did I learn?
- Your own project should be taken seriously. – if you do it right with your customers, why not do it yourself?
- Less plugins = cleaner code No new plug-ins are required for all functions
- Utility classes give you flexibility faster development, easier maintenance
- Database cleaning is a regular task – don’t let it grow
- Automation (e.g. auto translate) saves time – use wisely
What's next?
I will probably come up with more details about the project in the future:
- Performance measurements (before/after)
- Plugin list in detail
- Core Framework Settings
- Detailed description of Template Bundle
I enjoyed it, even if it was hard sometimes.
Do you have questions about WordPress site optimization? Are you in a similar situation? Write to me!
Technical summary:
Results:
- ✅ 36 → 21 plugins
- ✅ Clearer codebase (107 Utility class)
- ✅ Faster admin interface
- ✅ Easier maintenance
- ✅ Multilingual (Hungarian/English) with automatic translation
Technologies used:
- Core Framework (CSS Framework)
- BEM naming → Utility classes
- Web-T (multilingualization)
- Custom Post Types
- Template Bundle approach
