[alexg]

OK thank you for finding this. This is entirely my fault.

An ISO8601 string contains a timezone offset suffix, and this can’t be inserted into datetime columns.

The reason that this bug was not apparent before is that most coin adapters already convert timestamps to strings elsewhere. With the TurtleCoin adapter this became an issue.

Instead of DATE_ISO8601 I should have used the string literal 'Y-m-d H:i:s'. I will fix this in the next patch release of wallets. In the meantime you can do the same change in your copy of wallets.

I’m still not sure why the current code works in some cases though.

Again apologies for all this trouble. I can’t believe I missed this.

with regards

[alexg]

Hello,

Oops, yes, you are correct, the symbol is ARMS. I mistakenly indexed the array by the string 2ACOIN. My apologies.

So when you use the following filter, with the code otherwise unmodified, decimals should work correctly:

function wallets_turtlecoin_adapter_filter( $coins ) {
    $coins['ARMS']['amount pattern'] = '%01.8f';
    $coins['ARMS']['decimals'] = 8;

    return $coins;
}
add_filter( 'wallets_turtle_coins', 'wallets_turtlecoin_adapter_filter' );

[alexg]

Yes, this is due to another feature request that is not related to the bug fix.

[alexg]

Hello,

The only thing that’s changed with respect to when the UI is shown, is the new capability. The plugin checks to see that the current user has the tip_the_author capability and that the author has the receive_tip capability. So first ensure that the capabilities are assigned to the users. If you assign the capabilities to the user roles, check to see if the capability is assigned to all the user roles for your users, as a user can belong to multiple roles.

Check the above and let me know if you are still encountering this issue.

with regards

[alexg]

Hello,

Regarding the login url, I can add an option to enter a login page. If the login page is set, then it will override the default login url. In the mean time, you can use the templating system to override the login text. The template shown is in wp-content/plugins/wallets-tips/templates/login.php.

Regarding the QR code feature, like I said earlier, I decided against it. While I do appreciate people sending in suggestions, this does not mean that I always implement them, or that I implement them within a specific time-frame. If you decide to hire a developer to implement the features you require, I can guide them through.

with regards

[alexg]

Hello,

When the fix will be out, the notification will be an internal transfer (move) message. Both the sender and the receiver will be notified.

with regards

[alexg]

Hello,

I have looked into this and have provided a fix in version 2.1.0 of the extension. It looks like the issue arises if the post’s author is a deleted user.

with regards

[alexg]

Hello,

In version 2.1.0 of the extension, the UI is only shown if both of the following are true:

– the current user has the tip_the_author capability.
– the author of the post or page has the receive_tip capability.

So make sure to use the admin screen Wallets → Capabilities to assign the correct capability to your user roles.

with regards

[alexg]

Hello,

In version 2.1.0 of the extension, if the user is not logged in, they get a link to login in place of the tipping UI. The link redirects to the same page after login.

with regards

P.S. I will not be implementing QR codes. Any such tips would not be counted as tips but as deposits, so it would defeat the whole point of the plugin’s architecture.

[alexg]

Hello,

In version 2.1.0 there is now an admin option on whether you want the form to be open by default on page load.

with regards

[alexg]

Hello,

I’ve looked at this and it’s actually not related to the Tip the Author extension. It’s a bug in the parent plugin. Internal transfers that are initiated with skip_confirm=true do not trigger the notification mechanism. I have developed a fix which will be pushed out on the next release of Bitcoin and Altcoin Wallets.

with regards

[alexg]

Hello,

I have NOT had the time to test with 2ACoin.

What value did you insert in the code to make it work? If you are certain that this value works, I can put that value in there.

with regards

[alexg]

Hello,

This is by design.

The adapter always re-scans the last 1000 blocks to detect any changes in the status of recent transactions.

with regards

[alexg]

According to digital ocean, their managed DB is a MySQL 8, so I don’t see why it wouldn’t work.

Additionally I couldn’t find on the web any reason why an ISO8601 string would not be inserted into a datetime column, in any version of MySQL.

I asked to see the server version to ensure that you’re not on a weird type of SQL that has different rules.

You can see the MySQL version in the WordPress admin dashboard (first item in the left-side menu). There should be a panel titled “Bitcoin and Altcoin Wallets”. It has several tabs, and there’s a “Debug” tab. Under it there’s some information. We’re interested in “MySQL version”.

Alternatively, you can type into your MySQL console this: SELECT VERSION(); This will give the same information.

As for the MySQL log, there should be a way for you to access it.

Since this is a strange issue, try to access the MySQL server log. It’s your best chance to figure out what’s wrong.

You can also use a temporary table to test and see if your server behaves as expected:

CREATE TEMPORARY TABLE timestamps( created_time DATETIME NOT NULL );

INSERT INTO timestamps VALUES('2020-08-06 10:00:00');

SELECT * FROM timestamps;

What do you get as result?

[alexg]

Hello,

Ok you have isolated the issue sufficiently. This is a good start. Thank you.

I have tested the plugin with MySQL and it should be compatible with MariaDB.

To further track down the issue, please do the following.

On the server where you can reproduce the issue, please go to the admin dashboard. Under “Bitcoin and Altcoin Wallets” you will find a “Debug” tab. Please let me know what the “MySQL version” is. For example, on my dev machine, I have 5.7.31-0ubuntu0.18.04.1-log.

The plugin takes an integer timestamp and inserts it into the created_time column of type datetime. As you say, it first converts it into a string, here. There should be something in your MySQL server logs regarding this. Perhaps a warning on the INSERT statement?

While you wait for the reply from digital ocean, I will look on the web to see in what server versions or configurations this can happen.

In summary: Please let me know what MySQL version you see in the debug tab, so I can narrow down my search. If you can also check the MySQL log, that will also be helpful.

with regards

[Author]

Posts