If you have ever felt that starting a blog should not require a computer science degree, you are exactly the kind of person Scriptlog was built for. Scriptlog is a free, open source blogging platform written in PHP, designed from the ground up to be simple, private, and secure, without dragging along the bloat of a full scale content management system. No confusing dashboards full of settings you will never touch. No plugin marketplace pushing you toward things you do not need. Just a clean, fast, and dependable place to publish your thoughts.

Today marks the release of Scriptlog version 1.8.0, and it is one of the most meaningful updates the project has shipped in a while. Under a codename that honors one of Indonesia's most remarkable birds, this release quietly rebuilds several pieces of the platform's foundation: how it remembers your settings, how it protects your uploads, how it defends your content from malicious scripts, and how quickly your pages load for visitors. None of these changes will ask you to learn anything new. They simply make the blog you already love running that much better.

Whether you are a complete beginner who has never touched a line of code, or a developer who wants to poke around the source and see exactly how things work under the hood, this article will walk you through what changed in 1.8.0, why it matters, and how you can get started with Scriptlog today. By the end, you should feel confident enough to download it, install it, and start writing, even if the words "server" and "database" currently sound a little intimidating.

Let us dig in.

What Exactly Is Scriptlog?

Before talking about what is new, it helps to understand what Scriptlog actually is and who it is for.

Scriptlog is personal blogging software. You install it on your own web hosting account (or on your own server if you are more technically inclined), and it gives you a complete publishing system: a public facing blog where your readers land, and a private admin panel where you write, edit, and manage everything behind the scenes. Think of it as owning your own small publishing house instead of renting space on someone else's platform.

The project is built with a layered architecture that keeps things request, then bootstrap, then dispatcher, then controller, then service, then data access, then database. If that sentence meant nothing to you, do not worry. What it means in practice is that the codebase is organized in a predictable, disciplined way, which makes it easier to maintain, easier to secure, and easier for other developers to extend safely. Every request follows the same clear path from start to finish, and each layer only does one job. That discipline is part of why Scriptlog has a reputation, even this early in its life, for being unusually careful about security.

On the technical side, Scriptlog supports PHP versions from 7.4 all the way through 8.5, and works with either MySQL 5.7 or newer, or MariaDB 10.3 or newer. It follows the PSR 12 coding standard, which is the community agreed style guide for clean PHP code, and it leans on well respected security libraries such as Laminas, Defuse PHP Encryption, voku's Anti XSS library, and HTMLPurifier to keep your content and your visitors safe.

Perhaps the most important word in all of this is "own." When you install Scriptlog, the files live in your own hosting account, the database sits under your own control, and the words you write belong entirely to you. Nobody can suspend your account for violating a vague policy you never fully read, nobody can quietly change the rules of what gets shown to your readers, and nobody stands between you and the people who choose to follow your writing. That is a different relationship with your own content than what most free, hosted blogging services offer, and for a lot of writers, once they experience it, it is difficult to go back.

None of that complexity, however, is something you as a blogger ever need to see. You fill out a simple installation wizard once, and from that point on, writing a post in Scriptlog feels a lot like writing an email. Type a title, write your content, hit publish. The engineering happens quietly in the background so your writing does not have to compete with your patience for technology.

Why This Release Deserves Your Attention

Every software project releases updates, and it is easy to scroll past a changelog without really absorbing what changed. Scriptlog 1.8.0, though, is worth pausing on for three simple reasons.

First, your blog will load faster for your readers. The team rebuilt how the application reads and remembers its own settings, cutting down on repeated database queries that used to happen on every single page load. If you have ever clicked on a blog and waited an extra second or two for the page to appear, you know how much that gap matters to a visitor's patience.

Second, your blog is more resistant to some of the sneakiest tricks attackers use against self hosted websites, including disguised files hidden inside uploads and scripts smuggled inside images. Scriptlog 1.8.0 closes several of those doors with dedicated new safeguards.

Third, the platform is now fully compatible with PHP 8.5, the newest version of the language Scriptlog is built on. That might sound like a small detail, but it means your hosting provider can keep your server software current without breaking your blog, which is a quiet kind of peace of mind that many older blogging platforms cannot offer.

According to the project's own changelog, 1.8.0 touched 59 files across 78 individual commits since the previous feature release, version 1.7.1. That is a meaningful amount of engineering work distilled into an update you can install in minutes.

There is a fourth reason too, quieter than the first three but no less important over the long run. A meaningful share of this release is dedicated to maintenance work that produces no visible feature at all: fixed edge cases, safer defaults, and new automated tests that exist purely to catch mistakes before they ever reach a live blog. That kind of unglamorous discipline is often what separates software that survives a decade from software that quietly rots after its first burst of attention fades. It is a good sign when a project keeps investing in its own foundations even after the exciting parts already work.

Let us walk through the highlights properly, one at a time, in plain language.

A Smarter Memory: The New Settings Cache

Every blog has a set of core settings behind the scenes: your site's name, its tagline, its base web address, how your posts are displayed, and dozens of smaller preferences you configured once during setup and mostly forgot about. In earlier versions of Scriptlog, whenever a page needed one of these values, it would ask the database directly, sometimes several times over the course of loading a single page.

