UPDATE: Some of you have been contacting me asking on the status of wallets6 development. Honestly am surprised at how many people are looking forward to wallets6, so thank you for this! I am currently working on rewriting the last extension, the Exchange extension. wallets6 is almost ready. Then there’s a few bugfixes across all products, integration testing, documentation, and website changes. It was a mistake to try to estimate development time. It will be ready when it’s ready!

Why?

Let’s face it: The plugin currently sucks, and it’s extensions also suck! You know it, I know it, the world knows it. Every day I’m amazed at how you, the brave admins and webmasters, put up with it!

Some time in August of 2020 I got fed up with the low quality, and decided to rewrite everything from scratch. The plugin, the extensions, the documentation, the build process, the website, everything…

For this, I had to put the existing plugins into “maintenance mode”: I stopped developing enhancements. I am now only fixing bugs to the existing codebase, when needed.

This is a normal thing that can happen in software projects. Incremental steps are safer, but too many things had to change all at once. A new design was needed to go forward. I hate refactoring because it’s risky. But sometimes you have to do it, in order to move forward.

I didn’t want to say much until now. I had to first prove that all of this can be done.

The parent plugin is over 75% done now, and I have a clear plan on how to finish it and how to re-write the extensions. So now, I can rant about the reasons for my decision here, in one long paragraph:

I wanted to stop using error-prone SQL queries and start using post types for all the plugin data. I had to to re-think the coin adapters, so that ERC-20 can finally be incorporated. This meant decoupling the concepts of wallet and currency. I also wanted to do away with the fiat coin adapter extension, which was an ugly hack, and to integrate fiat coin support into the parent plugin. The frontend UI templates have terrible performance, and even worse code encapsulation. The JSON-API, being custom-made, also sucks; it should have been implemented as an extension to the WP REST API. Then, caching and authentication could be delegated to WordPress. Most importantly, I wanted to improve code quality: I wanted to reduce the number of issues/bugs that users are experiencing. To that end, I am improving unit test coverage, and am now also automating integration tests; I also do more and better static code analysis. As WordPress is moving away from PHP 5.x, there’s no longer a point in avoiding the new language constructs. Typing declarations in particular, can improve code quality by a lot. Finally, I wanted a clearer admin UI. And I wanted the plugin to be friendlier to PHP developers, and therefore to allow easy integration with other plugins. PayPal and other credit card processor integrations, which many of you have been asking for, should be custom “glue code” that anyone can write, not an entire plugin.

Here’s what you can expect from Bitcoin and Altcoin Wallets version 6.0.0, which will be out sometime in Q2 of 2021 (or Q3 at the latest!).

Post types

Up to version 5.x, as many of you know, the plugin data was stored in two custom tables: wp_wallets_txs and wp_wallets_adds. There was a custom .csv exporter/importer. Coin adapter settings were mostly stored as WordPress options (on the wp_options table). This is not ideal for a number of reasons. Custom SQL queries are error-prone and require a lot of maintenance. Code readability, maintainability, and safety suffered because of this choice.

All data is now implemented as WordPress Custom Post types:

With this change:

• You can now use the WordPress editor to edit wallet settings, currency settings, transactions and addresses.
• Wallet connection settings can be backed up and migrated from one installation to another, like any other content.
• An admin can create new transactions and thus modify the user balances.
• Transactions and addresses now have their own taxonomies. This lets you and other plugin extensions to organize the data using tags.
• Exporting and importing becomes a breeze using existing tools.

Wallet post type

• Wallets are now a custom post type.
• A wallet is a post that holds connection settings to a hot wallet. (A hot wallet can be something like Bitcoin core, a Monero full node, a TurtleCoin full node, a CoinPayments account, or, in the near future, an Ethereum node.)
• Wallets are now decoupled from currencies. This is the most major improvement in the plugin’s architecture!!!
• You must create wallet posts for each of your hot wallets. This information will not be auto-migrated from 5.x (sorry).
• You must create and assign currencies to your wallet(s). A wallet can now have one, or many currencies.

Coin adapters are out, Wallet adapters are in!

• A wallet can have one, or many, currencies.
• Therefore coin adapters are replaced with the new wallet adapters. This breaks compatibility with existing coin adapters (sorry).
• All the coin adapters offered on dashed-slug will be rewritten as wallet adapters.
• New wallet adapters can withdraw to multiple addresses at once to save on tx fees!

Currency post type

• A currency has a name, ticker symbol and associated transaction fees.
• A currency also holds current exchange rate data against a selection of other currencies.
• You must associate each currency with a hot wallet that you have created.

Ticker symbols vs currency_id

In the past, coins were always uniquely identified by their ticker symbol (e.g. “BTC” for Bitcoin).

This is no longer viable. The number of cryptocurrencies has since exploded, and there are many collisions.

Now that currencies have their own post type, the post_id can be used to uniquely identify a currency. Shortcodes that previously accepted the symbol attribute, now also accept the currency_id attribute.

