There is something strange happening in modern software development…
We keep building increasingly sophisticated applications, but somehow, making them run is becoming increasingly complicated.

You need a framework… Then a package manager… Then a dependency manager for the package manager… A database server, a cache server, a queue worker, a build pipeline, a collection of extensions, a dozen environment variables, and occasionally a small sacrifice to the infrastructure gods….

And after all that, you can finally display a page saying “Hello World“.

Congratulations!

But what happens when you just want to install a piece of software on your own hosting account and use it? What happens when your hosting provider doesn’t give you SSH access? When you cannot install system packages? When Redis isn’t available? When ImageMagick is disabled? And why should you need another monthly subscription just to perform a task that should be relatively straightforward?

At ScriptNet Solutions, we’re a small software house. We don’t have an army of developers, dedicated infrastructure teams or unlimited resources. Perhaps that’s precisely why we’ve learned to question things that larger development environments sometimes take for granted.

Our philosophy has gradually become quite simple: Keep It Simple & Standalone.

Not because dependencies are inherently bad. Not because frameworks are useless. And certainly not because reinventing everything is always a good idea. But because every dependency introduces a responsibility, every additional infrastructure requirement creates a potential obstacle, and every unnecessary abstraction has a cost.
Sometimes, the smartest engineering decision is not adding something: it’s removing it.

The Framework Paradox

Let’s start with something that might upset a few developers: our primary development stack is PHP and JavaScript.

Yes, PHP.

That supposedly dead language. The one that has been declared obsolete approximately seventeen thousand times over the last fifteen years. Funny thing is, it still works remarkably well. With PHP handling backend operations and JavaScript taking care of client-side interactions, you can build practically anything required by a modern web application. We deliberately avoid making our products dependent on large frameworks.

Why?

Because we’d rather spend time solving a specific problem than fighting an entire framework because it wasn’t designed to handle that particular requirement. Does this require more work?

Absolutely.

You need to understand what you’re building. You need to pay attention to security, establish consistent architectural rules and make sure every component does exactly what it’s supposed to do. There is no magical framework protecting you from poor engineering decisions. But when you get the architecture right, something interesting happens.

You can build a spaceship with 1,000 carefully designed lines of code instead of assembling a delivery van with wings using 10,000 lines of unnecessary abstraction.

The point isn’t that fewer lines automatically mean better software.
The point is that complexity should exist because it solves a real problem, not because your technology stack introduced it. And here’s another advantage of using a mature language like PHP: an enormous ecosystem of existing libraries.We are not reinventing everything.
We use established tools whenever they make sense. Sometimes we customize them, sometimes we adapt them, and sometimes we develop dedicated components because existing solutions introduce more complexity than they remove.

That’s the difference between choosing a tool and becoming dependent on it.

The Hidden Cost of Something Free

An open-source library might cost absolutely nothing to download.
But that doesn’t mean it’s free.
Every external dependency introduces a relationship that somebody must maintain. Updates, compatibility, security vulnerabilities, abandoned projects, breaking changes and additional infrastructure requirements; and sometimes, the biggest problem isn’t even the library itself. It’s everything required to make that library work.

A relatively simple PDF processing operation might require ImageMagick, specific system packages, additional PHP extensions and server permissions that your hosting provider may not offer.

Suddenly, a straightforward application feature becomes an infrastructure deployment problem.
For a large enterprise with a dedicated DevOps department, this might be perfectly acceptable.
For a small business, an independent developer or somebody running a website on shared hosting?

Not so much.

We don’t believe that every application should require an infrastructure department just to perform its basic functions.
And we certainly don’t believe that users should pay for infrastructure they don’t actually need.

Your Browser Is More Powerful Than You Think

One of the most interesting changes in our development philosophy has been recognizing that the server doesn’t necessarily need to perform every operation. Modern browsers are surprisingly capable environments. Why consume server resources when the user’s browser can perform a task perfectly well? This simple observation has allowed us to remove several mandatory server-side requirements from our products.

PDF previews without mandatory ImageMagick

But if you’ve ever tried to process PDF documents on shared hosting, you’ve probably encountered its security policies.
Many hosting environments restrict PDF processing by default. You might have ImageMagick installed but still be unable to use it for PDF conversion. And enabling the required functionality could mean SSH access, administrative privileges and server configuration changes.

We decided that PDF preview generation shouldn’t depend on all of that.

Dokky uses PDF.js to allow the uploading user’s browser to generate document previews. ImageMagick remains available as an optional tool where the environment supports it.
The difference? A missing server-side dependency no longer prevents the core workflow from functioning.