Version 1.8.0 introduces what the team calls a centralized settings cache. Rather than repeatedly asking the database the same questions again and again, Scriptlog now reads all of your settings once at the start of a page request and keeps them in memory for the rest of that request. A new internal function called app_settings() handles the heavy lifting of pulling everything from the settings table in one pass, while a companion function called app_setting() lets any part of the application grab a single value with a sensible fallback if that value has not been configured yet.

There is also a function named reset_app_settings_cache(), which clears that memory when it needs to, for example right after an administrator changes a setting in the dashboard, so the change takes effect immediately rather than waiting for the cache to naturally expire.

The practical result for you as a blog owner is straightforward: pages that used to make several small trips to the database for basic information like your site name or tagline now make far fewer of those trips. Multiply that saving across every visitor and every page view, and it adds up to a noticeably snappier blog, particularly on modest, budget friendly hosting plans where every database query counts.

Full Page Caching, Now Configurable From the Dashboard

Speed is one of those things that most readers never consciously notice when it is good, but immediately notice when it is bad. Scriptlog has offered a page caching system for a while, a mechanism that saves a ready made copy of a page so the next visitor gets served that saved copy instead of making the server rebuild the page from scratch. What changed in 1.8.0 is how you control it.

Previously, adjusting page cache behavior meant editing configuration files directly, which is exactly the kind of task that scares off anyone who does not consider themselves a "computer person." Now, page caching lives right inside the General Settings screen of your admin panel. You get a simple checkbox to turn full page caching on or off, and a numeric field where you can set how long a cached page should stay valid, anywhere from sixty seconds up to a full day, with three thousand six hundred seconds, which is one hour, set as a sensible default.

Behind that friendly checkbox sit two new helper functions, page_cache_is_enabled() and page_cache_ttl(), which check both your server's configuration and your database settings to decide how caching should behave, with clear rules for which source takes priority if the two disagree. For fresh installations, the cache starts out disabled with a sixty minute default lifetime already seeded into the database, so upgrading users and brand new users alike land on a predictable, sensible starting point.

If you run a blog that gets shared on social media and occasionally experiences a sudden spike in visitors, this feature alone could be the difference between your site holding steady and your site struggling under the unexpected load. And you can now switch it on with a single click, no code editor required.

Locking the Doors: Security Hardening in 1.8.0

Security is where Scriptlog has always tried to stand out among small, independent blogging platforms, and version 1.8.0 leans further into that identity. Several of the changes in this release exist purely to make life harder for anyone trying to abuse your blog, whether that is through a malicious plugin upload, a booby trapped image, or an automated bot hammering your login form.

It is worth noting upfront that none of the following changes ask anything of you as a blog owner. You will not see a new checkbox to configure or a new decision to make. These protections are simply active from the moment you install or update to 1.8.0, working quietly in the background the same way a good lock on your front door works, doing its job without ever needing you to think about it. Let us go through the most important ones, translated out of engineering language and into terms that matter to you as a site owner.

Safer File Uploads With safe_zip_extract()

Scriptlog allows administrators to extend their blog by uploading plugins and themes as ZIP files. That convenience, however, has historically been a favorite target for attackers across many kinds of software, because a cleverly crafted ZIP file can sometimes trick a careless extraction process into writing files somewhere it should never be allowed to write, potentially overwriting sensitive system files or planting malicious scripts outside the intended folder.

Version 1.8.0 introduces a new function called safe_zip_extract(), which acts as a careful gatekeeper around the extraction process. It actively blocks several known attack techniques, including attempts to sneak files outside their intended folder using path traversal sequences, attempts to write to absolute file system paths, hidden null byte tricks, symbolic link based escapes, and so called zip bomb archives, which are specially crafted files designed to expand into an enormous, resource exhausting size the moment they are unpacked. This safeguard is now used automatically whenever a plugin or theme ZIP file is uploaded, quietly standing guard every time you or your team installs new functionality.

Cleaning Up What Gets Pasted Into Your Posts

If you have ever pasted content into a blog post editor from another website, you know that pasted content can sometimes drag along more than just text. Hidden formatting, inline styles, and in worse cases, embedded scripts can hitch a ride inside that pasted HTML.

Scriptlog 1.8.0 introduces two new tools working together, sanitize_post_content() and post_content_deny_attributes(), which strip out inline style attributes and any event handler attributes, the kind of code that can trigger a script to run automatically when a page loads, from your post content before it is saved. This cleanup is now handled by the dedicated post protection service inside Scriptlog, replacing an older approach that called security library functions directly inside the code. The result is content that displays exactly the way you intended, without carrying hidden risks a reader's browser might act on without your knowledge.

Photos That Cannot Hide Anything

Image uploads are another classic weak point across countless web platforms. It is technically possible to disguise a working script as an ordinary looking image file, a trick sometimes called a polyglot file, because the same bytes can be interpreted as two different file types depending on which program opens them.

