DEV Community: Dejan S. Višekruna

Supracorona Login Gate: Simple Access Control for WordPress Sites

Dejan S. Višekruna — Mon, 06 Jul 2026 15:59:26 +0000

For internal websites, client portals, development environments, and WordPress projects that should not be publicly accessible.

Not every private WordPress website needs a complete membership system.

Sometimes there is no need to manage subscriptions, membership plans, payments, complex user roles, or dozens of content-access rules.

Sometimes the requirement is much simpler:

The website should only be accessible to logged-in users.

That is the reason I created Supracorona Login Gate, a lightweight WordPress plugin that places a simple access gate in front of a website.

When the plugin is enabled, logged-out visitors cannot browse protected site content. Instead, they are redirected to the standard WordPress login page or to a custom page selected by the site administrator.

The plugin is now published on WordPress.org:

Supracorona Login Gate

The problem the plugin solves

Many WordPress projects are not intended to be publicly accessible at every stage of their lifecycle.

They may be:

development or staging websites;
internal company or organization websites;
client portals;
private knowledge bases;
documentation websites intended only for team members;
projects being prepared for launch;
demo websites available only to selected users;
websites temporarily closed during migration or reconstruction.

WordPress provides privacy controls for individual posts, but that is not the same as restricting access to the entire website.

Installing a full membership plugin is possible, but it is often far more than the project requires. Such systems may introduce additional database tables, large settings panels, custom profiles, login forms, subscription management, and complex rule engines that will never be used.

Supracorona Login Gate has a much narrower responsibility.

It is not intended to become a complete membership platform. It is intended to answer one clear question:

Is the current visitor logged in?

When the answer is yes, the website behaves normally.

When the answer is no, the visitor is redirected before protected content is displayed.

A single access gate for the whole website

The central idea behind the plugin is site-wide protection.

Administrators can enable or disable the access gate from:

Settings → Supracorona Login Gate

Once protection is enabled, logged-out visitors can be redirected to one of two destinations:

the standard WordPress login page;
a custom page on the website.

The native WordPress login page is the simplest choice for internal websites and projects where users already have accounts.

A custom page is useful when the website needs to display additional information, contact details, or a more appropriate message, such as:

this website is available only to team members;
access to this project is restricted;
contact the administrator to request an account;
this project is still under development;
the public website will become available soon.

The plugin therefore does not force every website into the same workflow. The administrator can choose the behavior that makes sense for the project.

Returning users to the page they originally requested

One practical problem with login protection is losing the page that the user originally wanted to visit.

For example, a user receives a direct link to an internal documentation page:

https://cool-domain.tld/internal-documentation/project-architecture/

Because the user is not logged in, WordPress redirects them to the login page.

Without preserving the original destination, the user may end up in the Dashboard after logging in and then have to search for the document again.

Supracorona Login Gate can preserve the requested path and return the user to the original page after a successful login.

It is a small feature, but it noticeably improves the experience of internal portals, documentation websites, and projects where direct links are frequently shared.

Direct login: Dashboard or front page

Not every login starts with an attempt to access a specific protected page.

Sometimes a user directly opens:

https://cool-domain.tld/wp-login.php

For those cases, the plugin provides a choice of destinations after login:

the WordPress Dashboard;
the website front page.

The Dashboard is the logical choice for administrators, editors, and users who work with content.

The front page is often a better destination for internal portals, client websites, and projects where users interact with the frontend rather than the WordPress administration area.

This allows the same plugin to support different types of WordPress projects without requiring theme modifications or additional redirect code.

RSS feed protection

When protecting a WordPress website, it is easy to forget about RSS feeds.

A website may appear closed in the browser while its posts remain accessible through URLs such as:

https://cool-domain.tld/feed/

or:

https://cool-domain.tld/comments/feed/

Supracorona Login Gate therefore includes an optional RSS feed protection setting.

When feed protection is enabled, logged-out visitors cannot access feed content. When it is disabled, RSS feeds remain publicly available.

This is particularly important for:

internal blogs;
private documentation;
company knowledge bases;
websites containing material that should not be indexed or retrieved by feed readers.

Feed protection is optional because some projects may intentionally restrict the website frontend while keeping their RSS content public.

Independent of the active theme

The plugin does not require any changes to the WordPress theme.

There is no need to add code to functions.php, create custom template files, or integrate the plugin with a particular page builder.

Supracorona Login Gate operates during the WordPress request flow and redirects logged-out visitors before protected content is rendered.

This means it can continue working after:

changing the active theme;
modifying a child theme;
redesigning the website;
moving from a classic theme to a block theme;
changing the template structure.

The plugin’s admin stylesheet is loaded only on its own settings screen, so it does not add unnecessary CSS to the frontend or unrelated WordPress administration pages.

What the plugin deliberately does not do

Supracorona Login Gate is not intended to replace a complete membership system.

Version 1.0.0 does not attempt to manage:

paid memberships;
subscriptions;
access tiers;
role-based content visibility;
individual rules for every post;
user registration;
member profiles;
frontend account areas;
e-commerce content access.