OCR without outsourcing your documents

Extracting text and metadata from uploaded documents can significantly improve search capabilities and document organization; external OCR services are certainly an option. But they introduce API dependencies, usage restrictions and potentially significant privacy considerations. Do you really want to upload every document to a third-party service just to extract some text?
Dokky uses a self-hosted version of Tesseract.js. The browser performs the OCR processing locally, and the extracted information is sent back to Dokky for storage.

No mandatory server-side OCR installation.
No compulsory external OCR subscription.
And once that metadata is available, other functionalities can build on it: for example, AI-powered document summaries and audio summaries.

TTS: less is sometimes more

We also approached Text-to-Speech differently: we didn’t set out to build another audiobook platform. That’s not the problem we wanted to solve.
Imagine searching through hundreds of documents. Opening every PDF just to understand whether it contains the information you’re looking for is inefficient and very boring.

What if you could understand the content in approximately twenty seconds?

Dokky uses AI through OpenRouter to generate short summaries of up to 200 words, which are then converted into audio and stored locally as MP3 files. The result is available during document searches and can also be used by Forum Autopost.
It’s not about turning every document into an audiobook.
It’s about helping users answer one simple question: “Is this the document I’m looking for?”
And doing so without opening it.

Self-Hosted Doesn’t Mean Expensive-Hosted

This is probably where our philosophy becomes most evident. We believe self-hosted software should mean something different from what the industry has gradually made it become.

Self-hosted shouldn’t mean:

– Buy an expensive VPS.
– Configure SSH access.
– Install Composer and system packages.
– Set up Redis.
– Configure additional services.
– Spend an afternoon resolving server compatibility issues.

And then, perhaps, install the application.

No.

If you need to purchase infrastructure costing as much as a Porsche lease just to run a document management application, something has gone terribly wrong.

We deliberately avoid making tools such as Composer, SSH, Git, Redis or ImageMagick mandatory requirements for Dokky’s core installation.

The installer itself is deliberately simple and boring: three steps.

Step 1 – Environment Check

Dokky checks the essential requirements, including PHP, mod_rewrite, cURL, PDO and SQLite.

Step 2 – Database Configuration

Enter your MySQL credentials.

Step 3 – Administrator Account

Create your administrator account.

That’s it.

No command-line installation procedure. No dependency compilation. No package manager gymnastics. And we actually tested something that many developers might consider slightly ridiculous. We installed Dokky on InfinityFree…

Yes, that InfinityFree.

One of the most restrictive shared hosting environments you can find. Almost everything worked:
PDF/A-3b publishing, document merging, private groups, forums, AI integration, IPFS, P2P distribution and much more. We did identify an issue with image insertion in Forum comments, apparently related to limitations in that hosting environment.
But the broader experiment demonstrated exactly what we wanted to prove: a properly designed application doesn’t necessarily need an expensive server to deliver sophisticated functionality.

Of course, performance and capacity still depend on available hosting resources; we’re not suggesting that free hosting is suitable for every production workload. But the fact that the platform can operate in such a restricted environment says something about the architecture. Software should adapt to the infrastructure whenever reasonably possible. Not the other way around.

Efficiency Doesn’t Mean Putting Everything in One Box

Here’s another common misconception.

Efficiency doesn’t necessarily mean putting everything inside one centralized system. Sometimes, the opposite is true.
We deliberately separate responsibilities, even when that means maintaining multiple small databases or independent components. Dokky has an extensive caching system, but it doesn’t require Redis. Instead, it uses dedicated SQLite databases for different caching responsibilities.

Why?

Because different components have different workloads, different requirements and different maintenance needs.
Our approach is to keep these responsibilities isolated rather than introduce a centralized service that becomes another mandatory infrastructure requirement. Static assets, audio summaries, QR codes, IPFS gateway URLs, OCR results, cookie consent and general system caching don’t necessarily need to share the same storage mechanism.
Even WebWall, our standalone security product, follows this philosophy with four dedicated SQLite databases.

We don’t believe that putting everything into one database automatically makes an architecture more efficient. Sometimes, separating responsibilities is precisely what makes everything more predictable. And no, you don’t need Redis just because your application has a lot of features; You need a caching strategy that makes sense for your application.

External Services Should Extend, Not Complicate

Are we against external services? Absolutely not.

That would be rather hypocritical.
Some technologies are better handled by dedicated services, and there is no reason to reproduce an entire infrastructure stack inside an application just to avoid using an API. The important thing is how you integrate them.

