Unable to negotiate with x.x.x.x port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

After looking up the error I was able to fix this by using the following instructions:

On your local machine, edit/create ~/.ssh/config

Add this (replace the x’s with the server IP)

Host x.x.x.x
    HostKeyAlgorithms=+ssh-dss

After this try connecting. You may need to remove the host from your known hosts first…

Edit ~/.ssh/known_hosts

Search for your server IP, and remove any matching line(s)

That’s all, after this you’ll be able to reconnect using your existing keys

The post Fix: SSH No Matching Host Key Type Found appeared first on Cube Websites.

This guide has been written with the current latest versions of the libraries:

• PEST 2.6.2
• Laravel 10.13.1

InsTALLATION

• Install Laravel using any of their methods detailed in the Official Documentation
• Install PEST using Composer. The flags in this command are very important as it’s likely that you’ll have conflicting dependencies and this will take care of that for you:

composer require pestphp/pest --dev --with-all-dependencies

• Install the Laravel Plugin for PEST

composer require pestphp/pest-plugin-laravel --dev

• At this stage the installation should be complete and running the following you can verify that things are working as they should

./vendor/bin/pest --version

The above should output the installed PEST version, which in my case is 2.6.2

php artisan pest

The output here should be the ‘Available commands for the “pest” namespace

Installation Troubleshooting