To close this door, Scriptlog 1.8.0 changed how uploaded photos are processed. Every uploaded image is now re encoded through the GD and WebP image libraries before it is stored. Re encoding effectively rebuilds the image from its visual pixel data alone, which strips away any hidden code that might have been smuggled inside the original file, since anything that is not genuinely part of the image simply does not survive the rebuilding process. As a nice side benefit, the update also skips a redundant step during this process when your server's fileinfo extension is available, making uploads a touch faster too.

A Stronger Front Door Against Automated Abuse

Every public website eventually attracts automated traffic trying to guess passwords, scrape content, or otherwise abuse the system faster than any human could. Scriptlog's rate limiter, the internal system that slows down or blocks suspicious rapid fire requests, received two meaningful improvements in this release. It now compares security tokens using a timing safe comparison function, which helps prevent a subtle class of attack where a bad actor could theoretically guess a secret value by measuring tiny differences in how long a server takes to respond. The rate limiter's tracking system was also simplified to use only the visitor's IP address as its bucket key, removing an older bypass route that involved a special API key header.

Blocking Inline Scripts at the Browser Level

Beyond changes to Scriptlog's own code, this release also strengthens the instructions your visitors' browsers receive about what a page is allowed to do. A new directive called script src attr none was added to Scriptlog's Content Security Policy, a set of rules sent along with every page that tells the browser which sources of code it is permitted to execute. This particular addition specifically blocks inline event handler attributes, working hand in hand with the post content sanitization described earlier, and with an accompanying change that replaced an inline onchange handler on the post visibility dropdown with a modern, framework friendly alternative instead.

Guarding the Plugin System Itself

Finally, the PluginService, the internal component responsible for enabling, disabling, and removing plugins, now applies basename() sanitization along with an explicit directory traversal guard whenever it works with plugin directory paths. In plain terms, this closes off a subtle route by which a maliciously named plugin folder could potentially trick the system into operating outside the plugin directory it was supposed to stay confined to.

Taken together, these six changes represent a genuinely thoughtful, defense in depth approach to security. No single safeguard is asked to do all the work alone. Instead, several independent layers each cover a different angle, so that even if one protection were somehow bypassed, others remain standing.

Full Compatibility With PHP 8.5

Programming languages evolve constantly, and PHP is no exception. Each new version tends to phase out older techniques that were once common but are now considered outdated or risky, a process developers call deprecation. Software that does not keep pace with these changes eventually starts throwing warnings, and in worse cases, outright errors, on newer PHP versions, forcing site owners into an uncomfortable choice between upgrading their server software and keeping their blog running smoothly.

Scriptlog 1.8.0 removes that dilemma entirely for the newest release of PHP. The team updated fourteen separate admin panel templates, along with the PostController, ThemeController, TranslationDao, TranslationService, a core utility class, and several installer files, specifically to address PHP 8.5 deprecation warnings. This was not a quick patch job either. It was a methodical, file by file pass through the codebase to make sure every corner of Scriptlog behaves correctly on the newest language version available.

Why should you, a blogger rather than a developer, care about this? Because it means your web hosting provider can upgrade the PHP version running on their servers, something hosting companies do periodically for their own security and performance reasons, without your Scriptlog blog breaking as a result. Many older or abandoned blogging platforms lose this compatibility over time and start showing cryptic error messages the moment a host updates its software. Scriptlog is explicitly built to avoid that fate, supporting a wide span from PHP 7.4 through PHP 8.5 in a single, unified codebase.

Performance Improvements You Will Feel Without Noticing Why

Beyond the settings cache and page cache dashboard already covered, version 1.8.0 includes a handful of smaller performance refinements that quietly add up.

The Db class gained a new method called prepareCached(), which reuses prepared database statement objects for identical SQL queries that occur more than once within the same page request, rather than preparing a fresh statement from scratch every single time. This cache is capped at sixty four entries and clears itself automatically once a database connection closes, so it stays efficient without growing unbounded.

The functions responsible for figuring out which theme is currently active, theme_dir() and theme_identifier(), now remember their answers for the duration of a request instead of recalculating them repeatedly, with dedicated reset functions available for the rare situations where that cached answer needs to be cleared early.

A function called applyTablePrefix(), which Scriptlog uses internally to make sure every database table name is consistently prefixed, used to build its matching pattern with a loop that ran a pattern quoting operation once per table. That loop has been replaced with a single, combined pattern sorted with the longest table names first, compiled once and reused afterward rather than rebuilt on every call.

None of these three changes will show up as a headline feature anywhere, and you will likely never think about any of them while writing a blog post. But collectively, alongside the settings cache and the new page cache controls, they represent the kind of unglamorous, careful engineering that separates software built for the long haul from software that merely works well enough for a demo. Your pages simply load a little faster, your server works a little less hard for each request, and you never have to think about why.

A Small But Useful Addition: The Public API Info Endpoint

Scriptlog includes a RESTful API for developers who want to build integrations, mobile apps, or automated tools around their blog. Version 1.8.0 adds a small but genuinely handy piece to that API: a public information endpoint, reachable through ApiController's new info() method, which returns basic application metadata such as your Scriptlog installation's name, its version number, and the PHP version it is running on, without requiring any authentication to check.

