This article is the fourth in a series of articles, links to the others are found here: First, Second, Third

This post has been a long time coming, seeing as the last post in the series was just over three months ago.

CraftBook has sat on the backburner since progress towards 1.13 started, mainly due to the smaller user base than WorldEdit and WorldGuard. In saying this, CraftBook is still my main priority out of all plugins I develop.

Challenges of 1.13

IDs on signs

1.13 poses a few interesting challenges for CraftBook. The biggest of which is items and blocks on signs. This idea is used throughout the plugin and underpins many of the main features.

The main annoyance regarding this issue, is I fixed it back in 2014 with CraftBook 4. CraftBook 4 never requires entering items or blocks on signs; however, it depends on a feature that is not realistically possible with Spigot.

The current solution has been to allow legacy IDs for existing blocks and use 'minified' (without the minecraft namespace) string IDs for new blocks. In the few cases where they're still unable to fit on signs, CraftBook's Variables feature allows for it to still function. This recommendation is a temporary solution.

Spigot Bugs

Another major issue that I've encountered is the instability and bugginess of the Spigot API. Upon first updating the plugin, over half of the features didn't work purely due to Spigot not correctly handling API calls and events. Even now, I'll find issues caused by a new bug in Spigot.

CraftBook uses almost all of the Spigot API, making it one of the most common plugins for encountering bugs within Spigot itself. Due to this, I quite frequently run into very niche issues, some that have existed for years.

I've gotten some of these fixed within Spigot and others within Paper. However, many are fundamental design flaws that Spigot can't reasonably fix. For these, I'd need to create new additions to the API, and Spigot is less likely to accept these.


Having to make such significant changes to the plugin meant this was also a perfect time to modernise the plugin. The build system has switched to Gradle, meaning builds are once again available on I removed the WorldEdit API's deprecated usages and made few other minor changes to ensure the plugin has a modern codebase.

Now and the Future

Currently, CraftBook 3 is in a predominantly working state. I'm fixing issues as they crop up and improving the plugin as usual. There will have to be some changes made in the future to ensure that CraftBook continues being a performant, stable, and versatile plugin.

Plans for the Future

My current plan is to build the WorldEdit API to a point where CraftBook can exist on top of it. This plan is quite an enormous task, so it won't happen in the short term.

The goal here would be for a thin platform layer to sit between Spigot and CraftBook, meaning there is much less code that Spigot bugs can break.

This goal is also where CraftBook 4 comes into it. Maintaining CraftBook for both Spigot and Sponge as two separate code bases was an awful idea. The intention here is to have CraftBook 5, compatible with Sponge and Spigot, and based on the CraftBook 4 source. It's unclear how I will replicate the Sponge-specific features on Spigot at this stage. My main idea is to require Paper and add the necessary functionality there.

For more updated information on CraftBook 5, check out this article!

I've devoted countless hours to working on this project. If you'd like to support me, I have a Patreon and accept donations through PayPal. Thanks 😁

About the Author

Maddy Miller

Hi, I'm Maddy Miller, a Senior Software Engineer at Clipchamp at Microsoft. In my spare time I love writing articles, and I also develop the Minecraft mods WorldEdit, WorldGuard, and CraftBook. My opinions are my own and do not represent those of my employer in any capacity.