SneakPeek: external capabilities without mandatory infrastructure

Dokky includes URL-to-PDF functionality through SneakPeek, another ScriptNet product. SneakPeek is a standalone application built around Node.js and Puppeteer Cluster.

Running it independently requires a more capable server environment than running Dokky itself. We could have made Node.js and Puppeteer mandatory requirements for every Dokky installation. But why?

Instead, Dokky communicates with a dedicated SneakPeek endpoint through JWT authentication. When purchasing Dokky, users receive access to a limited free service, allowing up to ten requests per day. Those requiring higher capacity or additional PDF customization can purchase SneakPeek or access a dedicated installation. The functionality is available without forcing every administrator to deploy and maintain additional infrastructure. That’s how we believe external integrations should work: they should extend capabilities, not unnecessarily complicate the installation.

OpenTimestamps: solving a problem without adding another dependency

Another example is Bitcoin OpenTimestamps integration.
We wanted native document timestamping through OpenTimestamps, but we couldn’t find a suitable PHP implementation for the workflow we needed. Rather than introducing another mandatory runtime dependency, we implemented a dedicated integration through SneakPeek.

Dokky can request cryptographic timestamping of document hashes, receive the initial proof and subsequently retrieve the completed proof once the corresponding Bitcoin transaction has been confirmed. The document itself doesn’t need to be transferred to the external service. Only the cryptographic hash is required for the timestamping operation.

It’s another example of a simple principle: When an external capability is necessary, isolate it behind a clearly defined interface. Don’t make the entire application dependent on its internal implementation.

Modular Software. Modular Experiences

Now we get to something that, in our opinion, is just as important as reducing technical dependencies.
Modularity shouldn’t stop at the source-code level. It should extend to how people actually use the product. A platform with dozens of features shouldn’t force administrators to enable and use all of them.
Why should it?

Imagine three completely different scenario.

A company looking for a private document portal.

It needs document management, private groups, PDF publishing, WebWall and OpenTimestamps.
It doesn’t need public registrations or a community forum.

A community of people sharing recipes.

They want document publishing, a forum, AI assistance, IPFS and P2P distribution.
They don’t necessarily care about all the other document-management capabilities.

A group of football supporters.

They simply want a community where friends can discuss matches, players and everything happening every Sunday.
They can disable the document-related functionality and use Dokky essentially as a forum platform with a funny AI Powered User.

Same installation. Different configurations. No need to maintain three separate products.

The Anti-Panic configuration

Of course, giving administrators dozens of independent configuration options can become intimidating.

That’s why Dokky includes an initial configuration interface with predefined usage presets.
Instead of presenting an inexperienced administrator with a wall of switches and configuration options, we offer macro-configurations designed around common use cases.

– Choose the intended usage.
– Apply the preset.

The relevant functionality is configured automatically. And if you want to customize everything later, you can.
We like to call this the Anti-Panic approach. Complexity should be available when needed, not imposed during installation: You shouldn’t have to understand every feature of a platform just to start using the three features you actually need. This is what functional modularity means to us.

Independent components internally, independent functionality externally. A module can be enabled or disabled according to the needs of the installation; the platform adapts to the user, not the other way around.

We Don’t Sell Infrastructure. We Sell the Result

After all these examples, we should probably clarify something:

We aren’t trying to eliminate every external library.
We use established libraries such as PDF.js, SweetAlert, Sortable.js and others whenever they provide real value.
We integrate external services when they make technical and economic sense.
We use AI providers, IPFS providers and specialized services when they solve problems more effectively than building everything ourselves. The objective isn’t ideological purity: it’s engineering pragmatism.
We want to build software that:

• Doesn’t require unnecessarily expensive infrastructure
• Doesn’t force users into recurring subscriptions for basic capabilities
• Doesn’t require advanced server administration just to get started
• Keeps user data under the control of the people who own it
• Uses external services only when they provide a genuine advantage
• Remains modular, maintainable and adaptable

And most importantly, we want users to spend their time using software rather than maintaining the infrastructure required to run it. There is nothing wrong with powerful frameworks, sophisticated server environments or large cloud infrastructures. But they should be choices, not automatic prerequisites.

– A small business should be able to install a document management platform without hiring a DevOps engineer.
– An independent developer should be able to deploy an application without first assembling an infrastructure ecosystem.
– An organization should be able to own its software environment without becoming dependent on an endless collection of SaaS subscriptions.