This is particularly useful for anyone managing multiple Scriptlog installations, for monitoring tools that want to confirm a site is alive and running the expected version, or simply for developers who want a fast, no login way to confirm which version of Scriptlog a given site is running before diving into any deeper API work.

Keeping Your Theme's Security Promises Up to Date

Modern web browsers support a feature called Subresource Integrity, commonly shortened to SRI, which lets a website tell the browser exactly what a linked file, such as a stylesheet or a script, should look like using a cryptographic fingerprint. If the actual file ever does not match that fingerprint, perhaps because it was tampered with, the browser refuses to load it. It is a quiet but powerful safeguard.

The challenge with SRI is that those fingerprints have to be recalculated every time the underlying file changes, or the browser will start rejecting files that were legitimately updated. Scriptlog 1.8.0 introduces a new function called sync_integrity_hashes(), living inside the platform's asset minification tooling, which automatically scans theme templates for outdated integrity attributes and recalculates their SHA384 hashes whenever theme assets are regenerated. If you are a theme developer, or if you simply enjoy customizing your Scriptlog theme's appearance, this means one less manual step to remember, and one less way to accidentally end up with a broken looking site because a security fingerprint quietly fell out of sync with reality.

Dozens of Small Fixes That Add Up to Real Stability

Not every improvement in a release makes for exciting reading, but many of them matter enormously for day to day reliability. Version 1.8.0 quietly resolved a long list of smaller issues, including several worth mentioning here because of how directly they affect real world usage.

Sites that had disabled Scriptlog's friendly permalink feature were, in certain Nginx server configurations, unable to reach the API correctly, because the server's catch all routing rule was intercepting API requests before they ever reached their intended destination. Scriptlog 1.8.0 fixes this by adding a dedicated routing rule specifically for API paths that takes priority over that catch all behavior, restoring correct API access regardless of your permalink settings.

The autoloader, the internal system responsible for locating and loading PHP classes as they are needed, now falls back gracefully if a controller file happens to be missing, rather than causing a hard failure. Session handling picked up a small but important guard that checks whether a session has already ended before attempting to destroy it again, preventing unnecessary warning messages. The tool responsible for recursively removing directories, used during certain administrative operations, gained protection against being pointed at something that is not actually a directory, or at a path that does not exist at all. And the PluginService, already mentioned above for its new security guard, received that same basename sanitization specifically to prevent directory traversal issues during plugin path handling.

Individually, these are the kind of fixes that most users would never notice happening. Collectively, they represent the unglamorous, essential maintenance work that keeps a piece of software trustworthy over years of continued use rather than just at the moment of its first release.

Seven New Test Suites, Because Trust Has to Be Earned

One detail buried in the changelog deserves a moment of its own attention, because it says something meaningful about how the Scriptlog project approaches quality. Alongside all of the features and fixes above, version 1.8.0 shipped seven brand new automated test files: AppSettingsTest, DbStatementCacheTest, ThemeCallerCacheTest, SyncIntegrityHashesTest, SafeZipExtractTest, SanitizePostContentTest, TokenizerSelectorKeyTest, and MessageLogGuardTest.

Automated tests are essentially a safety net written in code. Every time a developer changes something in Scriptlog going forward, these tests run automatically and confirm that the new settings cache still behaves correctly, that the ZIP extraction safeguards still block what they are supposed to block, that post content sanitization still strips what it should strip, and so on. It is the kind of investment that rarely shows up as a feature you can point to, yet it is precisely what allows a project like Scriptlog to keep moving quickly on new features without quietly breaking things that used to work. For an open source project that many small businesses and individual writers are trusting with their content, that discipline matters.

Meet Maleo Senkawor, the Bird Behind the Codename

Scriptlog gives each release cycle a codename rather than just a version number, and the codename for the current cycle, carried forward into 1.8.0, is Maleo Senkawor.

The name honors Macrocephalon maleo, a striking bird found only on the Indonesian island of Sulawesi. The maleo is famous for a reproductive strategy found almost nowhere else in the bird world. Rather than sitting on their eggs to keep them warm the way most birds do, maleo pairs dig deep pits and bury a single large egg, letting either geothermal heat rising from volcanic soil or simple sunlight at coastal nesting grounds do the incubating instead. When a maleo chick finally hatches, it emerges already fully feathered and capable of flight, walking straight out of the sand and into independent life without ever needing a parent's care.

It is also, unfortunately, a critically endangered species, with its population having fallen by more than ninety percent since the 1950s and fewer than ten thousand individuals believed to remain in the wild today. Conservation groups such as the Wildlife Conservation Society Indonesia and the Alliance for Tompotika Conservation have worked for years protecting nesting grounds and running hatchery programs that have released thousands of chicks back into the forest since the early 2000s.

Naming a software release cycle after a species like this is a small gesture, admittedly. But it reflects something genuine about the spirit of an independent, community built project like Scriptlog: an appreciation for things that are distinctive, a little unusual, worth protecting, and entirely capable of standing on their own two feet from the very beginning, much like a blogging platform that asks you to own your own content instead of renting space from a corporation.

