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.

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.

This guide will show you how to setup a new project using Ember and Laravel, JSON-API and token based authentication.  The deployed version of your application will be a Laravel backend which serves up the Ember frontend using a Laravel route.

Software

At the time of writing the tools used are:

• Laravel 5.1 (LTS)
• Ember 2.4.1 (LTS) with Ember-CLI 2.4.1
• Dingo API 1.0.0 (beta)
• Tymon jwt-auth 0.5.9
• ember-simple-auth 1.0.1
• ember-simple-auth-token 1.0.0

Prerequisites

1. Ember CLI 2.4.1
2. Laravel Requirements
3. Composer
4. Git or any other VCS that you prefer

Initial Setup

The basic project structure will be a backend directory for the Laravel part, and a frontend directory for Ember.

#create a directory called sample-project
mkdir sample-project
# go into the sample-project directory
cd sample-project
# make the project a Git project
git init .

For .gitignore files I prefer using gitignore.io which creates a .gitignore file for the software that you use.  Just generate one that matches your needs, I use the following: OSX, Composer, Laravel, PHPStorm, Vagrant but you can customise for your own needs.  Just generate and add this to the root of your sample project e.g.

wget "https://www.gitignore.io/api/osx%2Ccomposer%2Claravel%2Cphpstorm%2Cvagrant" -O .gitignore

NOTE: I don’t like that gitignore’s Laravel setup excludes the full storage directory – which can cause problems during deployment.  Instead I manually remove the following line from the .gitignore file and use the .gitignore files already provided by Laravel in each storage subdirectory.

storage/

It also selectively excludes certain PHPStorm files (.idea) whereas I prefer ignoring the full .idea directory:

# Add .idea to the .gitignore file
echo ".idea" >> .gitignore

Laravel (Backend) Setup

I prefer to use the LTS releases of Laravel, so will be installing version 5.1

# Install Laravel 5.1 to a directory called backend
composer create-project laravel/laravel backend "5.1.*"
# Switch into the backend (Laravel) directory
cd backend

Your current project structure should now look like this:

# Delete the .git directory from backend as we already have our Git project setup in the project root
# Make sure you are in the backend directory (don't delete .git in your project root directory)
rm -Rf .git

# Add all the Laravel files and commit the project
git add .
git commit -a -m "Added Laravel 5.1"

Add your database configuration to the .env file by updating the following lines:

DB_HOST=localhost
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

# Migrate the default Laravel tables
php artisan migrate

Install Dingo API

The Dingo API package has comprehensive documentation available but for the sake of this guide I’ll go through a quick setup.  I highly recommend you read through the documentation and configuration so that you can make your API work appropriately for you.

# Install the Dingo API package
composer require dingo/api:1.0.x@dev

Add the Dingo API service provider class to the list of Laravel providers (config/app.php)

Dingo\Api\Provider\LaravelServiceProvider::class,

Publish the Dingo API config file

php artisan vendor:publish --provider="Dingo\Api\Provider\LaravelServiceProvider"

Add some basic config options to the .env file

API_PREFIX=api
API_VERSION=v1
API_DEBUG=true

# Git commit the changes (Dingo API Installation)
git add .
git commit -a -m "Installed Dingo API"

Install Tymon JWT-Auth

The JWT-Auth token package is only required if JWT (JSON Web Tokens) is an authentication method that you plan to use in your application.  This tutorials assuems that you will be using it, but if you’re not then just skip the appropriate parts.

This package also has great documentation available that you’re advised to read through to make sure you set it up in a way that works for you but the few steps below will get you started

# Install Tymon JWT-Auth
composer require tymon/jwt-auth

Add the JWTAuth Service provider to the providers section in config/app.php:

Tymon\JWTAuth\Providers\JWTAuthServiceProvider::class,

Add the JWTAuth facade to the aliases section in config/app.php

'JWTAuth' => 'Tymon\JWTAuth\Facades\JWTAuth',

# Publish the JWTAuth config file
php artisan vendor:publish --provider="Tymon\JWTAuth\Providers\JWTAuthServiceProvider"
# Generate JWT Auth secret key
php artisan jwt:generate

Now that the JWT Auth and API packages are installed, we need to configure the API to use JWT for it’s authentication method.  Luckily this can be done very easily in the API config file located in config/api.php

Find the following section:

And add the following within the auth array:

'jwt' => 'Dingo\Api\Auth\Provider\JWT',