That’s why we keep questioning dependencies. That’s why we keep removing unnecessary requirements. And that’s why we keep investing in modular architecture. Keep It Simple & Standalone.

Not because simplicity means doing less; but because good engineering means making complicated things work without making them complicated for everyone else.

So, why bother building everything yourself?

Well, you don’t have to.

You could spend months developing a document management platform, implementing PDF publishing, building private collaboration tools, integrating AI, configuring decentralized storage, developing security mechanisms and creating a complete community system.
You could also spend another few months maintaining all of it.

Or…

You could simply use something that already exists.
Dokky Suite brings document management, publishing, collaboration, security, AI and decentralized distribution together in one modular, self-hosted platform.

Configure what you need. Disable what you don’t. Keep control of your installation and your data.
No unnecessary infrastructure. No mandatory SaaS subscriptions. No need to reinvent the wheel.
And if you don’t feel like spending your weekends building and maintaining all of this…
Why bother building it when it’s already done? Get Dokky.

ScriptNet Solutions · Keep It Simple & Standalone.
Discover Dokky Suite – Live Demo
Get now Dokky Script – 20% Off

 

WebWall 2.3, Venkman Edition, takes a wider look at that problem.

This release introduces a new analysis engine for low-and-slow distributed activity, improves the way WebWall evaluates system pressure, and strengthens the connection between local detection and Cloudflare native enforcement. It also makes those decisions easier to follow, with a more informative dashboard, recent suspicious-path events, and an IP investigation view that brings activity, scoring, and enforcement history together.

The theme is context: understanding not just what a request looks like, but how it fits into everything happening around it.

The Attack That Does Not Look Like a Spike

Traditional per-IP scoring answers an important question:

“What has this visitor been doing?”

If an address repeatedly probes sensitive paths or sends suspicious payloads, its history gives WebWall something concrete to act on.
But distributed activity changes the shape of the problem.
Instead of one client making hundreds of requests, many clients can make only a handful each. Individual scores remain modest while the combined activity creates persistent pressure.

WebWall 2.3 adds another question:

“What are these visitors doing together?”

The new subnet analysis engine examines a rolling three-hour traffic window, looking for patterns across network ranges rather than treating every address as an unrelated visitor. A pool of addresses producing relatively little activity per IP can now become visible as a collective pattern. This is not a replacement for individual scoring. It is the missing perspective between a single visitor and the overall traffic graph.

A Shared Network Is a Clue, Not a Conviction

Grouping addresses is only the beginning.
A mobile network can produce traffic from many legitimate users. A hosting network can carry both ordinary applications and automated abuse. A recognized crawler should not be treated like an unknown client simply because it is busy.

WebWall therefore combines subnet behavior with network classification.

The new ASN reference data, supported by Team Cymru DNS lookups, helps identify the network behind an address. WebWall then applies its own classification and risk weighting:

– Hosting and suspicious proxy classifications increase the weight of suspicious behavior.
– ISP and mobile classifications receive a substantial reduction.
– CDN-classified traffic receives a lower weighting.
– Recognized good-bot networks are excluded from this analysis.

The important distinction is that network identity provides context, not an automatic guilty verdict.
WebWall is not designed to ban a provider because it is a provider. It uses network information to interpret the activity it has actually observed. That matters just as much when traffic is legitimate as when it is hostile. A protection system that cannot tell the difference between “many visitors” and “many suspicious visitors” can easily become its own availability problem.

Investigate in the Background. React on the Next Request

A broader view should not require a full historical investigation every time someone opens a page.
WebWall separates immediate request handling from deeper analysis. The request-time tracker performs local checks, inspects suspicious input, consults cached information, and records activity for background processing.
The background engine consolidates those events, updates scores, evaluates system pressure, and runs subnet analysis.

When that analysis flags a network, it publishes the result to a cache that subsequent request checks can use.

The loop is straightforward:

1. Observe incoming activity.
2. Analyze the accumulated pattern.
3. Update local intelligence.
4. Use that intelligence when the next request arrives.
5. Escalate when the evidence reaches the relevant threshold.

The next request no longer has to be assessed without the benefit of what the previous thousand revealed.

Meanwhile, score decay reduces the influence of older activity over time, allowing the system’s assessment to evolve rather than simply accumulating suspicion forever.

From “Something Is Happening” to “Here Is What Is Happening”

Detection is only half the experience.
The other half is opening the dashboard and understanding the situation without assembling it from several logs and database queries.