It is a fitting metaphor for the software itself in another sense too. Just as maleo chicks emerge fully capable rather than needing years of dependent care, a freshly installed Scriptlog blog is immediately functional the moment the installer finishes, with caching, security hardening, threaded comments, multilingual support, and a working editor all present from the very first page load, rather than requiring you to bolt on plugin after plugin just to reach basic functionality.

Who Is Scriptlog Actually For?

By now you might be wondering whether Scriptlog is the right fit for you specifically. Here is an honest answer.

Scriptlog is a strong choice if you want a personal blog, a portfolio with a writing component, a small business site that publishes regular updates, or a niche publication covering a topic you care deeply about, and you would rather your content live on infrastructure you control instead of a platform that could change its rules, its pricing, or its algorithm at any moment. It is also a strong choice if performance and security matter to you, but you do not want to spend your evenings configuring caching layers and firewall rules by hand, because Scriptlog is designed to handle a meaningful amount of that complexity for you by default.

Scriptlog is probably not the right tool if you specifically need an enormous, sprawling content management system with hundreds of third party plugins covering every conceivable feature, the kind of flexibility that comes from platforms like WordPress after two decades of ecosystem growth. Scriptlog deliberately does not try to be that. It aims to be smaller, simpler, and more focused, a tool built specifically for the act of blogging rather than a general purpose website builder trying to be everything to everyone.

Scriptlog also tends to appeal to people who have been burned before, writers who once built an audience on a hosted platform only to watch it disappear overnight due to a policy change, a business decision made somewhere far away, or a service simply shutting down. Self hosting removes that particular fear entirely. As long as you keep paying for modest, inexpensive web hosting, exactly the kind that costs less than a couple of coffees a month at most providers, your blog remains exactly where you left it, under your own name, on your own domain.

If what you want is somewhere honest, fast, and secure to publish your writing, without needing to become a systems administrator in the process, Scriptlog was built with exactly you in mind.

Everything Else Scriptlog Already Gives You

Version 1.8.0 is the newest layer on top of a platform that already comes surprisingly well equipped for something so lightweight. Before we get to installation, it is worth taking a short detour through some of the built in capabilities Scriptlog offers every blogger by default, since several of them directly answer questions readers tend to ask before committing to a new platform.

Multiple Languages, Handled Automatically

If your audience does not read only in English, or if you write in Indonesian, Arabic, Spanish, or any other language, Scriptlog includes a genuine internationalization system rather than a bolt on translation plugin. It can detect which language a visitor should see based on a URL prefix, a saved cookie, or the language preference their browser already sends, falling back to a sensible default when none of those are available. Translations themselves are stored in the database and cached for performance, and the system fully supports right to left languages such as Arabic and Hebrew, correctly adjusting the reading direction of your theme rather than simply mirroring text awkwardly. For a blogger writing for a bilingual or international audience, this means you are not stuck bolting on a separate plugin ecosystem just to serve readers in more than one language.

Comments That Can Actually Hold a Conversation

Scriptlog supports threaded, reply based comments, meaning readers can respond directly to a specific comment rather than only ever adding a new comment to the bottom of a long, flat list. Replies are linked back to their parent comment, so a genuine back and forth discussion under a post stays readable and organized rather than turning into a confusing wall of disconnected opinions. Comments can be marked approved, pending, spam, or draft, giving you straightforward moderation control over what appears publicly on your blog without needing a separate third party comments service.

Bringing Your Old Blog With You

Perhaps the single most reassuring feature for anyone currently blogging somewhere else is Scriptlog's content import system. It can read export files from WordPress, from Ghost, and from Blogspot, also known as Blogger, along with Scriptlog's own native export format for moving between two Scriptlog installations. The import process previews your content before committing anything, so you can see exactly what will be brought over, then carries across your posts, pages, categories, and comments, mapping everything to your new Scriptlog site and linking comments back to the correct posts automatically. In other words, if you already have years of writing sitting on another platform, you are not being asked to start from a blank page. You can bring your archive with you.

The same system works in reverse too. Scriptlog can export your content back out to WordPress, Ghost, or Blogspot compatible formats, or to its own native format, which doubles as a straightforward way to create a full backup of your posts, pages, categories, tags, comments, navigation menus, and settings whenever you want one.

Email That Just Works

Sending automated emails, for things like comment notifications or password reset links, is one of those behind the scenes tasks that is easy to get wrong on shared hosting. Scriptlog includes a dynamic SMTP configuration system, meaning you configure your outgoing mail server, whether that is your hosting provider's mail server, Gmail, or another provider entirely, directly from a settings page in your admin panel, rather than editing a configuration file by hand. Under the hood it relies on Symfony Mailer, a widely trusted and actively maintained email delivery library, and it gracefully falls back to any values already saved in your configuration file if a particular database setting has not been filled in yet.

Finding Things, Both for You and for Your Readers

Scriptlog also ships with a genuine search system rather than a bare bones keyword match. Visitors can search your published content directly from your site, whether your blog has friendly permalinks turned on or off, and results are rendered through a proper search template consistent with the rest of your theme's design, rather than dumping readers onto an unstyled results page that looks like it belongs to a different website.

Privacy Tools Built In From the Start