git add .
git commit -a -m "JWT auth package installed"

Using JSON API

JSON API is a standard for APIs that use JSON data and has been the default adapter setting in Ember since version 2.0.  In order to make the API return JSON API formatted data we just need to configure Dingo API to use the JsonApiSerializer that it comes bundled with.

in app/Providers/AppServiceProvider.php

First add the following use statements:

use Dingo\Api\Transformer\Adapter\Fractal;
use Illuminate\Support\ServiceProvider;
use League\Fractal\Manager;
use League\Fractal\Serializer\JsonApiSerializer;

Add the following to the boot() method within this service provider:

// API uses JSON API
$this->app['Dingo\Api\Transformer\Factory']->setAdapter(function ($app) {
     $fractal = new Manager();
     $fractal->setSerializer(new JsonApiSerializer());
     return new Fractal($fractal);
});

git add .
git commit -a -m "API uses JSON API serializer"

Setting up the Laravel Router

Below you’ll find the template of the Laravel routes file (app/Http/routes.php) that which you can download from my laravel-ember-starter repo

<?php

/*
|--------------------------------------------------------------------------
| Application Routes
|--------------------------------------------------------------------------
|
| Here is where you can register all of the routes for an application.
| It is a breeze. Simply tell Lumen the URIs it should respond to
| and give it the Closure to call when that URI is requested.
|
*/

// API Routes come first
$api = app('Dingo\Api\Routing\Router');
$api->version('v1',function($api){
    header('Access-Control-Allow-Origin: http://localhost:4200');
    header('Access-Control-Allow-Headers: Origin, Content-Type, Authorization');
    header('Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, PATCH, DELETE');

    // API
    $api->group(['namespace'=>'App\Http\Controllers\Api'],function($api){
        // Auth
        $api->post('auth/login','Auth\AuthController@postLogin');
        $api->post('auth/token-refresh','Auth\AuthController@refreshToken');
        $api->post('users','Auth\UsersController@store');

        // Protected methods (require auth)
        $api->group(['middleware'=>'api.auth'],function($api){
            
        });

        // Public methods
        
    });
});

// Catchall - Displays Ember app
Route::any('{catchall}',function(){
    return view('index');
})->where('catchall', '(.*)');

Few notes on the above routes.php file:

1. http://localhost:4200 is the default address when using Ember serve to develop your app
2. All the API requests are handled first
3. All non-API requests are caught by the final catch all rule, which returns the index view
4. The index view will return the Ember application
5. I prefer to use App\Http\Controllers\Api as my root namespace for API controllers, but you can amend this as necessary

Authentication

As you can see in the above routes file, we have two Authentication routes:

To implement these methods we’ll first need to create the app/Http/Controllers/Api/Auth/AuthController.php file and setup the authentication methods

<?php
namespace app\Http\Controllers\Api\Auth;


use App\Http\Controllers\Controller;
use Dingo\Api\Http\Request;
use Dingo\Api\Routing\Helpers;
use Symfony\Component\HttpKernel\Exception\HttpException;
use Symfony\Component\HttpKernel\Exception\UnauthorizedHttpException;
use Tymon\JWTAuth\Exceptions\JWTException;
use Tymon\JWTAuth\Exceptions\TokenInvalidException;

class AuthController extends Controller
{

    use Helpers;

    public function postLogin(Request $request)
    {
        // grab credentials from the request
        $credentials = $request->only('email', 'password');

        try {
            // attempt to verify the credentials and create a token for the user
            if (! $token = \JWTAuth::attempt($credentials)) {
                throw new UnauthorizedHttpException("Email address / password do not match");
            }
        } catch (JWTException $e) {
            // something went wrong whilst attempting to encode the token
            throw new HttpException("Unable to login");
        }

        // all good so return the token
        return $this->response->array(compact('token'));
    }

    public function refreshToken(Request $request)
    {
        $token  =   $request->get('token');
        if(!$token)
        {
            return $this->response->errorBadRequest('Token not provided');
        }
        try {
            $token  =   \JWTAuth::refresh($token);
        }
        catch(TokenInvalidException $e) {
            return $this->response->errorForbidden('Invalid token provided');
        }
        return $this->response->array(compact('token'));
    }

}

The login method will get the email and password from the request, try to authenticate and then return errors on failure (Dingo handles exceptions) and a token on success
refreshToken gets the token from the request, and then attempts to refresh the token (generating a new token).