The updated WebWall dashboard brings together traffic totals, verified-bot activity, local enforcement counters, Cloudflare edge activity, and a weekly chart showing traffic alongside pressure trends. A dedicated CPU Stress panel puts the server-health signal within the same operational view.
That arrangement helps separate questions that are easy to confuse:

– Is traffic increasing?
– Is suspicious activity increasing?
– Is the server losing processing headroom?
– What protective actions are already in place?

Those are related questions, but they are not interchangeable.
A higher traffic count alone does not explain whether the application is dealing with legitimate visitors, recognized automation, repeated probing, or a mixture of all three.
The dashboard gives those signals somewhere to meet.

Recent incidents, without the log hunt

The recent-incidents panel surfaces suspicious path attempts directly beside the main activity view.

In the example shown, requests include WordPress login paths, exposed Git configuration paths, and environment-file locations. Each entry displays the requested path, a masked source address, a timestamp, and the associated score contribution. That turns a general warning into something an administrator can inspect.
Instead of seeing only that “suspicious activity increased,” you can see what clients were actually trying to reach, and how WebWall scored those attempts.

An IP Address Should Come with a Story

Once a particular address needs attention, the next step should not feel like starting the investigation from scratch.

The IP search view brings the relevant information into a single dossier: current status, accumulated score, total hits, last activity, available security logs, decision history, and provider and network information. The surrounding interface provides quick enforcement and whitelist controls, while the activity table refreshes every ten seconds.

This makes the workflow more direct:
Find the address. Review its history. Understand its current state. Take action if necessary.

In the example dossier, the selected address has a score of 141 against a local enforcement threshold of 100, a recorded total of 82 hits, and a local enforcement decision in its history. Those details sit together rather than requiring the administrator to reconstruct the sequence from separate screens. The distinction matters because a score alone rarely answers every operational question:
– Was this address already handled?
– When was it last active?
– Which network does it belong to?
– Is there a recorded decision?

The investigation view gives those questions a shared home.

Local Detection, Edge Enforcement

WebWall observes behavior inside the application’s security flow. Cloudflare provides a place to enforce selected decisions before matching traffic reaches that application.
Version 2.3 extends that connection with support for escalating confirmed malicious network ranges alongside individual IP addresses.
Both can be submitted to the same custom IP list used by the WebWall Cloudflare rule.
That becomes particularly useful when an abusive pattern keeps moving between addresses inside the same network. If the evidence supports a subnet-level response, the enforcement target can represent that subnet rather than chasing every address separately.

But a wider target also demands stronger justification.
Range-level enforcement potentially affects more clients than an individual-IP action. The classification and confidence logic therefore matters as much as the ability to submit the range.

The feature is not “block more addresses with fewer clicks.”
It is “respond at the scope the evidence supports.”

What the Cloudflare Screenshot Actually Shows

The example Cloudflare view contains two distinct challenge rules worth separating.
The WebWall rule references the `$webwall` list and explicitly excludes Cloudflare-verified bots. In the displayed view, it has approximately 46.27 thousand events and a Challenge Success Rate of 0.28%.

That is a useful operational observation: few of the recorded challenges were successfully completed. It is not, on its own, a complete measure of detection accuracy or false positives. Above it sits an example of a separate manually configured rule covering two IPv6 ranges. That rule shows approximately 1.49 million events and a displayed CSR of 0%. Those events belong to the operator’s policy rule—not to WebWall’s automated detections.

This separation reflects an intentional boundary:

– Behavioral detection asks whether observed activity justifies intervention.
– Operator policy decides whether particular infrastructure is welcome at all.

An administrator can choose to challenge traffic from a network even when WebWall’s behavioral assessment would not independently classify it as malicious.

Keeping those decisions separate makes both the automation and the reporting more honest.

Protection That Knows When to Step Back

The release also improves how WebWall decides when broader Cloudflare protection is appropriate.
The pressure assessment combines traffic activity, security incidents, and a server-health signal. The revised CPU stress logic compares a small SHA-256 workload with a stored baseline to help estimate changes in available processing capacity.
That measurement is a signal, not a diagnosis. Reduced headroom does not automatically mean an attack is responsible.

WebWall evaluates it alongside the rest of the activity, while subnet confidence and network classification help avoid interpreting legitimate distributed traffic as sufficient reason for escalation.
When the configured pressure or sustained-distress conditions are met, WebWall can enable Cloudflare Under Attack Mode. When conditions stabilize, it returns the configured security level to Medium. The aim is not to keep the site in a permanent defensive posture.
It is to apply additional protection when the evidence calls for it, and release it when those conditions pass.