If you operate in a region with data protection regulations such as the General Data Protection Regulation, commonly known as GDPR, or if you simply want to run your blog with good privacy hygiene regardless of where your readers are located, Scriptlog includes dedicated tooling for exactly that. It has structured support for recording visitor cookie and tracking consent, and for tracking data subject requests, meaning formal requests from a visitor to access or delete the personal data your site holds about them. Access to these privacy tools is restricted to administrators through Scriptlog's permission system, ensuring sensitive personal data handling never becomes accidentally exposed to the wrong user role. You do not need to bolt on a separate compliance plugin from an unfamiliar third party vendor just to take your visitors' privacy seriously.

Taken together, these existing capabilities, layered underneath everything new that arrived in version 1.8.0, are why Scriptlog tends to surprise people who assume that "lightweight" and "capable" cannot coexist in the same piece of software. It can.

Writing Features That Make Publishing Feel Natural

A blogging platform lives or dies by how it feels to actually sit down and write, so it is worth spending a moment on the day to day writing experience rather than only the engineering underneath it.

Scriptlog's post editor is built around Summernote, a polished, widely used WYSIWYG editor, which is simply a technical way of saying that you write and format your post visually, bolding, adding headings, inserting links, the same way you would in a familiar word processor, rather than typing raw formatting code by hand. Uploading an image into a post happens through AJAX, meaning the image uploads in the background the moment you insert it, without reloading the page or losing your place in whatever you were writing.

For content that is not ready for the entire internet just yet, Scriptlog also includes a genuine password protected posts feature, and it is built more carefully than the phrase might suggest. Rather than simply hiding a post from a menu, Scriptlog actually encrypts the post's content using AES 256 CBC encryption with a passphrase unique to that post, and stores only a bcrypt hash of the password itself, never the password in plain readable form. A visitor who lands on a protected post sees a password prompt and nothing else, since no content is sent to their browser until the correct password has been verified. To prevent someone from simply guessing passwords over and over, the system automatically rate limits attempts, allowing a maximum of five failed tries within any fifteen minute window for a given post and visitor. This makes password protected posts genuinely useful for sharing an early draft with a trusted friend, publishing content meant only for family, or holding back a post for a specific audience until you are ready to make it fully public, all without needing a separate membership plugin or a third party service.

Small conveniences like these are easy to overlook in a changelog full of caching systems and security functions, but they are often what actually determines whether writing on a new platform feels comfortable enough to stick with.

Getting the Most Out of Your New Blog

Once you have Scriptlog installed and your first post published, a few simple habits will help you get real value out of everything covered in this article.

Turn on page caching from the General Settings screen described earlier, especially if your hosting plan is on the modest side. It costs nothing to enable and the difference in load times is often immediately noticeable to returning visitors.

Use the export system every so often, even if you never plan to leave Scriptlog, simply as a backup habit. A native format export takes moments to generate and gives you a complete, portable copy of your posts, pages, categories, tags, comments, menus, and settings, sitting safely outside your live hosting account.

If you write for readers who speak more than one language, take a look at the internationalization settings early rather than after you already have hundreds of posts published, since deciding on your language strategy from the start tends to be far less work than retrofitting it later.

And if you are migrating from WordPress, Ghost, or Blogspot, use the built in importer's preview step carefully before confirming anything. It gives you an honest look at exactly what will be brought over, which is the right moment to catch anything unexpected before it becomes part of your new site.

Installing Scriptlog if You Have Never Touched Code in Your Life

This is the section many readers have been waiting for, and it deserves to be as reassuring as possible. If words like "server," "database," and "PHP" make you nervous, take a breath. You do not need to understand any of the engineering described earlier in this article to get a working Scriptlog blog online. You just need to follow a sequence of steps, the same way you would follow a recipe.

Step one: get the files. Visit the official Scriptlog website at https://scriptlog.my.id and look for the download link. It will give you a ZIP file, a single compressed package containing everything Scriptlog needs to run. You do not need any special software to download it beyond your regular web browser.

Step two: get web hosting ready. You will need a web hosting account that supports PHP and either MySQL or MariaDB, which is standard on the vast majority of affordable shared hosting plans sold today. If you already have a hosting account for another website, there is a good chance it already meets Scriptlog's requirements without any changes.

Step three: upload the ZIP file. Most hosting providers offer a file manager tool inside their control panel, often called something like cPanel, Plesk, or a similar dashboard, that lets you upload files directly through your web browser without needing any special software like FTP clients, though those work too if you are already comfortable with them. Upload the ZIP file you downloaded, then use your hosting provider's file manager to extract it, which is usually as simple as right clicking the file and choosing an option like "Extract" or "Unzip."

Step four: create a database. Inside your hosting control panel, look for a section about databases, usually labeled something like MySQL Databases or Database Wizard. Create a new, completely empty database, and when you are given the option, choose the utf8mb4_general_ci collation setting, which simply ensures your blog can correctly store text in any language, including emoji. Write down the database name, the username, and the password you set, because you will need them in the next step.

