paulred222

Resolved

For those looking at this I have fixed it. The issue was that I had the old application password plugin installed – it is now included in core WordPress. I deactivated and removed the plugin, revoked and recreating the ones in the system. All now fine!

Thank you. This is helpful. This is a a development instance so in subfolder devel7.

So I’ve amended my htaccess to be close to yours

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /devel7/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /devel7/index.php [L]
</IfModule>

But sadly still does not work.

I think I will find the wordpress code which generates that error message and add some tracing to see if I can track it down. If I make progress I will post back here.

Thank you for your ideas and help.

Makes sense, but I’ve tried revoking, recreating the password and it fails. The authentication made up of username and application password is of course sent as a single base 64 encoded string, so I do not understand why the username gets decided ok but the password does not.

Very good thought but sadly with and without spaces still fails.

BTW if I change the username in the basic auth tab in postman it detects it – I can:
"code": "invalid_username",
"message": "Error: unknown username. Check again or try your email address.",
"data": {
"status": 401
}

With all three lines in my original post in htaccess. So the basic auth is getting through to some extent.

Hi Peter

That is fantastic and it works. Great product and great support. Thank you.

Paul

This is a WordPress bug or feature. I thought for a time it was due to me storing the raw instead of base64 data in the database which has the image but this is not the case – I changed it to store the image in base64 and it still fails.

In the code the line with comment //*** changes the logo data read from the database to a hard coded red dot. Works fine. Comment it out to use the picture data read from the database and I get the error.

But use other images and it is fine. It is definitely an accident of the image data.

Looking at the code where the error occurrs in formatting.php, this code scans for smilies and I think it is wrongly detecting something in the image data as a smilie tag or something like that. This is WordPress 5.7.2

$eventData['Logo']="iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=="; //***
			$logohtml=""; //get logo if required
			if ($eventData["Logo"]) {
					$logohtml='<img width="15%" height="15%" src="data:image/'.$eventData['LogoType'].';base64,'.$eventData['Logo'].'"/>';
				  //$logohtml='<img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />';
			}

I am on track to find the underlying cause – it isdata dependent. The image was being read from a database field then encoded using base64_encode($eventData[“Logo”])
If I tried various other images it all worked fine. But the image causing the problems uploaded fine and was displayed perfectly in the datatables part of the code which still uses base64_encode($eventData[“Logo”]) with an identical img tag.

Thanks. I have tried Dion’s code but get exactly the same error. It is strange as I am using almost exactly the same code for the same image in a plugin I wrote invoked via a shortcode, which works perfectly and which gives the same html. In the plugin case the image is in a datatables table.

So I have:
Code invoked by shortcode implemented in code snippet. Not in a table. Fails
Code involved by shortcode implemented in plugin and in a databable. Works fine.

I wonder if the failing one is due to some other characteristic of the code snippet. I am investigating.

Thanks for this. The error is in formatting.php which is definitely WordPress code. I think the sequence is that the code is generated/emitted in the snippets plugin but then processed by formatting.php. The function where it fails in this is the one which replaces smilies.

Thank you. I did not look at the documentation closely enough and assumed hidden was an extra attribute, not a field type. All sorted.

Paul