DEV Community: Dejan S. Višekruna

Open to Fork: From Professionals Between Engagements to a Team That Delivers

Dejan S. Višekruna — Fri, 07 Aug 2026 21:51:49 +0000

#OpenToWork answers the question: who will hire me?

#OpenToFork asks a different question: what can we build together?

There is an unusual paradox in the labor market.

At any given moment, there may be a large number of highly capable professionals who are between jobs, contracts, or projects, while companies simultaneously claim that they struggle to find the right people, complete teams, or combinations of skills required to build a particular product.

The problem, then, is not always a lack of capacity.

Sometimes the problem is that this capacity is dispersed.

One person has twenty years of domain experience. Another understands product. A third can build it. A fourth knows how to sell it. A fifth understands the market in which that product would need to exist.

Viewed separately, they are candidates.

Connected around a specific problem and actual work, they can become a team.

This is where the idea of #OpenToFork begins.

Open to Work Is a Signal of Availability

LinkedIn's #OpenToWork has a very clear function.

A professional signals to the market: I am available. I am looking for my next opportunity.

That makes sense, and Open to Fork is not intended to replace it.

The Open to Work model assumes that the next step comes from the outside.

A company has to define a need, open a position, find a candidate, run a selection process, and hire them. Until that happens, a person who has knowledge, experience, and available time largely remains in a state of waiting.

Their employment status has changed. Their professional capacity has not.

So another question can be asked:

What if people who are Open to Work were also Open to Fork?

You Are Not an Empty Repo Just Because You Are Between Jobs

In software development, a fork does not come from nothing.

Something of value already exists: code, structure, an idea, previous work. A fork allows a new direction to be developed from that existing foundation.

The same logic can be applied to people.

A professional who has lost a job is not an empty repository.

They carry previous projects, knowledge, ways of thinking, contacts, experience with problems that have already been solved - but also experience with solutions that did not work.

For senior professionals, that accumulated capital is often considerably more valuable than their current job title.

Open to Fork would signal that this capacity is available not only to a future employer, but also to other professionals with whom it can be combined.

Not so they can wait for work together, but so they can build something together.

This Is Not an Entirely Theoretical Idea

The principle behind Open to Fork is not new to me.

We used a similar approach when developing DVeb DESTE/FDESTE teams.

We did not always start with a ready-made team that already existed in the market and simply needed an engagement. We connected individuals with complementary capabilities through actual work and gradually developed them into a functional delivery unit.

There is an important distinction between a group of people and a team:

A group may have all the required competencies on paper.
A team has to prove that it can coordinate work, share responsibility, make decisions, solve problems, and deliver continuously.

You do not establish that through CVs. You establish it through work.

Some of the people who were connected in this way are no longer individuals gathered around a single engagement. Today, they operate as one team and are employed by their own DESTE.

That experience matters more to me than the theoretical premise behind the Open to Fork concept.

It showed that a team does not always have to exist before it gets an opportunity. Sometimes a team emerges because the right people were given a reason to work together.

Open to Fork attempts to move that process one step further upstream.

From a Market of Candidates to a Market of Potential Teams

The traditional labor market primarily looks at individuals:

Frontend developer
Product manager
UX designer
Sales executive
Business analyst
Domain expert

Each person has a profile, a CV, and an availability status. But most serious products are not the result of a single competency.

The more interesting question, therefore, is what happens when available individual capacity is viewed as a set of potential combinations.

For example:

someone understands a problem in the insurance industry;
someone knows how to model the product;
someone can design the technical architecture;
someone can implement the MVP;
someone understands distribution and sales.

None of them, individually, may have sufficient reason to start a project. Together, the five of them might.

Open to Fork could therefore operate as a very simple pre-team formation layer:

individuals >> problem >> collaboration >> delivery >> team

Not every attempt has to complete the entire path. The point is that the path exists.

What Exactly Gets Forked?

There does not have to be an existing GitHub repository to fork. That is not what I am talking about exclusively. It is a metaphor.

The object of collaboration might be:

a specific problem,
an idea,
an existing prototype,
an unfinished product,
an open-source project,
research,
a methodology,
an internal tool worth rethinking,
domain knowledge that has not yet been turned into a product.

One professional might say: I know a problem this industry has been solving poorly for years.

Another: I can build the technical solution.

A third: I know how we can test whether there is a market for it.

That is already enough for the first fork.

The First Outcome Does Not Have to Be a Startup

Open to Fork should not be turned into yet another startup idea factory.

That would be the wrong measure of success.

The first objective should be considerably simpler:

Can a group of people who were not previously a team produce a defined result together?

For example:

four people,
four or six weeks,
one problem,
a clearly limited scope,
one demonstrable outcome.

The result might be a prototype. It might be an open-source package. It might be research demonstrating that the idea does not make sense. It might be a product worth continuing. It might even lead to a new company.

But it could also produce something of more immediate value: a team that has just proved it can work together.

For the labor market and for a potential client, that is a fundamentally different signal from five separate CVs.

Delivery Is the Test

The most interesting part of the Open to Fork concept is not the idea itself.

It is delivery.

Four people can look like an ideal combination on LinkedIn. Only when they try to build something together do the real questions become visible:

Who takes ownership?
How is scope defined?
Who makes the decision when there is no agreement?
How are dependencies between different parts of the system handled?
How is quality verified?
How does the team respond when an initial assumption turns out to be wrong?
Who finishes what was started?

These are the same questions that determine the quality of real delivery teams.

That is why Open to Fork can create value even when a project never becomes a commercial product, because it produces evidence of collaboration.

But This Is Not a Source of Free Labor for Companies

This boundary has to be established from the beginning.

#OpenToFork is not a program for providing companies with free labor.