Step five: run the installer. Open your web browser and navigate to the install folder of your uploaded Scriptlog files, which will look something like yourdomain.com followed by slash install. A friendly setup wizard will greet you. It walks you through three simple stages: first, it checks that your hosting environment meets the basic requirements, second, it asks for the database details you wrote down in the previous step so it can connect and automatically build all twenty two tables Scriptlog needs, and third, it finishes the setup and creates your administrator account, the login you will use to write posts going forward.

Step six: the one important cleanup task. Once installation finishes successfully, delete the install folder from your hosting account entirely. This single step matters for security, since leaving that folder in place could theoretically allow someone else to run the installer again on your live site. Most hosting file managers let you delete a folder in a couple of clicks, the same way you deleted the ZIP file once it was extracted.

And that is genuinely the entire process. From that point forward, you log into your admin panel, which will be something like yourdomain.com followed by slash admin, and you start writing. No command line, no code editor, no configuration files to hand edit unless you specifically want to customize something advanced later on.

If any step along the way feels unclear, most hosting providers offer live chat support that is well accustomed to walking beginners through exactly this kind of installation, since the overall pattern, upload files, create a database, run a setup wizard, is common across countless PHP applications, not just Scriptlog.

Installing Scriptlog if You Are a Developer

If you are comfortable with a terminal and version control, Scriptlog offers a more direct path through its GitHub repository at https://github.com/cakmoel/Scriptlog.

Start by cloning the repository and moving into the project folder.

git clone https://github.com/cakmoel/Scriptlog.git
cd Scriptlog

From there, install the project's dependencies through Composer.

composer install

One detail worth knowing here: Scriptlog's Composer configuration deliberately locks dependency resolution to PHP 7.4 compatibility rules through its platform.php setting, which is precisely what allows the same package set to work cleanly across PHP versions all the way from 7.4 through 8.5 without throwing runtime warnings on newer installations, even though your actual server can run any supported PHP version you choose.

The application itself lives inside the src directory, which also serves as your web root, so point your local development server or your production virtual host configuration at that folder specifically. After setting appropriate file permissions, which the project's README documents in detail, and creating an empty database using the utf8mb4_general_ci collation, you run the same three step browser based installer described above by navigating to the install folder, after which you should, as always, delete that folder once setup completes.

For ongoing development work, Scriptlog ships with a proper test suite you can run from the application root using lib/vendor/bin/phpunit, along with static analysis tooling through PHPStan for catching potential bugs before they ever reach production. The codebase follows PSR 12 formatting conventions and Conventional Commits for its commit message style, and the project's documentation folder inside src/docs contains considerably deeper references, including a full Developer Guide, a Theme Developer Guide for anyone building custom themes, a Plugin Developer Guide for anyone extending Scriptlog's functionality through the hook based clip() system, and a complete API reference including OpenAPI specification files for anyone building external integrations.

If you want to extend Scriptlog rather than simply run it, that plugin system is worth exploring specifically. Plugins hook into specific points of the application using a function called clip(), letting you add new frontend content, new admin pages, and new functionality without ever touching Scriptlog's core files directly, which keeps your customizations safe across future updates rather than getting overwritten every time you upgrade. A minimal plugin needs only three things: a plugin.ini file describing its name, version, author, and required permission level, a main PHP class file that registers its hooks in its constructor, and optionally a schema.sql file if the plugin needs its own database tables, which Scriptlog will execute automatically the moment the plugin is enabled from the admin panel.

Developers who would rather manage Scriptlog as a Composer dependency instead of a cloned repository have that option too, since the project is also published on Packagist and can be pulled into a fresh project with a standard composer require command, which some developers prefer when Scriptlog is one part of a larger, more customized project structure rather than a standalone site.

For anyone building an external application, whether that is a mobile companion app, a browser extension, or an entirely separate tool that talks to your blog remotely, Scriptlog's versioned RESTful API, reachable at the api/v1 path, follows HATEOAS principles, meaning API responses include hypermedia links describing what related actions are available, alongside consistent HTTP status codes and a documented authentication flow. The project ships both an OpenAPI YAML specification and a JSON equivalent inside its docs folder, which most API tooling and documentation generators can consume directly.

Joining a Growing Community

Open source software is ultimately a collective effort, and Scriptlog welcomes contributions of essentially every kind, not only code. If you find a bug, reporting it helps every future user who might have hit the same issue. If you write documentation, translate the interface into another language, design a theme, or simply share the project with someone who might find it useful, you are meaningfully strengthening the project's future.

The GitHub repository at https://github.com/cakmoel/Scriptlog includes contributing guidelines, a code of conduct describing the standard of respectful collaboration the project expects, and a dedicated security policy for anyone who discovers a genuine vulnerability and wants to report it responsibly rather than publicly, giving the maintainers a fair chance to fix it before details become widely known.

Scriptlog is licensed under the MIT License, one of the most permissive open source licenses in common use, which means you are free to use it, modify it, and build upon it, for a personal project or a client's small business website, without restrictive strings attached.

Common Questions, Answered Honestly

Before wrapping up, let us address a handful of questions that tend to come up whenever someone is deciding whether to try a new blogging platform.