The Work Behind the Headline Feature

Low-and-slow analysis is the most visible architectural addition, but version 2.3 also improves the systems around it:

• Refactored request tracking and optimized background decision flow
• Revised CPU stress balancing and Cloudflare activation scoring
• Dedicated storage for low-and-slow analysis metrics
• Updated SQLite indexes
• Improved scheduled-maintenance capabilities and execution flow
• Stronger `.htaccess` path shielding with additional security headers
• Updated frontend translations and the precompiled privacy-policy page
• Minor interface fixes

These changes support different parts of the same job: collecting useful evidence, processing it efficiently, making proportionate decisions, and showing the administrator what happened.

A Wider View of Application Security

WebWall 2.3 does not assume that every attack arrives as an obvious spike, or that every spike is an attack. It connects individual requests with visitor history, subnet behavior, network context, server health, and edge enforcement.

There are limits. Subnet analysis is most useful when suspicious activity shares a network-level pattern. A campaign distributed across unrelated networks may not produce the same signal, and ASN classification cannot establish intent by itself.
But the direction is clear. When a hundred quiet visitors are part of the same problem, looking at them one at a time is no longer enough.

Venkman Edition gives WebWall a wider view—and gives the person running it a clearer one.

Live Demo
Buy WebWall Script v2.3

 

Sorry…but skipping the v2.6.0 review to dive straight into Dokky Suite v2.6.1 was worth it. This release marks one of the most significant updates in Dokky’s history: it solidifies our vision of a document infrastructure that is fully self-hosted, decentralized, and free from the fees and control of proprietary SaaS platforms.

If your goal is total data sovereignty, legal certainty regarding information, and maximum communication privacy, version 2.6.1 is your new standard.

Let us briefly list what these improvements are.

1. Immutable Notarization on the Bitcoin Blockchain (OpenTimestamps)

The major new feature introduced with the 2.6 branch is native integration with Bitcoin OpenTimestamps (OTS).

You can now anchor the timestamp of any document or revision directly to the Bitcoin blockchain, without relying on centralized certifying authorities:

– Official PDF Audit Certificates: Automatic generation of a PDF/A3B audit document containing full metadata, the SHA-256 hash, the IPFS CID, and the .ots timestamp proof.

– Decentralized Live Verification: Users or auditors can verify document authenticity in real-time by querying Bitcoin nodes and OTS calendar servers directly via the public verification interface.

– Admin & User Control: Administrators can enable the service globally, while users can request notarization during the upload or new version creation process.

2. In-App Zero-Trust Chat and “Burn-on-Read” Messages

Security in v2.6.1 takes a major leap forward with a complete overhaul of the internal messaging system:

– Zero-Knowledge E2E Encryption: The private chat integrated into threads now supports client-side encryption (AES). The server only handles encrypted data for which it does not hold the keys. “Burn-on-Read” Messages: Send confidential information with the assurance that the message will self-destruct as soon as it is read by the recipient.

– Decoupled Architecture (ES6): The chat’s frontend logic has been refactored into an isolated ES6 module leveraging HTML5 `data-*` state attributes, significantly improving maintainability and security.

3. Enhanced PDF Engine and Publisher

The internal Dokky Publisher editor and generator receives new tools for document lifecycle management:

– New “Custom” Template: Added a layout option designed to generate even cleaner, minimalist PDF outputs ready for professional printing.

– Voting System Optimization: The document voting system has been rewritten using zero-reload AJAX. Like/dislike aggregations and user status are now resolved via a single database query, drastically reducing network overhead and server execution time.

– Vote Integrity: Introduction of unique voter fingerprinting (a combination of authenticated User ID and a salted IP hash for guests) to prevent duplicate votes or bot activity.

4. WebWall v2.2 “Spengler Edition” Protection and Infrastructure

Protecting the platform is the new release of our native, zero-dependency firewall:

– WebWall v2.2: Updated engine featuring Hive support, optimized database tables, and dynamic DNS blacklists.

– Zero-Reload FAQ & Translations: Multilingual (EN, IT, ES, FR, DE) in-line FAQ modals on public verification pages.

– Compatibility and Performance: Full optimization of system logs and MySQL/SQLite database indexing, plus guaranteed full compatibility with PHP 8.4 and PHP 8.5.

How to Update

The update follows our standard philosophy: Admin can create a backup, just click to “Update” and go.
What are you waiting for?

Try Dokky Suite Live Demo
Buy Now Dokky Suite