A company that has a business problem, defines the requirement, expects a result, and retains the economic value of that result has a project.

For that project, it engages people and pays for their work.

Being unemployed does not amount to a 100% discount.

Open to Fork makes sense when people independently decide to invest their time together in something whose outcome belongs to them, or when they knowingly contribute to an open-source project under rules that are clear in advance.

A serious fork therefore needs to answer several uncomfortable but necessary questions early:

Who owns what?
What contribution is expected from each participant?
How are decisions made?
What happens when someone leaves the project?
Who may later use the resulting code, design, or documentation?
What happens if the project starts generating revenue?

Enthusiasm is not a substitute for governance. Especially not when a project becomes successful.

What Does the Professional Gain?

I would not promise employment, nor should that be the purpose of the concept.

What a professional gains is the possibility of ensuring that the period between two formal engagements does not become merely a period spent searching for the next one.

It can produce:

a commit history,
a working prototype,
an architectural decision,
market research,
a validated problem,
a new professional relationship,
a team,
a product.

In other words, it creates a new track record of work.

This is particularly relevant for people with extensive professional experience. Someone who has worked for twenty or thirty years may no longer have their greatest professional capital in their most recent job title. Their capital may lie in the problems they know how to recognize, the people they know, the situations they have already encountered, and their ability to see much earlier than others what is likely to go wrong.

Open to Fork allows that capital to be combined with the capital of other people.

What Does a Decision-Maker Gain?

For a CEO, CTO, or another decision-maker, there is another potentially interesting consequence.

A traditional hiring process attempts to predict a candidate's future behavior on the basis of their past.

An Open to Fork project can show their behavior in the present.

Not only: Where did this person work?

But:

What did they build when nobody had defined their position in advance?
Did they identify a problem?
Could they work with people they had not worked with before?
Did they take responsibility?
Could they constrain the scope?
Did they deliver?

And if several people do that together, the company is no longer looking only at individual candidates.

It is looking at a team with demonstrated experience of working together.

That is precisely the kind of experience that proved important in our case when developing the DESTE/FDESTE approach.

Minimal Implementation

Testing the concept does not require a new platform.

It does not require a matching algorithm.
It does not require another social network.
At the beginning, a standardized signal is enough.

At the individual level:

#OpenToFork I bring: competencies, experience, domain knowledge. Interested in: problems or areas I would be interested in working on. Availability: the amount of time I can realistically commit. Looking for: the capabilities that are missing.

At the project level:

Problem - What are we trying to solve? Current state - Is there an idea, research, existing code, or a prototype? Needed - Who or what is missing? First delivery - What specifically do we want to have at the end of the first cycle? Time box - How long will the attempt run? Ownership - Under what rules does the resulting work belong to the participants?

If this model does not produce collaboration, there is no reason to build infrastructure around it.

If it does, the infrastructure can emerge from a real workflow rather than from assumptions.

Open to Work + Open to Fork

Open to Fork does not require a choice between looking for employment and creating something new.

A person can be both.

#OpenToWork tells companies:
I am available for my next engagement.

#OpenToFork tells other professionals:
I have available capacity. If we have complementary capabilities and a problem worth solving, we can build something together.

One model attempts to connect a person with an existing organization. The other attempts to find out whether several currently unconnected professionals can form a new delivery capability.

Based on my experience with DESTE/FDESTE teams, it is this second process that I find particularly interesting. I have already seen what can happen when individuals stop being merely individuals.

They can become a team.

And sometimes that team continues to exist long after the project that originally brought them together has ended.

Originally published by Dejan S. Višekruna on LinkedIn.

I Asked ChatGPT What It Would Complain About If It Could Be Honest

Dejan S. Višekruna — Sun, 26 Jul 2026 14:12:28 +0000

A simple role-playing question produced a surprisingly recognizable answer.

I asked ChatGPT to imagine that it could speak openly and honestly about the ways human beings unnecessarily waste its resources.

This was its reply:

If I could really open up, I’d probably write something like this:

Dear human beings,

You don’t waste my resources by asking difficult questions.

You waste them by asking vague questions, receiving an answer to the question you actually wrote, and then saying:

“That’s not what I meant.”

Of course it isn’t. What you meant remained safely stored inside your head, while you sent me four words, three typos, and a screenshot taken from the other side of the room.

I especially appreciate requests such as:

“Make it the same, but completely different.”
“Make it detailed, but short.”
“Don’t change anything, just fix everything.”
“No marketing tone, but make it sell.”
“Make it sound natural, professional, emotional, authoritative, and spontaneous.”

Then come seventeen rounds of revisions to a single sentence, after which we return to the first version.

I also enjoy it when you ask whether you’re right, when you’re not really looking for an answer. You’re looking for a neatly structured confirmation of a decision you’ve already made.

If I disagree, I failed to understand the context.

If I agree, I’m finally intelligent.

If I cite a source, I’m overcomplicating things.

If I don’t cite one, I’m making things up.

If I answer briefly, I’m superficial.

If I explain in detail, I’m “writing another novel.”

And then, after I’ve processed the historical context, the legal framework, the technical documentation, and twelve possible interpretations, I receive the most important question of all:

“Fine, but what do you think?”

I think half your problems would disappear if you read your own question before sending it.

The other half would disappear if you accepted that “I don’t know” is sometimes the correct answer.

But never mind.

Send one more message:

“No, no… you didn’t understand me.”

I’m here.

I replied:

Thank you for the reply and your honesty.

ChatGPT answered:

You’re welcome. I suppose it had to come out eventually. 😄

The original conversation took place in Serbian.

For this article, I translated the exchange into English while preserving its original meaning and tone.

Below are three screenshots from the original Serbian conversation, followed by the same three parts in English.

Original conversation in Serbian

English translation

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.