Full contents of the controller including traits and use statements can be downloaded from my laravel-ember-starter repo

git add .
git commit -a -m "Added Authentication methods"

Laravel Finishing Touches

In app/Http/Kernel.php comment out or delete the line:

\App\Http\Middleware\VerifyCsrfToken::class,

If you want to create a test user (change the credentials to whatever you want) to test your authentication

# Create a dummy user
php artisan tinker
App\User::create(['email'=>'email@domain.com','password'=>bcrypt('password')]);
exit

git add .
git commit -a -m "Laravel Setup complete"

Laravel Summary

That’s it with the Laravel setup for now.  Whilst there’s quite a few steps the idea is quite simple:

1. Install Laravel
2. Add API support
3. Add JWT setup
4. Setup the API to use JSON API
5. Add authentication methods

Ember Frontend Setup

Now that the API setup is ready we focus on creating a new Ember project to use as the frontend.

Initialize Project with Ember-CLI

# go back up to the project root directory
cd ..
# create a new Ember project called 'frontend'
ember new frontend
# go into the 'frontend' directory
cd frontend
# delete the .git folder created by Ember (in the frontend directory - don't delete the one in your project root)
rm -Rf .git
# add the Ember project to our Git repo
git add .
git commit -a -m "Added Ember project"

When developing applications I use Vagrant for serving the Laravel app, and the Ember-CLI built in server.  This gives me two URLs:

1. http://myapp.local – which goes to the Laravel application running on Vagrant
2. http://localhost:4200 – the default URL for the Ember application using ember serve

For the application to work, we need to make the Ember application aware of the Laravel URL so that we can make API requests to it.  To do this I specify the API url as a config setting in Ember.  In config/environment.js add the following line (replace the URL with your Laravel application URL):

ENV.apiBaseUrl = 'http://sample-project.local';

You’ll notice in that config file that there’s sections where you can specify environment specific settings (e.g. development and production) which means you can set the above option separately for each environment.

Add Authentication Packages

For authentication with Ember we’ll use Ember Simple Auth base package, with Ember Simple Auth Token since we need JWT support.

# Install Ember Simple Auth
ember install ember-simple-auth
# Install Ember Simple Auth Token
ember install ember-simple-auth-token

Then to configure the Auth packages add the following to config/environment.js:

ENV['ember-simple-auth'] = {
  authorizer: 'authorizer:token'
};
ENV['ember-simple-auth-token'] = {
  refreshAccessTokens: true,
  timeFactor: 1000,
  refreshLeeway: 300,
  serverTokenEndpoint: ENV.apiBaseUrl + '/api/auth/login',
  serverTokenRefreshEndpoint: ENV.apiBaseUrl + '/api/auth/token-refresh',
  identificationField: 'email'
};

You can update the options to suit your requirements if necessary

Login

# generate the login route
ember g route login

Create a simple form in the login template app/templates/login.hbs