Do I really not need to know how to code? Correct, you do not. Everything described in the non technical installation section above happens through your web browser, using a setup wizard and your hosting provider's control panel. Writing posts afterward happens inside the admin panel, which works much like any familiar text editor. Code only becomes relevant if you personally choose to build a custom theme or plugin later on, and even then, the Theme Developer Guide and Plugin Developer Guide included with the project are written specifically to walk a motivated beginner through that process step by step.

Is Scriptlog actually free? Yes. Scriptlog is released under the MIT License, one of the most permissive open source licenses available, which means there is no license fee, no forced upgrade to a paid tier, and no artificial feature limits waiting behind a paywall. Your only ongoing cost is whatever you already pay for web hosting, which for a small personal blog is typically inexpensive.

Can I move my existing blog over from WordPress or another platform? In most cases, yes, thanks to the content import system described above, which supports WordPress, Ghost, and Blogspot export files directly. It is always wise to keep a backup of your original site until you have confirmed everything imported the way you expected, but you are not being asked to manually copy and paste years of posts one at a time.

Will installing this slow down my website? If anything, the opposite is true, and version 1.8.0 specifically pushes further in that direction. Between the new settings cache, the dashboard controlled page caching, the database statement cache, and the various memoization improvements covered earlier in this article, Scriptlog is built to be gentle on modest, affordable hosting environments rather than assuming you have access to expensive, high powered servers.

What happens if I get stuck during installation? Start with your hosting provider's support chat, since the general installation pattern, uploading files, creating a database, and running a browser based setup wizard, is one their support staff handle constantly across many different PHP applications. Beyond that, the Scriptlog GitHub repository is the right place to search existing issues or open a new one if you believe you have found a genuine bug rather than a hosting specific configuration question.

Is my content actually safe if something goes wrong on my end? Nothing can promise perfect safety, technology occasionally fails regardless of the platform behind it, but Scriptlog gives you real tools to protect yourself. The built in export system doubles as a straightforward backup mechanism you can run whenever you like, and because you own the hosting account and the files outright, you are never dependent on a third party company's decision to keep your account active or your content online.

Can I change how my blog looks, or am I stuck with one default design? You have real freedom here. Scriptlog uses a proper theming system, with the default blog theme serving as a clean, accessible starting point rather than the only option available. Themes are self contained folders with their own templates and assets, described through a theme.ini file, so switching between themes or building a custom one does not require touching Scriptlog's core code at all. If you enjoy design and front end work, or you know someone who does, building a fully custom Scriptlog theme is a realistic weekend project rather than a months long undertaking, and the project's Theme Developer Guide walks through the required files and templates in detail.

Do I have to update to 1.8.0 immediately if I am already running an older version? Updating is strongly encouraged given the security hardening included in this release, but it is your decision and your website, and Scriptlog does not lock you out or nag you into upgrading against your will. If you do decide to update, back up your database and your files first, which is simply sound practice before updating any piece of self hosted software, Scriptlog included.

Bringing It All Together

Scriptlog 1.8.0 is not a flashy release built around one single headline feature you can put on a marketing banner. It is instead a thoughtful, disciplined update that strengthens nearly every layer of the platform at once: a smarter settings cache that reduces unnecessary database work, full page caching you can now control from a simple dashboard checkbox, six distinct security hardening measures covering everything from ZIP file uploads to image processing to browser level script blocking, complete compatibility with PHP 8.5, several quiet performance refinements, a useful new public API endpoint, automatic security fingerprint synchronization for theme assets, a long list of smaller stability fixes, and seven new automated test suites standing guard over all of it going forward.

If you already run Scriptlog, updating brings all of this to your blog with essentially no visible disruption to your existing content or your daily writing routine. If you have never used Scriptlog before, there has arguably never been a better moment to start, with a platform that is faster, more secure, and more broadly compatible than at any previous point in its history.

You do not need to be a developer to enjoy any of this. You need a web hosting account, about fifteen minutes for the installation wizard, and something you want to say to the world. Head over to https://scriptlog.my.id to download the latest version, or if you are the type who likes reading source code before trusting it, visit https://github.com/cakmoel/Scriptlog to see exactly how Scriptlog works, line by line, contribution by contribution, commit by commit.

It is worth remembering, too, that software like this does not build itself. Every function mentioned in this article, from the settings cache to the safe ZIP extraction guard to the seven new test files quietly watching over all of it, came from real work by real people who decided that independent, self hosted publishing was worth continuing to invest in, commit after commit, release after release. Choosing to run that software on your own domain, for your own writing, is a small but genuine way of supporting that kind of work.

There is also something quietly satisfying about the whole arrangement. You will not see advertisements bolted onto your posts by a platform trying to monetize your audience on its own terms. You will not wake up one day to a redesigned dashboard you never asked for, imposed on you by a company optimizing for engagement metrics rather than your actual writing experience. You will simply have a fast, secure, honestly built piece of software doing exactly what you installed it to do, on infrastructure that answers to you and nobody else.

So take the fifteen minutes. Download the ZIP file, or clone the repository if you would rather start from source. Run the installer, delete that install folder once you are done, and log into your new admin panel for the first time.

Your blog is waiting. Go build something worth reading.