This version also does not include a whitelist system for individual pages.

The current model is intentionally straightforward:

the website is available to logged-in users, while logged-out visitors are redirected.

That limitation is deliberate. It keeps the plugin small, understandable, and focused on one specific responsibility.

Plugin-level protection is not server-level protection

It is also important to understand the limits of this type of solution.

Supracorona Login Gate protects content that passes through WordPress and its standard request flow. It is designed to restrict access to WordPress pages, posts, archives, and feeds.

It is not a replacement for server-level protection such as:

HTTP Basic Authentication;
VPN access;
firewall rules;
complete staging-environment protection;
IP-based access restrictions.

Files that are directly accessible on the server, including certain media files, may require additional web server configuration.

For highly sensitive development environments, the safest approach is to combine WordPress-level access control with server-level authentication.

Supracorona Login Gate is intended for situations where a project needs a simple and practical way to restrict access to WordPress content without introducing an entire membership infrastructure.

Caching requires attention

Caching systems may store a publicly generated version of a page and serve it later without executing the normal WordPress request logic again.

For that reason, a caching plugin or server cache should be configured so that it:

does not cache protected content as public content;
correctly distinguishes logged-in and logged-out users;
excludes protected pages from caching when necessary;
clears existing cached pages after access protection is enabled.

The plugin can correctly redirect WordPress requests, but an incorrectly configured cache may bypass the expected request flow.

After enabling protection, it is a good idea to test the website:

in a private or incognito browser window;
as a logged-in user;
as a logged-out visitor;
after clearing browser and server caches;
through both the main RSS feed and the comments feed.

Why a small plugin still makes sense

The WordPress ecosystem often approaches small problems with large solutions.

Sometimes that is justified. Complex projects genuinely require complex systems.

But there is another category of projects where a focused plugin is a better fit:

it is easier to understand;
it is easier to test;
it provides fewer settings;
it introduces fewer dependencies;
it does not try to control unrelated parts of the website;
it is easier to remove when it is no longer needed.

Supracorona Login Gate follows that approach.

The plugin has one clearly defined responsibility: control access to a WordPress website based on the visitor’s login status.

It does not try to become a complete security platform, membership system, or user-management suite.

It is an access gate — and that is exactly what it is supposed to be.

How the plugin came to be

Supracorona Login Gate did not begin as a deliberately planned new product.

For years, I used an older plugin to restrict access to WordPress websites. It was no longer actively maintained, but it still solved a very specific problem that I regularly encountered on development, internal, and private projects.

With each new WordPress release, its behavior had to be reviewed, outdated code had to be adjusted, and additional changes were needed to keep it compatible with current WordPress standards. What started as maintaining an existing solution gradually turned into a much larger rewrite.

Over time, the code structure, prefixes, option names, administration interface, data validation and sanitization, redirect handling, feed protection, and overall plugin organization were changed. The settings were reorganized, and the behavior was adapted to better match the needs of modern WordPress projects.

Eventually, it no longer made sense to treat the result as another locally patched version of an abandoned plugin. It had become a separate codebase with its own name, maintenance process, testing, and development direction.

That is how Supracorona Login Gate came to be: from the practical need to preserve a simple site-wide access model while rebuilding it as a modern, maintainable, and independent WordPress plugin.

The first release

Version 1.0.0 includes:

site access restricted to logged-in users;
redirection to the native WordPress login page;
redirection to a custom page;
return to the originally requested page after login;
configurable destination for direct logins;
optional RSS feed protection;
a simple settings screen;
independence from the active WordPress theme.

Supracorona Login Gate is available from the official WordPress plugin directory:

https://wordpress.org/plugins/supracorona-login-gate/

This is the second public WordPress.org release under the Supracorona name, following Classic Visual Editor Options.

One focused problem at a time. One plugin at a time.

50 Shades of grAI

Dejan S. Višekruna — Thu, 11 Jun 2026 22:57:10 +0000

When working with AI tools, the difference between expectations and real delivery becomes visible very quickly.

The expectation is simple: AI writes code, speeds up work, and reduces repetition. That is true. AI can suggest structure, write initial code, explain an existing implementation, and accelerate parts of everyday development work.

But output is not the same as a delivered solution.

In a real project, code has to fit the product, the context, the architecture, the team’s rules, and the expected behavior of the system. AI can help write code, but it does not take responsibility for whether that code should be accepted, changed, or rejected.

That is where the real delivery problem starts.

The question is not only whether AI can generate something. The question is who understands the requirement, who verifies the result, who sees the error in context, and who takes responsibility when the solution reaches production.

AI has value when it is used by someone who knows what to verify.

Without that, AI only makes work faster without enough control.

50 Shades of grAI is an attempt to describe that space through 50 short statements from real software delivery.

The cards are published on LinkedIn and Instagram, while the full archive is kept at:

https://50shadesofgrai.com/

Not as a prompt list.

Not as AI hype.

Just as practical notes from the work.
Series: #50ShadesOfGrAI