Info from https://repo.packagist.org: #StandWithUkraine
./composer.json has been updated
Running composer update pestphp/pest
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - pestphp/pest[v0.1.0, ..., v0.2.4] require php ^7.3 -> your php version (8.1.19) does not satisfy that requirement.
    - pestphp/pest[v0.3.0, ..., v0.3.19, v1.0.0, ..., v1.4.0] require nunomaduro/collision ^5.0 -> found nunomaduro/collision[v5.0.0, ..., v5.11.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.5.0, ..., v1.17.0] require nunomaduro/collision ^5.4.0 -> found nunomaduro/collision[v5.4.0, ..., v5.11.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.18.0, ..., v1.21.1] require nunomaduro/collision ^5.4.0|^6.0 -> found nunomaduro/collision[v5.4.0, ..., v5.11.0, v6.0.0, ..., v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.21.2, ..., v1.22.1] require nunomaduro/collision ^5.10.0|^6.0 -> found nunomaduro/collision[v5.10.0, v5.11.0, v6.0.0, ..., v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.22.2, ..., v1.22.5] require nunomaduro/collision ^5.11.0|^6.3.0 -> found nunomaduro/collision[v5.11.0, v6.3.0, v6.3.1, v6.3.2, v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest[v1.22.6, ..., v1.23.0] require nunomaduro/collision ^5.11.0|^6.4.0 -> found nunomaduro/collision[v5.11.0, v6.4.0] but it conflicts with your root composer.json require (^7.0).
    - pestphp/pest v2.6.2 conflicts with phpunit/phpunit >10.2.0.
    - pestphp/pest v2.6.1 conflicts with phpunit/phpunit >10.1.3.
    - pestphp/pest[v2.5.3, ..., v2.6.0] conflict with phpunit/phpunit >10.1.2.
    - pestphp/pest[v2.5.1, ..., v2.5.2] conflict with phpunit/phpunit >10.1.1.
    - pestphp/pest v2.5.0 conflicts with phpunit/phpunit >10.1.0.
    - pestphp/pest[v2.3.0, ..., v2.4.0] conflict with phpunit/phpunit >10.0.19.
    - pestphp/pest[v2.2.1, ..., v2.2.3] conflict with phpunit/phpunit >10.0.18.
    - pestphp/pest[v2.0.2, ..., v2.2.0] conflict with phpunit/phpunit >10.0.17.
    - pestphp/pest v2.0.1 conflicts with phpunit/phpunit >10.0.16.
    - phpunit/phpunit is locked to version 10.2.1 and an update of this package was not requested.
    - Root composer.json requires pestphp/pest * -> satisfiable by pestphp/pest[v0.1.0, ..., v0.3.19, v1.0.0, ..., v1.23.0, v2.0.1, ..., v2.6.2].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require pestphp/pest:*" to figure out if any version is installable, or "composer require pestphp/pest:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

If you see the error above, check the composer require command that you ran. You’ll need the flags displayed above to allow Composer to update your dependencies to satisfy PEST and Laravel.

Configuration

After installation you’ll find you can run the existing Laravel Example tests with the Pest command. This is because Pest is built on top of PHPUnit in a progressive manner.

If you try writing your own test e.g. consider the following:

<?php

it('makes an example request', function () {
    $response = $this->get('/');
    $response->assertStatus(200);
});

You may get an error like the following:

  FAILED  Tests\Feature\ExampleRequestTest > it get an example request                                                                                                                                                                                                 Error
  Call to undefined method Tests\Feature\ExampleRequestTest::get(). Did you forget to use the [uses()] function? Read more at: https://pestphp.com/docs/configuring-tests

  at tests/Feature/ExampleRequestTest.php:4
      1▕ <?php
      2▕
      3▕ it('get an example request', function () {
  ➜   4▕     $response = $this->get('/');
      5▕     $response->assertStatus(200);
      6▕ });
      7▕

  1   tests/Feature/ExampleRequestTest.php:4


  Tests:    2 failed, 2 passed (2 assertions)
  Duration: 0.08s

This is because Pest is not yet configured to use the Laravel TestCase which includes the additional methods such as get, post, actingAs etc.

To solve this we create a new file:

./tests/Pest.php

Add the following into the file

<?php
uses(\Tests\TestCase::class)->in('Feature');
uses(\Tests\TestCase::class)->in('Unit');

This tells Pest to use the Laravel TestCase in your Feature and Unit tests and makes the additional methods available to your Pest tests.

You can now run the test again, and this time it should run without the error

Database Setup (Optional)

Unit tests test blocks of code and so don’t require the Laravel application to start. However, with Feature tests you’ll find that they do boot the Laravel application and everything within – including a database connection. By default, it will connect to whatever you Database Connection is defined as in your .env file which means your tests end up writing to your dev database. This may be fine, but I prefer keeping a separate databases for Dev and Testing.

There’s a number of ways to do this including using SQLite, but I find it’s better to run the same database type as I will be using in production to avoid any unforeseen issues. The easiest way to do this is to create a second database and then configure the connection using a .env.testing file – more information on this is available in the Laravel Docs.

Summary

I hope this guide helps anyone looking for a current installation of Laravel and Pest.

The post HOW TO: SETUP PEST PHP 2 WITH LARAVEL 10+ appeared first on Cube Websites.

This articles shares my findings and shows how easy it is to setup.

Setup your collection

Select an existing (or create a new collection) that you want translations for. Don’t add any fields that need translations just yet!

Next, click on Create Field and choose the ‘Translations’ type field:

If you like you can modify some of the field configuration by clicking the Continue in Advanced Field Creation Mode. For example I prefer using UpperCamelCase for my table names, so I modified the languages table name to Languages

Setup Translation Fields

Once you’ve done that go back to the Data Model screen. Here you’ll see a new hidden collection, in my case Categories Translations

Click into the Categories_Translations table, and within this collection add all the fields for Categories that need translations. e.g.:

Add Translated Content

Now, go to the Content menu and choose your collection. You’ll see the fields you’ve added to the Translations table appear with the option to fill them out in different languages.

Here you can use the Translations input to select a language, and then use the input fields below to populate the content in your selected Language. There’s even a split view which is very handy if you’re translating content from one language to another.

Managing Languages

You can control which Languages appear by modifying the entries in the Languages collection. By default Directus populates that table with 8 common languagues.

Hopefully this demonstrates how easy it is to add translated content in Directus. Of course, if there’s fields that don’t need translation you just add them in the parent table – in this case the Categories collection.

The post How To: Setup Content Translations In Directus appeared first on Cube Websites.

The general idea is to use a composer package to interact with Directus. We’ll register it in our AppServiceProvider which means we can call a pre-configured instance anywhere in our app using dependency-injection.

In Directus

• It’s advisable to create a new role for your Laravel Application. To make it easy to track I give it the name ‘laravel-app’
• Create a new user for your Laravel Application and assign it the new Role you just created
• On the Edit User screen, find the ‘Token’ field. Generate a token and make a note of it somewhere

In Laravel

• Now switch to your Laravel app. For this integration, I’m using a composer package from https://github.com/alantiller/directus-php-sdk
• Install the package:

composer require alantiller/directus-php-sdk

• In your .env file add the following:

DIRECTUS_URL=https://directus.example.com
DIRECTUS_TOKEN=-YOURTOKEN

• Replace the Url with your actual Directus URL
• Replace YOURTOKEN with the Token you generated for your Laravel user in Directus
• In config/services.php add the following:

'directus' => [
    'url'   => env('DIRECTUS_URL'),
    'token' => env('DIRECTUS_TOKEN'),
],

In app/providers/AppServiceProvider.php add the following to the register() method

$this->app->singleton(Directus::class, function ($app) {
    $directus = new Directus($app['config']['services']['directus']['url'],'');
    $directus->auth_token($app['config']['services']['directus']['token']);
    return $directus;
});

In your code you’ll be able to now use Directus with the standard dependency injection. You can find examples on how to use the alantiller/directus-php-sdk package on Github.

Example:

php artisan make:command DirectusTest

In the handle method of the generated command:

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;

class DirectusTest extends Command
{
    /**
     * The name and signature of the console command.
     *
     * @var string
     */
    protected $signature = 'directus:test';

    /**
     * The console command description.
     *
     * @var string
     */
    protected $description = 'Command description';

    /**
     * Execute the console command.
     *
     * @return int
     */
    public function handle(\Slations\DirectusSdk\Directus $directus)
    {
        dd($directus->users_me());
    }
}

Call the command:

php artisan directus:tset

The output should show you details of the Laravel App user you added on Directus. Once it’s working delete the command.

This is all it takes to have a fully working Directus integration with Laravel. The package does most of the work, but registering it in your AppServiceProvider means you’ll get a connected instance whenever you need to use it instead of having to instantiate it.

Note that this application uses an application token which is tied to a single user. If you need multi-user support then the package supports login so you can authenticate users and use their auth token.

The post HOW TO: Using Laravel with Directus 9 appeared first on Cube Websites.

docker ps | grep 8029

This searches through your docker containers, and finds any that are running on port 8029. The output should look like this:

fec0c35f0b2d directus/directus:latest "docker-entrypoint.s…" 15 minutes ago Up 5 minutes 127.0.0.1:8029->8055/tcp directus-example

In the above example you can see that port 8029 was identified to be in use by the directus-example container. It turns out I did a test install of Directus on that port, and then forgot to delete it.

Stop the docker container:

docker stop fec0c35f0b2d

The container ID (fec0c35f0b2d) used above is from the first command which provided the container ID

Delete the docker container. In my case I no longer needed this Directus container, so I deleted the container too. If you need to keep your container, then just change its configuration to run on a different port that doesn’t clash.

docker rm fec0c35f0b2d

With this complete, I was able to start the Docker container that’s actually supposed to be running on port 8029 with no issues.

In my case I knew that the port would be used by Docker because I use that port range for Docker only. If you don’t know for sure that it’s Docker using the port, then you can use the following to check which service is using the port. Note that you will need sudo access to run this.

sudo netstat -tulpn | grep 8029

The output from this should tell you which service is using that port.

The post How To: Check Which Docker Container Is Using A Port appeared first on Cube Websites.

I’ve now setup a new integration which uses some additional tools (Directus and n8n) to help with this process. The below provides a quick run-through of the process and explanation of this approach.

Advantages

Directus provides a quick way of creating an API around data models. They offer a free cloud version which is perfect for this small-scale integration. It can also be self-hosted in a number of ways, including using Docker which makes it very easy to setup.

Note that you don’t necessarily need Directus – you could use a database (e.g. MySQL) and replace the n8n API calls with database queries instead.

n8n (nodemation) is a powerful automation tool similar to Zapier or Logic Apps. You can build workflows to help you achieve complicated processes using simple building blocks. This also has a Cloud version (paid) or a self-hosted version.

Using the above means that I have far more control over what is going out to Mastodon, and can easily be expand to cover additional platforms e.g. Telegram, Slack or Teams.

• messages can be customised to your liking
• messages can be deleted if a post is updated, and you can resubmit
• you use your own Mastodon account so your profile can be managed fully

The Process

1. In Directus create a Collection called ‘rss_feed_items’ with a field called ‘guid’. This is used to track posts which have already been sent to Mastodon to prevent duplicates
2. In n8n, use a Schedule trigger to run every 5 minutes or so
3. Use the RSS block to fetch the RSS feed for your WordPress blog
4. Use the HTTP block to get a list of existing guids from the Directus API
5. Use the Merge block to keep only new blog posts
6. Use a Code block to prepare the message for Mastodon i.e. get the title, link and convert the categories to hashtags
7. Use the Mastodon block to post the message to Mastodon. This is a third-party block at the moment.
8. Use the HTTP block to call the Directus API and create a record for the guid of the blog post

Using this method, if a blog post is updated, I can just edit my post on Mastodon. It could actually be made more sophisticated by keeping the Mastodon status ID and Mastodon post content in Directus with the GUID, and then if the new content is different to the old n8n can delete the old post and create a new post for you.

Note that on the first run, it will send all the posts that appear on your current RSS feed to Mastodon.

Enjoy!

The post Guide: Using n8n to Send New WordPress Posts to Mastodon appeared first on Cube Websites.

The project was configured to:

• run on MAMP
• the MAMP host was configured to use SSL
• Laravel 9
• Vite
• InertiaJS

The Problem

When running the default project with yarn run dev and accessing the project in the browser via the hostname configured in MAMP, the hot reload feature was not working and the network and console tabs in Developer Tools were polluted with lots of 404 errors about the failure to connect to the Vite Ping URL e.g. __vite_ping to which it keeps trying to reconnect to.

How to fix

You have to configure Vite to run on https. This can be done in a number of ways, but the easiest is to use the @vitejs/plugin-basic-ssl plugin. It’s really easy to get started:

1. Add the plugin to your project
   • with yarn: yarn add --dev @vitejs/plugin-basic-ssl
   • with npm: npm i @vitejs/plugin-basic-ssl
2. Open the vite.config.js file in your Laravel project
3. Import the plugin at the top of the file:
   • import basicSsl from '@vitejs/plugin-basic-ssl'
4. Enable the plugin using the defineConfig block e.g.

export default {
  plugins: [
    basicSsl()
  ]
}

Note: you might already have other plugins or config options in the defineConfig block, but you just need to make sure you add the called to basicSsl() in the plugins section.

After this when you run your project using yarn run dev it will provide you with a Local URL e.g.

11:15:06 [vite] vite.config.js changed, restarting server...
11:15:06 [vite] server restarted.

  > Local: https://localhost:3000/
  > Network: use `--host` to expose

Open that Local URL in your browser and you’ll receive an SSL warning. Accept the risks to accept the SSL certificate generated by the plugin.

Once that’s done when you visit your application dev URL, you’ll see all the Vite 404 errors have disappeared and you’re left with one neat little log that tells you Vite is now connected.

[vite] connecting... client.ts:16:8
[vite] connected. client.ts:53:14

Hope this helps!

The post HOW TO: Using Laravel with Vite on MAMP appeared first on Cube Websites.

The idea is to automatically make all your blog posts on WordPress available on the Fediverse that people can follow on their apps such as Mastodon.

Caution: before doing this read the notes below around the downsides to this integration.

Doing this is really easy…

1. Note that this will only work on self-hosted WordPress installations
2. Note that there’s very limited configuration options
3. Install the ActivityPub for WordPress plugin
4. Activate it
5. Done – on the plugin settings page it will give you the username and URL that can be shared for others to follow. Any new posts will start to appear to all followers.

Quick fix: when I installed the plugin and went to the Health Checks page, it was showing that my author page was not returning valid JSON with the error:

Your author URL https://cubewebsites.com/author/Cube Websites/ does not return valid JSON for application/activity+json. Please check if your hosting supports alternate Accept headers

The reason for this issue was that the author name format in the URL is from an old version of WordPress. To fix it all you need to do is:

1. Connect to your database using a management tool e.g. phpMyAdmin, TablePlus etc
2. Go to the users table
3. Find your user account
4. Change the user_nicename field to a username/slug format i.e. no spaces, lowercase
5. Save the changes
6. You’ll now see that your author page starts to work and the error message goes away

Why do this?

I only set this up to test this feature out. It’s quite cool but extremely limited as it creates a Fediverse presence for your site with little to no control. From what I can tell it registers your site domain as a Fediverse server to give you a unique presence.

The following is all missing:

• option to modify a post once it’s published
• specify hashtags to include (very useful on Mastodon)
• personalise your profile directly
• receive notifications for any engagement with your content i.e. replies and favourites
• changing your Fediverse address

The Fediverse address, it’s always @admin@yourdomain.com which isn’t a particularly appealing good name in this world of vanity usernames. For profiles it will pick up your profile picture from the user account, so you can modify that. Perhaps it picks up additional fields from your WordPress user profile but I haven’t explored that far.

I made a post that I published without setting the category, so the URL includes the ‘uncategorized’ slug. After fixing this mistake, there was no way to go back and change the automatic post it’s pushed out on the Fediverse feed.

Alternative Approaches

1. An easy option is to create a Fediverse account on an existing Mastodon server. Then connect your blog to push to this account using the API via a plugin, or via the RSS feed
2. Setup your own Mastodon server so you can use your own server address instead of a general one, and then use that to push the same way as above
3. Explore Friendica which seems to have the option of making RSS Feeds into Fediverse accounts

My preferred option is Option 1, and perhaps at a later date when I have the time to setup my own server, I would migrate the account to that server. It provides the most control and personalisation and means you can use the Mastodon app to engage with readers.

The post How To: Add Your WordPress Blog to the Fediverse appeared first on Cube Websites.

E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

This is because the current stable for Debian is now Bullseye, and Buster is considered ‘oldstable’
To fix the error and continue receiving Buster updates (whilst available) run:

apt-get update --allow-releaseinfo-change

You may need to run it as sudo

Eventually it will be better to upgrade your Raspbian version to the latest.

The post FIX: Raspberry PI UPDATE ERROR appeared first on Cube Websites.

Preparing to edit /etc/exports. Administrator privileges will be required…

Password:
tee: /etc/exports: Operation not permitted
tee: /etc/exports: Operation not permitted
tee: /etc/exports: Operation not permitted

You can quickly fix this issue by following the following steps:

1. Open “System Preferences”
2. Go to “Security & Privacy”
3. Click the “padlock” icon in the bottom-left corner where it says “Click the lock to make changes” – enter your password when prompted
4. On the list of permissions on the left, select “Full Disk Access”
5. Now, on the right-hand side, click the little “+” icon
6. This will open a browse window, use this to select your preferred Terminal e.g. “Applications > iTerm” or “Applications > Utilities > Terminal”
7. If the selected Terminal is already open, you’ll be asked to Quit it – quit the application and restart it
8. When you restart the selected application, you may prompted if you’d like to allow the app to make changes to your computer – accept and enter your password if required
9. Try mounting your vagrant machine and now the above error should no longer appear!

Note that this is a solution that I have tried and tested, but will be worth keeping an eye out for Vagrant/Virtualbox updates to see if they have an alternative solution.

The post Quick Fix: MacOS Mojave Vagrant Error – tee: /etc/exports: Operation not permitted appeared first on Cube Websites.