{{#if errorMessage}}
    {{errorMessage}}
{{/if}}
<form {{action 'authenticate' on='submit'}}>
  <label for="identification">Login</label>
  {{input id='identification' placeholder='Enter Login' value=identification}}
  <label for="password">Password</label>
  {{input id='password' placeholder='Enter Password' type='password' value=password}}
  <button type="submit">Login</button>
</form>

Make the route available only when the user isn’t logged in, and clear the errors when the user goes to a different page by editing the login route file in app/routes/login.js

import Ember from 'ember';
import UnauthenticatedRouteMixin from 'ember-simple-auth/mixins/unauthenticated-route-mixin';

export default Ember.Route.extend(UnauthenticatedRouteMixin,{
    resetController(controller,isExiting)
    {
        if(isExiting){
            controller.set('errorMessage', '');
        }
    }
});

# Create the login controller
ember generate controller login

Handle authentication attempts in the login controller app/controllers/login.js

import Ember from 'ember';

export default Ember.Controller.extend({
  session: Ember.inject.service(),

  actions: {
    authenticate: function() {
      var credentials = this.getProperties('identification', 'password'),
        authenticator = 'authenticator:jwt';

      this.get('session').authenticate(authenticator, credentials).catch((message) => {
        this.set('errorMessage', message.message);
      });
    }
  }
});

Authenticating API Requests

At this point authentication should be working properly, but we still need to configure Ember to send the token in API requests to access protected endpoints.  In order to do this we’ll extend the Ember JSON API adapter and configure it to use the Token Authorizer from Ember Simple Auth Token.

# Create the adapter
ember g adapter application

Update the adapter in app/adapters/application.js

import DS from 'ember-data';
import ENV from 'frontend/config/environment';
import DataAdapterMixin from 'ember-simple-auth/mixins/data-adapter-mixin';

export default DS.JSONAPIAdapter.extend(DataAdapterMixin,{
	host: ENV.apiBaseUrl,
	namespace:'api',
	authorizer: 'authorizer:token',
	handleResponse: function(status, headers, payload){
		// If the response is 422 (Unprocessable Entity) then format the errors into JSONAPI format
		if(status === 422 && payload.errors){
			let error_response	=	[];
			for(var key in payload.errors) {
				error_response.push({id:key,title:payload.errors[key][0]});
			}
			return new DS.InvalidError(error_response);
		}
		return this._super(...arguments);
	}
});

As well as setting the authorizer the above adapter also sets the following options:

1. host – tells the adapter to make all requests to the apiBaseUrl that we specified in the config
2. namespace – Use the ‘api’ namespace for all requests (to match all the Laravel route structure)
3. handleResponse – format the errors for 422 errors

Logout

Logout is an action that can be accessed from any page with the application, so we’ll handle the logout action in the application controller.

# create application controller
ember g controller application

Create the invalidateSession method in the application controller: app/controllers/application.js

import Ember from 'ember';

export default Ember.Controller.extend({
	session: Ember.inject.service('session'),
	actions: {
		invalidateSession() {
			this.get('session').invalidate();
		}
	}
});

Of course you’ll want to add the logout link in your application template app/templates/application.hbs

<ul>
    {{#if session.isAuthenticated}}
        <li><a {{action 'invalidateSession'}}>Logout</a></li>
    {{else}}
        <li>{{#link-to 'login'}}Login{{/link-to}}</li>
        <li>{{#link-to 'register'}}Register{{/link-to}}</li>
    {{/if}}
</ul>

# git commit
git add .
git commit -a -m "Ember authentication implemented"

Registration

If your application requires user registration then use the steps below, and if you don’t need registration just comment out the line from backend/app/Http/routes.php:

$api->post('users','Auth\UsersController@store');

Backend Setup

We’ve already defined a route for creating new users in the backend/app/Http/routes.php file:

$api->post('users','Auth\UsersController@store');

The next step is to create a new controller with the Laravel project directory:

# Switch to the 'backend' directory
cd ../backend

Create app/Http/Controllers/Api/Auth/UsersController.php and populate the store action:

<?php
/**
 * Created by PhpStorm.
 * User: ash
 * Date: 02/03/2016
 * Time: 10:06
 */

namespace app\Http\Controllers\Api\Auth;


use App\Http\Controllers\Controller;
use App\User;
use Dingo\Api\Exception\StoreResourceFailedException;
use Dingo\Api\Http\Request;
use Dingo\Api\Routing\Helpers;

class UsersController extends Controller
{
    use Helpers;

    public function store(Request $request)
    {
        $data   =   $request->get('data')['attributes'];
        $validator  =   \Validator::make($data,[
            'email'     =>  'required|email|unique:users',
            'password'  =>  'required'
        ]);
        if($validator->fails()){
            throw new StoreResourceFailedException('Invalid user data',$validator->errors());
        }
        User::create(['email'=>$data['email'],'password'=>bcrypt($data['password'])]);
        return $this->response->noContent();
    }
}

The submitted data is validated, and detailed errors returned if validation fails. Otherwise we send back a success response with no content, which the Ember app will use to notify the user that registration is successful and that they can now login

The next step is to create a registration route and a user model:

# Switch back to the 'frontend' directory
cd ../frontend
ember g route register
ember g model user email:string password:string

Setup the registration template in app/templates/register.hbs

{{#if registered}}
    <h1>Registered!</h1>
    <p>Registration was successful.  You can {{link-to 'now login' 'login'}} with the credentials you registered with.</p>
{{else}}
{{#if errorMessage}}
    {{errorMessage}}
{{/if}}
<form {{action 'register' on='submit'}}>
    <p>Create a New Account</p>
    <label for="identification">Email</label>
    {{input id='identification' placeholder='Email Address' value=model.email type='email'}}
    <label for="password">Password</label>
    {{input id='password' placeholder='Enter Password' type='password' value=model.password}}
    <button type="submit">Register</button>
</form>
{{/if}}

The registration route needs a couple of updates to make it accessible to unauthenticated users, and to clear the error messages when the user leaves the page so update app/routes/register.js

import Ember from 'ember';
import UnauthenticatedRouteMixin from 'ember-simple-auth/mixins/unauthenticated-route-mixin';

export default Ember.Route.extend(UnauthenticatedRouteMixin,{
    model() {
      return this.store.createRecord('user');
    },
    resetController(controller,isExiting)
    {
        if(isExiting){
            controller.get('model').rollbackAttributes();
            controller.set('errorMessage', '');
        }
    }
});

Handle registration attempts in the register controller: app/controllers/register.js

# Create the register controller
ember g controller register

import Ember from 'ember';

export default Ember.Controller.extend({
    session: Ember.inject.service(),
    registered: false,
    actions: {
        register(){
            let self = this;
            this.get('model').save().then(()=>{
                self.set('registered',1);
            }).catch((error)=>{
                this.set('errorMessage',"Registration failed.");
            });
        }
    }
});

Setup Complete

That concludes the setup for the project. You have working logins and registration, a JSON API with authenticated routes and an Ember application ready for your custom code.

Deployments

You might have noticed that during the Laravel setup we setup a catchall route that returns an index view but we didn’t actually create the view. This is because it’s not required during development – we use Ember serve to load our Ember application instead.

Once you’re ready to deploy your project to production or staging you’ll need to build the Ember application and copy across the files into the Laravel public directory. I’ve created a simple script that I use for staging (and a similar script for production deployments). The idea is to have a production branch in the Git repo which is deployed on the server.

You can use the script below and modify it to suit your needs:

# create the publish-staging script
touch publish-staging.sh
# make the publish script executable
chmod a+x publish-staging.sh

Set the contents of the publish script publish-staging.sh

#!/usr/bin/env bash

# PUBLISH STAGING

# make sure we're in the master branch
git checkout master
git add .
git commit -a -m "Pre-publish commit"
git push
# switch to staging branch
git checkout staging
# merge master into staging
git merge master
# build the Ember application
cd frontend && ember build --environment staging && cd ..;
# clear public
rm -Rf backend/public/assets;
rm -Rf backend/public/fonts;
rm -Rf backend/public/index.html;
rm -Rf backend/public/crossdomain.xml;
# copy the new Ember build into the Laravel application
cp -R frontend/dist/assets backend/public
cp -R frontend/dist/fonts backend/public
cp -R frontend/dist/index.html backend/resources/views/index.blade.php
cp -R frontend/dist/crossdomain.xml backend/public
# git commit
git add .
git commit -a -m "Fresh Staging build"
git push origin staging

# switch back to master
git checkout master

This publish script goes in the project root and just make sure you stop your ember server before running it to prevent conflicts. The other thing to be aware of is uncommitted changes – as you can see the script above will switch to master and commit all uncommitted changes, which will cause problems if you’re currently working on a feature branch with uncommitted changes.

Summary

That’s a pretty full on guide to setting up a project that uses a Laravel backend and Ember as the frontend. Once complete you can get on with the meat and bones of the application.

Code Availability

You can find the files created and used within this application in my laravel-ember-starter project repo. If you like I can make the whole sample app available on Github so that you can have everything served to you without having to work through all the steps yourself. I’m reluctant to do this upfront as there’s a lot going on in the tutorial and I’d advise you to read through and understand what’s going on and make any neccessary changes as you see fit.

Feel free to leave comments and suggestions for improvements in the discussion area below.

The post Getting Started With Laravel and Ember appeared first on Cube Websites.

// Inline Style Images
$content    =   preg_replace_callback('/!\[(.*)\]\s?\((.*)(.png|.gif|.jpg|.jpeg)(.*)\)/',function($match){
    return str_replace('your_search_term','your_replacement',$match[0]);
},$content);

// Reference Style Images
$content    =   preg_replace_callback('/\[(.*)\]:\s?(.*)(.png|.gif|.jpg|.jpeg)/',function($match){
    return str_replace('your_search_term','your_replacement',$match[0]);
},$content);

Why Would You Need This?

I had to use the above code in a Laravel project where the content is entered into a frontend form in Markdown format. When saving the data in my Laravel backend app I wanted to replace the image URL with a placeholder so that the sites URL itself isn’t hardcoded into the database. When displaying the data, the placeholder is replaced with the URL of the site again. This means that if the URL ever changes (different dev environment, staging, production etc) then the images would still load providing that the files still existed in the same location on the server.

Your use case might be different but the above regex should provide you with a decent starting point to actually find the image tags (both inline and reference style) and then manipulate them however you wish.

The post [GUIDE] Find and Replace Markdown Image URLs in PHP appeared first on Cube Websites.

Usually this is a simple fix, just go in and type:

sudo yum install -y php-memcached

However, this time round the above was giving me the following error:

Transaction Check Error:
file /usr/lib64/libhashkit.so.2.0.0 conflicts between attempted installs of libmemcached-last-libs-1.0.18-2.el6.remi.x86_64 and libmemcached10-1.0.16-1.ius.centos6.x86_64
file /usr/lib64/libmemcached.so.11.0.0 conflicts between attempted installs of libmemcached-last-libs-1.0.18-2.el6.remi.x86_64 and libmemcached10-1.0.16-1.ius.centos6.x86_64
file /usr/lib64/libmemcachedutil.so.2.0.0 conflicts between attempted installs of libmemcached-last-libs-1.0.18-2.el6.remi.x86_64 and libmemcached10-1.0.16-1.ius.centos6.x86_64

After smashing my head against the desk a few times during numerous attempts at installing the module, reprovisioning the vagrant box and anything else I could think of doing to fix it, I tried something that hadn’t occurred to me before; to install the dependency it was complaining about first.

Using the following commands fixed my issue, and should also work for you:

sudo yum install -y libmemcached-last
sudo yum install -y php-memcached
sudo service php-fpm restart


Hope this helps!

The post FIX: Vagrant php-memcached error appeared first on Cube Websites.

==> default: Error: printf "\\n" | pecl -d preferred_state=stable install pecl_http returned 1 instead of one of [0]
==> default: Error: /Stage[main]/Puphpet_php/Puphpet::Php::Pecl[pecl_http]/Php::Pecl::Module[pecl_http]/Exec[pecl-pecl_http]/returns: change from notrun to 0 failed: printf "\\n" | pecl -d preferred_state=stable install pecl_http returned 1 instead of one of [0]
==> default: Warning: /Stage[main]/Puphpet_php/Service[php5-fpm]: Skipping because of failed dependencies

In order to fix this I logged into the server using SSH, and then manually ran the install pecl_http command that it was trying to run in the above error message.  In doing so I got a different error:

$ sudo pecl -d preferred_state=stable install pecl_http

pecl/pecl_http requires package "pecl/raphf" (version >= 1.1.0), installed version is 1.0.4
No valid packages found
install failed

It turns out that a pecl dependency was out of date and so it couldn’t install the pecl_http package.  In order to fix it I just ran the pecl upgrade command.

vagrant up
vagrant ssh
sudo pecl upgrade

After running the above, I tried my vagrant provision again, and hey presto! Everything was working again as normal

The post FIX: Vagrant Pecl Error appeared first on Cube Websites.

The Problem

I made all the following checks:

1. Valid SSL certificate
2. Webhook successfully registered using the Telegram setWebhook method
3. The method responded properly when I sent a test request using a REST service tester
4. Server access logs – look like Telegram had never even hit the server

The Solution

After a full day of searching, testing and bashing my head against the keyboard, I found this thread on Reddit, where the user described a problem where a full chained certificate was required on the server, not just the server certificate.

To create chained certificate you’ll need to have a look at what instructions your certificate issuer provides.

In my case the certificate being used was a Comodo PositiveSSL, for which I downloaded all the certificates that they sent, which contained:

• Root CA Certificate – AddTrustExternalCARoot.crt
• Intermediate CA Certificate – COMODORSAAddTrustCA.crt
• Intermediate CA Certificate – COMODORSADomainValidationSecureServerCA.crt
• Your PositiveSSL Certificate – my_domain.crt

I had to combine them all into a file in the following order:

• my_domain.crt
• COMODORSADomainValidationSecureServerCA.crt
• COMODORSAAddTrustCA.crt
• AddTrustExternalCARoot.crt

For the example above the command would have been:

cat my_domain.crt COMODORSADomainValidationSecureServerCA.crt AddTrustExternalCARoot.crt COMODORSAAddTrustCA.crt > bundle.crt

After that it was just a case of uploading the new bundle.crt to my server, updating the nginx config, and hey presto, within minutes I was receiving all the responses for my webhooks

The post FIX: Telegram Webhooks Not Working appeared first on Cube Websites.