mercredi, 11 juillet 2018

Migrer un site Wordpress

Wordpress

Pour migrer un site Wordpress d'un espace vers un autre, il convient de distinguer l'hébergement 1 (source) et l'hébergement 2 (destination).

  1. Exportez les fichiers depuis l'hébergement 1 vers l'hébergement 2 (votre espace FTP ou local, sous var/www (LAMP/MAMP), wamp/www (WAMP), xampp/htdocs (XAMPP))
  2. Exportez la base de données .sql présente dans votre SGBD 1 (ex : PhpMyAdmin ou Adminer)
  3. Créez une nouvelle base de données ou, si vous n'en avez pas la possibilité, préfixez vos tables avec de nouveaux indices en cherchant/remplaçant les mentions "wp_" au sein de votre fichier .sql par un autre préfixe. Par exemple = "wpnew_"
  4. Importez le fichier .sql(généré à l'étape 2) dans votre SGBD (destination)
  5. Modifiez le fichier wp_config à la racine des fichiers exportés à l'étape 1, changez vos identifiant d'utilisateur, mot de passe, serveur, et le nom de votre base de données si vous en avez changé
  6. Utilisez DB search & replace, placez le fichier décompressé à la racine de votre nouveau dossier Wordpress
  7. Rendez-vous à l'adresse où se situe le dossier DB Search & replace, saisissez vos identifiants de base de données et remplacez l'ancienne adresse URL (source) par la nouvelle (ex : http://monsite.fr par http://localhost/monsite) — pensez à réitérer l'opération une deuxième fois si vous avez saisi des adresses en https:// dans les articles/pages/médias de votre propre domaine
  8. Effectuez un Dry run (changements fictifs), observez si les modifications sont pertinentes et, si c'est le cas, réalisez ensuite un Live run (effectif et réel) qui modifiera toutes les entrées au sein de votre base
  9. Rendez-vous dans votre panneau de contrôle /wp-admin/. Après vous être identifié, rendez-vous dans Paramètres > Permaliens, et revalidez l'option précochée.
Votre déménagement devrait, en principe, être réalisé sans heurts ! ;)

mardi, 5 décembre 2017

RedBeanPHP, un ORM

RedBeanPHPRedBeanPHP est un ORM (Object-Relational Mapping), c'est-à-dire un  type de programme informatique qui se place en interface entre un programme applicatif et une base de données relationnelle pour simuler une base de données orientée objet (définition Wikipédia). RedBeanPHP permet d'interagir avec MySQL, PostgreSQL et SQlite. Parmi les ORM PHP les plus connus, on connaît entre autres Doctrine et Eloquent.

Installation

Pour l'installation de RedBeanPHP, rien de plus simple : il convient de télécharger le dossier compressé le plus récent, qui correspond au SGBDR que vous souhaitez utiliser. Ensuite, déposez le dans votre projet web en cours, et appelez-le dans les fichiers où des interactions avec la base de données sont nécessaires.


// ENTER.PHP

require_once('inc/rb.php');

Ensuite, effectuez la connexion à votre base de données dans un fichier tiers que vous appellerez derrière la ligne de code précitée.

require_once('inc/database.php');

// DATABASE.PHP

// effectuer la connexion
R::setup('mysql:host=localhost;dbname=chat_id','root','');

// vérifier la connexion
$isConnected = R::testConnection();
     if($isConnected !== true) {
       $_SESSION['message'] = "La connexion est inopérante";
       header('location:index.php');
     }

Pensez à installer également l'extension mbstring pour que l'installation fonctionne - à activer sous un Wamp via les paramètres, et à installer sous un Lamp comme suit :


sudo apt install php7.2-mbstring
sudo service apache2 restart

Ceci fait, si votre base de données est déjà créée, le CRUD (create, retrieve, update, delete) peut commencer.


CRUD

Create (INSERT)


// Attention, pour que les insertions passent, l'extension mbstring doit être installée.
$users = R::dispense('users');

$users->login = $user;
$users->password = $password;
$users->email = $email;

$id = R::store($users);

Retrieve (SELECT)

getAll, getRow, getCol génèrent des tableaux ; find, findAll, findMulti des objets.

// Recherche de toutes les données de la table 
$users = R::getAll('SELECT * FROM users');

// Recherche d'une ligne de données spécifique dans la base de données
$user = R::getRow('SELECT * FROM users WHERE login = :login', [':login' => $user]);

// Recherche d'une colonne spécifique
$onoff = R::getCol( 'SELECT onoff FROM onoff WHERE id = :id', [ ':id' => 1 ] );

// Recherche de données correspondant à une requête précise
$questions_user = R::getAll( 'SELECT id,titre FROM questions WHERE user_id = :user_id AND suite = :suite', [ ':user_id' => $user_id, ':suite' => 0 ] );

// Recherche de toutes les données de la table 
$articles = R::findAll('articles', ' ORDER BY date DESC');

// Recherche de données correspondant à une requête précise 
$articles = R::find('articles', 'statut = ?  ORDER BY date DESC', array('1'));

// Compter toutes les valeurs de la table :
$numOfUsers = R::count( 'users' );

// Compter toutes les valeurs répondant à un critère précis
$numOfUsers = R::count( 'users','login = ?', [$user] ); // Compter le nombre de fois qu'est reprise la valeur spécifiée dans la table

// Compter toutes les valeurs répondant à plusieurs critères
$nb_questions_base = R::getCol( 'SELECT count(id) FROM questions WHERE user_id = :user_id AND suite = :suite', [ ':user_id' => $user_id, ':suite' => 0 ] );

// Jouer sur les paramètres descendant, ascendant, et la limite de résultat attendue
$statut_suite = R::getCol( 'SELECT state FROM questions WHERE suite = :suite ORDER BY id DESC LIMIT 1', [ ':suite' => $id_question ] );

Update (UPDATE)


$users = R::load( 'users', $user_id );

$users->mode_reponse = $mode_reponse_set;
R::store($users)

Delete (DELETE)


$table = R::load($_POST['table'], $_POST['id_mot']);
R::trash($table); //for one bean
R::trashAll($table);

Sources

lundi, 6 juin 2016

Laravel : utilisation (cas d’une page dynamique)

Route

Créons une route qui mènera à la page power (c'est-à-dire http://localhost/monprojet/public/power), et dont les opérations seront gérées par la méthode activate() de mon contrôleur TestController :


Route::get('power','TestController@activate');

 

Vues

Afin d'aller un peu plus loin dans la découverte de Blade, nous allons garder les vues default.blade.php et informations.blade.php, comme nous les avons créées précédemment, mais en y ajoutant un peu de contenu.

vues.png

1. Le gabarit default (vue générique / parent)

J'ai étendu le gabarit pour permettre de constater que @yield peut agréger autre chose que des sections nommées content :


<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Page de test</title>
</head>
<body>
<h1>Mon site test</h1>

@yield('header')
@yield('nav')
@yield('content')

</body>
</html>

Nous allons voir que les @yield('header') et @yield('nav') permettent d'agréger les sections nommées 'header' et 'nav' de la vue enfant, comme cela était le cas pour la section content.

2. La vue informations (vue spécifique / enfant)

Dans la page informations.blade.php sous mon dossier test, j'ai adapté le code pour quelque chose de plus complet, qui permette de jauger plus significativement le potentiel de Blade :


@extends('default')


@section('header')
    <form method="get">
        <input type="submit" name="etat" value="{{ $value }}">
    </form>
@endsection


@section('nav')
    <ul>
        @foreach($nav as $item)
            <li><a href="#">{{ $item }}</a></li>
        @endforeach
    </ul>
@endsection


@section('content')
@if($value !== 'Activer')
    @include('test.bonjour')
@endif
@endsection

Section "header"

Dans la section header, je crée un simple formulaire en méthode GET. Aucun changement n'est observable dans cette partie du code, à l'exception de la value du formulaire qui accueille une variable entre double accolades. Les double accolades permettent d'afficher le contenu d'une variable en l'échappant. {{ $value }} revient à écrire : <?php echo htmlentities($value); ?> Le contenu de cette variable n'est pas renseigné dans la vue puisqu'il est envoyé depuis le contrôleur – que nous créerons dans le point suivant – vers la vue.

Section "nav"

Dans la section nav, j'appelle un tableau envoyé par le contrôleur – voir plus loin – sur lequel je réalise une boucle foreach et affiche chaque élément du tableau en l'échappant : {{ }}. Bien sûr, le code est adapté à la sauce Blade, tant pour l'affichage du contenu des variables que pour la boucle itérative. S'il était produit en PHP, le script serait écrit comme ceci :


<ul>
   <?php
   foreach($nav as $item) {
   ?>
     <li><a href="#"><?php echo htmlentities($item); ?></a></li>
   <?php
   }
   ?>
</ul>

Le code est donc largement simplifié puisqu'il permet notamment de se passer des (rébarbatives) balises PHP.

Section "content"

Afin d'avoir fait un tour satisfaisant des options de Blade, j'ai créé dans la section content une condition spécifiant que si la variable $value (du header) est différente d' "Activer", j'inclus une autre page nommée bonjour.blade.php, située au même niveau que la présente vue, sous le dossier test. Le @if et le @include sont également propres à la syntaxe de Blade.

3. La vue bonjour : inclusion

Voici la vue bonjour.blade.php, qui sera embarquée quand le site sera établi comme "Activé" :


<p>Le service est activé ! Les épices, c'est bon.</p>
<hr>
<p>{{ "<strong>hibou</strong>" }}</p>
<p>{!! "<strong>hibou</strong>" !!}</p>
{{-- Un commentaire --}}

On y trouve : du contenu échappé, entre {{ }}, du contenu non échappé – qui sera donc interprété – entre {!! !!}, ainsi qu'un commentaire, entre {{-- --}}. Nous verrons ce que donne le résultat de ces trois lignes de code un peu plus bas.

Contrôleur

Comme prévu, nous voilà dans la méthode du contrôleur à laquelle menait la route.


<?php
namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class TestController extends Controller {

	public function activate(Request $request) {
		$nav = ['aneth', 'bergamote', 'coriandre', 'estragon', 'fenouil']; ➊
		$etat = $request->etat;
		if($etat == 'Désactiver') {
			$value = 'Activer';
		} else {
			$value = 'Désactiver';
		} ➋
		return view('test.informations', compact('nav', 'value')); ➌
	}
}

➊ Nous pouvons trouver dans ce contrôleur le tableau $nav à 5 valeurs que nous avons déjà traité avec la boucle foreach (cf. point section nav de la vue 'informations').

➋ Ici, nous abordons les requêtes. Dans la ligne 11 du code ci-dessus, on affecte à la variable $etat la valeur du GET obtenue en cliquant sur le bouton (submit) du formulaire (cf. section header de la vue 'informations'). On demande en effet à Laravel d'établir une requête et d'aller chercher la valeur du GET auquel on a attribué l'attribut name, c'est-à-dire le submit lui-même.

⚠ Pour que $request->[name_du_get] fonctionne, il est nécessaire d'appeler le fichier Request au sommet du contrôleur (use Illuminate\Http\Request;) ainsi qu'en paramètre de la méthode (Request $request, Request servant à instancier l'existant). Ensuite j'établis une condition : si la variable $etat vaut "Désactiver", j'affecte à une variable nommée $value la valeur "Activer" ; mais pour toute autre valeur, la chaîne de caractères "Désactiver" sera affectée à ma variable $value.

➌ Enfin, on retourne la vue informations qui se trouve dans le dossier test, tout en passant à cette vue les variables $nav (➊) et $value (➋), de sorte qu'elles puissent y être exploitées, ce qui a été fait !

Résultat

Les vues ci-dessous varient en fonction qu'on clique sur le bouton en dessous du titre. Si l'on clique sur "Activer" (parce que le site est désactivé), on l'active, et le bouton prend alors dynamiquement la valeur "Désactiver" pour opérer dans le sens inverse (cf. Contrôleur). Par ailleurs, la vue bonjour n'est visible qu'à condition que le site soit établi comme actif (cf. Vue informations, section content).

active.png desactive.png

Conclusion

Désormais, nous avons fait un tour presque complet de Blade. @if @elseif @else, @for, @forelse, @isset – pour ne citer que celles-là – sont d'autres fonctions exploitables que vous pourrez découvrir sur la documentation officielle de Laravel. Le présent article nous a permis de voir comment communiquer des variables du contrôleur à la vue, ce qui est un premier pas vers l'élaboration d'un site ou d'une application plus dynamique. Dans le prochain article, nous verrons la gestion des formulaires en POST, Artisan (l'interface en ligne de commande) et les interactions avec une base de données. See you soon :) !

- page 1 de 4