Example: Bitcoin on your system is the Currency with post ID #1234. Then, the following two are now equivalent:

Simpler exchange rates

In version 5.x, there were multiple exchange rate providers. Setting a custom, fixed exchange rate was a complex process involving filters.

The situation now is simple:

Now, only Coingecko is used for cryptocurrency exchange rates, and fixer.io is used for fiat currency rates.

For each currency you have two choices:

• Associate your cryptocurrency with a CoinGecko ID. The plugin will help you in this. It does a fuzzy name match and gives you the most likely candidates for your currency. The plugin will then periodically update the exchange rate to those currencies.
• Set the exchange rate manually. You can set the exchange rate of your currency some major cryptocurrencies and/or fiat currencies. Only one exchange rate value is needed.

For fiat currencies, only a fixer.io API key is required. Once you enter it, the plugin will start updating fiat currency exchange rates periodically.

Address post type

• Addresses are now a post type.
• Addresses are associated to currencies and to transactions.
• Addresses belong to their authors/users.
• Admins can create, edit and delete Addresses.
• There can be deposit addresses, like before, and now also withdrawal addresses.
• For fiat currencies, Addresses can be physical home addresses.
• Old deposit addresses are migrated from wp_wallets_adds.
• Old bank deposit/withdrawals from the Fiat Coin Adapter are also migrated.
• Known withdrawal addresses are displayed as suggestions in the [wallets_withdraw] UI.

Transaction post type

• Transactions are now a post type.
• A transaction post is an entry in the plugin’s ledger that affects a user’s balance.
• This can be a deposit or withdrawal or move as before.
• An internal transaction (move) is either a debit or a credit entry, and does not correspond to a blockchain entity.
• A wallet adapter can create and modify transactions freely. This allows more flexibility in adapter development.

As an admin, you can create, edit and delete any type of transaction. So be careful who you give the capability manage_wallets to!

“With great manage_wallets, comes great capability.”

Confucius, probably

Integers, not floats

• All transaction amounts are now stored as integers internally. No more floats, no more floating-point errors.
• Decimal denominations are displayed to the user by dividing these integers by the amount of decimals allowed by the currency.
• For internal calculations/storage only integers are used. Not one Satoshi will ever again be lost (or gained)!

Data migration

Existing data will be automatically migrated to Address and Transaction entities. The migration process deserves its own article, and will be detailed with the release notes for wallets6. This is something that works out-of-the-box, but as an admin you may want to know more about what happens to your user data. For now, you should know that transactions and addresses will be migrated automatically, but you will have to re-connect your wallets and currencies when the time comes. The migration will be extra safe and you will be able to revert to wallets 5.x if something goes wrong. No data will be deleted, only copied over.

Admin/Backend

The Wallets menu was getting too crowded. Here’s what’s new:

• A more useful dashboard section. Actual statistics on recent plugin usage.
• Metaboxes for the four new post types. Admins can now edit content like any other post.
• All other settings are neatly organized, using tabs, under the WordPress Settings menu.
• Fiat deposit and withdrawal tools are under the Tools menu. These are there to process bank transfers in a backwards compatible way with the Fiat Coin adapter. You may also create any deposits/withdrawals directly via the transaction editor.

Frontend UI elements

The frontend UI elements will keep the same appearance. The customizer settings will also remain unchanged for now.

Templates

• The templating system, introduced in 5.0.0, is preserved and expanded.
• A UI template now encapsulates the markup, and associated JavaScript and CSS styling.
• When you copy and modify a UI, you now have more control. (Previously, part of the JavaScript was hard-coded. Now the JavaScript is part of the template and you can override it.)
• You can now initialize many UIs to a particular currency, without using the ugly template="static"hack.

Shortcodes

• The shortcodes remain backwards-compatible. There is no need to edit your existing shortcodes.
• There is no longer a distinction between dynamic and static UIs.
• A few new UIs are added. The [wallets_status] shortcode will display the status of currencies and whether their hot wallets are online.
• Additional attributes are added. You can now specify a currency by its symbol OR post_id (see the discussion on currencies and ticket symbols, above).

WP REST API

The frontend no longer requires the old JSON-API, but is now communicating with your server via the WordPress RESTful API.

This brings several advantages:

• No more caching issues
• No more need for token bearer authentication. Authentication is delegated to WordPress.
• A more uniform API experience. The RESTful paradigm is used in all endpoints.

Breaking changes related to JSON-API!

I realize that some of you may have built android applications communicating with the existing JSON-API. If you are depending on the JSON-API to continue to function as expected, please contact me. I’d like to know.

I may be able to re-develop the JSON-API on top of the new architecture, but it would be an enormous amount of work. Too many things have changed. Eventually the JSON-API has to be removed, either sooner or later. Again, if you think you are affected by this, please contact me.

EDIT: Turns out some of you have actually developed apps on the old JSON-API. The wallets6 plugin will feature a Legacy JSON-API that will be compatible with JSON-API v3, but works with the new architecture. It is marked deprecated and disabled by default, but if you have an already developed app that talks to the plugin, you can use this without changes to your app.