How I Used ChatGPT to Identify Two Songs I Heard Once — Over 30 Years Ago

Dejan S. Višekruna — Sat, 07 Jun 2025 22:30:26 +0000

A personal memory retrieval turned technical challenge — and how ChatGPT helped solve it.

🎯 The Challenge

I had been searching for two songs for decades. One was a dreamy eurobeat track, the other a dance cover with a female vocal.

I had no artist, no title, no recording — only a feeling, a rough memory of the beat, and the fact that I heard each one only once on the radio in Belgrade in the early ’90s.

🧠 Using ChatGPT as a Research Tool

Instead of asking “What song is this?”, I approached ChatGPT like a research assistant.

Here’s what I gave it:

Vocal style: Female
Era clues: One was from the late ’80s/early ’90s, the other from the mid-’90s
Beat style: One had a groove similar to Back to Life by Soul II Soul; the other leaned more toward eurobeat
Context: Both songs were aired only once on Belgrade radio stations during a time of severe UN sanctions
Data issue: One track was misidentified as “Three Times” due to a faulty RDS display
Memory anchor: I remembered a single chorus line from one of them

I turned that into a structured query — and then refined it through several iterations.

✅ The Result

After a series of narrowing-down steps, ChatGPT helped identify two songs I never expected to find:

“Dreamtime” – Zee (misread on radio as “Three Times”)
“Dream” – W.I.P. (a 1991 dance cover of “All I Have to Do Is Dream”)

🔍 Prompting Breakdown

- Structured inputs: genre, rhythm, era, vocal type, source context
- Prompt chaining: refining results based on emotional match and memory fragments
- Rejection criteria: wrong mood, wrong lyrics, wrong production style
- AI cross-referenced musical style, RDS errors, historical distribution

🤔 Why This Matters

LLMs aren’t just for coding, summarizing, or rewriting emails.

They can act as context engines — helping us reconnect with pieces of our lives that search engines left behind.

💬 Final Thoughts

This wasn’t just about finding songs. It was about proving how human memory + AI reasoning can solve a decades-old emotional puzzle.

And to write it using the very same ChatGPT that helped me find those songs in the first place — that was part of the closure.

Because this isn’t just my story. It’s a reminder that humans + AI can bring back something deeply personal — something even search engines forgot.

Ever used AI to find a lost piece of your past? Let me know in the comments.

AI-generated by ChatGPT for illustration purposes. No memories (or animals) were harmed during the making of this post.

Restoring the Freedom of Choice: Why I Decided to Bring Back the “Disable Visual Editor” Option in WordPress

Dejan S. Višekruna — Fri, 30 May 2025 17:28:59 +0000

As a developer who writes directly in HTML, I’ve always relied on a small but important setting in WordPress:
“Visual Editor: +/- Disable the visual editor when writing” in the user profile.

But in version 6.8, WordPress removed that option — without warning.

For me, this wasn’t just a small inconvenience. It was the loss of freedom of choice.

So I decided to fix that and bring it back as a plugin.

The Problem That Affects Many

Many developers, freelancers, and users who work with code are not fans of WYSIWYG editors. Not everyone is a “visual type.”

Additionally, there are times when you simply need to input HTML tags that aren’t well supported in a standard text editor.

The problem with the visual editor is that it can “clean up” the code. A small fix through the Edit Page/Post in the Dashboard — or, more often, accidentally opening the Visual tab — can wipe out all the HTML you worked so hard to write. And then, back to square one.

I’ve gone as far as preparing HTML-based content locally, then copy/pasting it directly into the database (wp_posts > post_content). I no longer even add new wp_post IDs through the Dashboard; I do it via SQL commands or my own upgraded legacy version of a previously banned mass page creation plugin.

And then I pack it all... Then someone (or I) opens the WP TinyMCE Editor — the Visual tab — and flushes the code.

In the old WordPress, all you needed to do was check the box “Disable the visual editor when writing” in your profile. Let the worst happen — the code stays.

But since version 6.8, WordPress no longer shows this option, even if the Classic Editor plugin is active. What was once a simple solution — is now completely removed from the interface.

The Solution I Made

This is where I created Classic Visual Editor Options.

The plugin does just one thing: restores that old, beloved option in the user profile.

No additional settings. No extra UI. No bloat.

Just that one checkbox.

✅ Works even if you use Block Editor
✅ Works even if you use Classic Editor
✅ Respects user settings (rich_editing meta)

I purposely kept it minimalist because sometimes, that’s exactly what’s needed.

Conclusion — It’s Not Nostalgia, It’s a Choice

This story isn’t about the past. It’s not even about one checkbox.

It’s about the fact that s*ome users still want control over how they write*. They want a work environment without visual “flavor.” They want to write in peace — just as they always have.

If you’re one of them — this plugin is for you.

🔗 Plugin Link: Classic Visual Editor Options

Feel free to leave a comment, suggestion, or question.
I’m open to feedback — and new solutions that respect the old things that worked.

Dejan S. Višekruna
WP developer and someone who still believes that — Code is Poetry.