New cron jobs scheduler

• Several jobs are required to keep the plugin running. Examples: data migration, emails, exchange rates, deposits, withdrawals, all are tasks that need to run asynchronously.
• A cron job scheduler now handles task priorities – much like in an operating system. Helps with scalability.
• Instead of a custom URL, you now must trigger /wp-cron.php to make the jobs ran fast. (This is not strictly necessary if your site is getting frequent traffic.)
• Emails are no longer sent immediately. They are queued in a WordPress transient. A cron job sends them asynchronously in batches.
• The cron job that processes crypto withdrawals is upgraded: it can now batch withdrawals of the same coin together, and save on fees. (This requires that the underlying wallet adapter supports transactions to multiple outputs.)

Capabilities/Access control

• Access control is done via WordPress capabilities. The same capabilities are used as before.
• The only exception is that the capability access_wallets_api is removed. This is due to the transition from the JSON-API to the RESTful API.
• As before, there is a capability editor that allows you to assign capabilities to user roles.
• The capability editor is extended. It now includes capabilities that control which user roles can edit the four post types, Wallets, Currencies, Transactions and Addresses. Most admins will not need to edit this.

Quality

This is where the devops fun begins!

By improving code quality on several fronts means less bugs, and therefore much less frustration for you, the users, and for me, the developer!

PHP versions

Version 6 of the plugin will require PHP 7.2. If you are still on 5.6, you may want to upgrade to something more recent. WordPress is moving away from PHP 5.x and currently recommends PHP 7.4 anyway.

The plugin will also be tested with PHP 8.

Rationale: Moving to 7.2 means that now code can be organized in namespaces. Also, types can be used in function/method signatures, preventing bugs. Static code analysis with phan works more efficiently with types, and now discovers more bugs for me early on.

Testing

Unit testing coverage is greatly improved. However, unit testing was never really that much useful in practice. Most actual bugs occur due to integration with WordPress and other plugins, not due to defects in unit implementation.

I have developed an integration testing framework that is similar to what other big plugins are using: A grunt target that installs the plugin into a WordPress and runs PHPunit. Instead of mocking WordPress functions and filters, it’s now possible to test the integration of the plugin with an actual WordPress instance, connected to a live MySQL DB and to the network. This allows me to catch even more issues before they arise.

This was one of the major challenges in this complex transition. It is also what will carry the plugin to the future! Rigorous testing is a necessity, not a luxury.

Extensions

Here’s what the fate of the existing extensions will be:

Documentation

I am rewriting the documentation to be clearer, more concise, easier to read. There will be a 1-1 relation between admin screens and documentation chapters.

The existing PHP-API has been re-developed for backwards compatibility, where possible. The new way to interact with transactions and addresses via PHP is an Object-Oriented API, but most of the old hooks are preserved, where they make sence.

The developer’s documentation will be centered around practical code snippets on how to do simple tasks.

The road ahead

I want to release all of this by the summer of 2021. Please realize that this is an ambitious goal for one person, but I can do it! If I can’t, then Q3 at the latest.

At first, many of you will encounter difficulties with the transition to wallets6. (again, sorry for this!)

My focus immediately after the release, will be to help you with these issues.

Once the dust settles, this is my plan:

ERC-20

Clearly, the ERC-20 saga has to come to an end. Ethereum full nodes and ERC-20 support will be top on my priorities.

In the past, many of you have requested this. But with the old coin adapter architecture, it was impossible to have currencies that incur a deposit fee. A deposit fee is necessary for ERC-20 tokens, because these must then be transferred from the user deposit address (account) to the site account. This costs gas which needs to be deducted from somewhere.

Game

Several of you have observed that this platform is mostly suitable for games, such as games of chance. I intend to create at least one casino-type game. This will be profitable on its own, and will be an example of how to develop other games.

Things I can’t work on right now:

I can’t do everything! Sorry! All of the above is already a lot for now.

PayPal, or other credit card or fiat gateways

As I mentioned several times before, I do not intend to work on a gateway to credit card processors.

However: The new documentation will showcase example code on how to easily create deposit transactions. If your payment gateway plugin emits a WordPress action, you can attach a few lines of code there.

DeFi or non-custodial wallets

I am aware that some of you are asking for MetaMask integration. However this is out of scope of this plugin. This is a plugin for custodial wallets. Also, this is not a plugin that has anything to do with smart contracts or the recent DeFi craze. It’s just too much of a stretch to include any such features right now.

Feedback

Thank you to all of you providing constructive feedback on the forums and over email. I respond to all queries at least once a day on working days.

I remain available to give advise and answer questions about the plugin. If you have a cool idea, you can always share it with me, but know that I probably don’t have the resources to implement it at this time.

If you spot a defect with any of the plugins, or if you encounter other issues, please contact me.

I am opening a new forum on the website, so we can discuss the Transition from version 5.x to the new version 6.0.0.