DEV Community: jean-smaug

Version Control Your WordPress Code Snippets

jean-smaug — Wed, 29 Jul 2026 00:00:00 +0000

If you use Code Snippets or WPCode, you’re probably editing your PHP functions directly in the admin panel. Click the snippet, make the change, save. Done.

It works. Until it doesn’t.

Someone edits a snippet and breaks something. You don’t know what changed. There’s no history. You either remember what it looked like before, or you don’t. There’s no git log, no diff, no blame.

How people try to solve this today

The current options aren’t great.

Option 1: WPCodeBox or Code Snippets Cloud These tools offer built-in versioning: you can see a history of changes and revert. It works, but it’s locked inside their platform. Your code history lives in their database, not in your repo, and it doesn’t integrate with your existing Git workflow.

Option 2: Keeping snippets in your theme’s functions.php This at least puts the code in a file you can version. But it ties snippets to your theme, means they disappear on theme switch, and turns functions.php into an unorganized dumping ground.

Option 3: A custom plugin Some agencies build a site-specific plugin to hold all their custom code. This is better: it’s version-controlled and theme-independent. But it requires setup for every project and doesn’t give you a clean way to sync between environments.

None of these feel like a real developer workflow.

The Loopress approach

Loopress treats your snippets as plain files in a Git repository. Pull them down from WordPress, edit them locally, push them back. Every change is a commit.

Setup

Install the Loopress CLI:


npm install -g @loopress/cli

Configure your project:


lps project config

It asks for a project name, an environment (production, staging, local, or a custom name), and your WordPress URL. By default it then opens your browser to authorize and creates an Application Password for you automatically, no copy-pasting a generated password. If that flow can’t complete, it falls back to asking for a WordPress username and an Application Password you generate yourself.

Pull your snippets


lps snippet pull

This creates a snippets/ directory with one .php file and one .json sidecar per snippet:

snippets/

  1-my-custom-function.php

  1-my-custom-function.json

  2-woocommerce-checkout-tweak.php

  2-woocommerce-checkout-tweak.json

  3-disable-gutenberg.php

  3-disable-gutenberg.json

Each .php file contains the raw snippet code. The .json sidecar stores the metadata (id, name, type, active status, tags) that Loopress uses to identify and update the snippet on WordPress.

Edit locally

Open any file in your editor. Make changes. The feedback loop is your local environment, not the WordPress admin panel.


git add snippets/2-woocommerce-checkout-tweak.php

git commit -m "fix: apply discount code before tax calculation"

Now you have a commit. A diff. A message explaining why. This is reviewable, reversible, and shareable.

Push back to WordPress


lps snippet push

Loopress syncs your local files back to WordPress via the REST API. No FTP, no copy-paste.

If you want to see what would change without actually changing anything:


lps snippet push --dry-run

Working across environments

The real value shows up when you’re working with local, staging, and production environments. Register each one once with lps project config, then target any of them with --env on a single command:

# Pull from production

lps snippet pull --env production

# Test locally, commit changes

# Push to staging first

lps snippet push --env staging

# When ready, push to production

lps snippet push --env production --yes

That trailing --yes isn’t optional flair: pushing to an environment literally named production asks for confirmation in a terminal, and requires --yes to skip that prompt outside one (CI, scripts). --env also takes priority over whatever lps project switch last left active globally, which matters the moment more than one person runs commands against the same project.

Your snippets flow between environments the same way your code does. No database exports, no manual copy-paste.

One thing to keep in mind

Loopress syncs snippets by ID (stored in the .json sidecar). If you pull first, the ID is saved and subsequent pushes update the correct snippet regardless of name changes. Without a sidecar ID, Loopress creates a new snippet. Treat the files as the source of truth once you’re in this workflow.

If this resonates, the next step is lps project config and adding snippets/ to your project’s Git repository. From there, every snippet change is a commit.

Ship a Custom WordPress Endpoint Without Writing a Plugin

jean-smaug — Mon, 27 Jul 2026 07:02:40 +0000

Your JavaScript frontend needs a list of featured products from WordPress. Not the whole REST API surface, not raw post objects with forty fields, just the ten items the homepage carousel shows, shaped the way the frontend wants them.

The endpoint is ten minutes of work: query, map, return. The question that eats the rest of the afternoon: where does that code go?

Where custom endpoints live today

functions.php. Fastest to write, tied to your theme. Switch themes, lose the endpoint. Two years later it's line 1400 of a file nobody wants to scroll.

A site-specific plugin. The clean classic answer. But now your ten minutes of logic come wrapped in a plugin header, a hook, and a registration array:

add_action('rest_api_init', function () {
    register_rest_route('acme/v1', '/featured-products', [
        'methods'             => 'GET',
        'callback'            => 'acme_featured_products',
        'permission_callback' => '__return_true',
    ]);
});

And you still need a way to get that plugin onto the site. And onto staging. And to know which version runs where.

A snippets plugin. Deployed in seconds, versioned never. The code lives in the database, edited through an admin textarea, invisible to Git and code review.

The endpoint logic is never the problem. The delivery vehicle is.

One file, one route

With Loopress Full installed, a custom endpoint is a single PHP file in your repo:

<?php

declare(strict_types=1);

class FeaturedProducts
{
    public function get(): array
    {
        $query = new WP_Query([
            'post_type'      => 'product',
            'meta_key'       => 'featured',
            'meta_value'     => '1',
            'posts_per_page' => 10,
        ]);

        return array_map(fn(WP_Post $post): array => [
            'id'    => $post->ID,
            'title' => $post->post_title,
            'url'   => get_permalink($post),
        ], $query->posts);
    }
}

Save it as api/featured-products.php and deploy:

lps api push

The conventions do all the wiring you saw above. The filename is the route. The class name is the filename in PascalCase. Each public method named after an HTTP verb (get, post, put, patch, delete) becomes that verb's handler. No registration code, no plugin header, no hook.

Now call it

curl https://your-site.com/wp-json/loopress-api/v1/featured-products

{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}

That 401 is the feature. A fresh route requires an administrator, the same authentication the Loopress CLI itself uses. Nothing you push is publicly reachable by accident.

For an endpoint another system calls on your behalf, a reporting script, an internal dashboard, a cron job, that default is already the right answer: the caller authenticates with an application password over Basic auth, and you have a protected endpoint without writing a single line of security code.

This feed, though, is meant for the browser. Making it public is a decision, so it's expressed where decisions belong, in the file, in the diff, in code review:

public function permission(): callable
{
    return fn(): bool => true;
}

curl https://your-site.com/wp-json/loopress-api/v1/featured-products

[{"id":231,"title":"Weekender Backpack","url":"https://your-site.com/product/weekender-backpack"}]

One greppable line. A reviewer seeing this diff knows exactly what's being opened to the world, which is not something you can say about a checkbox in an admin screen. The same permission() method takes any callable, so routes that need their own rules, logged-in users only, a capability check, a signed webhook, express them the same way (the docs cover those patterns).

The frontend lives on another domain? Declare CORS headers in the file too, they apply to every request, preflight included:

public function headers(): array
{
    return ['Access-Control-Allow-Origin' => 'https://app.example.com'];
}

Need an HTTP client or an SDK in a route? If the site uses Loopress's Composer integration, your packages are directly available to use in route files. No manual autoloader loading.

Built to not break your site

Deployed code that runs inside WordPress has one non-negotiable requirement: a mistake must stay contained.

lps api push syntax-checks every file server-side and rejects broken PHP with the actual parse error, before anything is written.
A file that still fails at runtime (a class collision with another plugin, a throwing dependency) is skipped and logged. Every other route, and the rest of the site's REST API, keeps working.
Files are protected from direct HTTP access and written atomically. Pull them back and you get exactly the source you wrote.

Endpoints your repository declares

Because routes are plain files, everything you already do with code applies:

lps api pull                  # mirror what's on the site locally
git checkout -b add-feed      # branch, edit, review
lps api push                  # deploy

Different environments? Push the same files to staging first, then production, like the rest of your Loopress-managed configuration. Endpoints stop being something you set up on a site and become something your repository declares.

Custom API Routes ship with Loopress Full, the free full edition of the plugin:

npm install -g @loopress/cli

The documentation covers the complete file reference: request handling, response types, authentication, CORS, namespaces, and the security model.

Installing Composer Packages in WordPress Without SSH

jean-smaug — Fri, 24 Jul 2026 10:59:17 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

You need to add a PHP dependency to a WordPress site. Maybe a PDF generation library, a CSV parser, an image manipulation package. Something available on Packagist.

Here's what the standard workflow looks like.

The current workflow

If you're on managed hosting (most clients are):

Check if SSH is available (often it isn't, or it requires upgrading the hosting plan)
If SSH is available: connect, check if Composer is installed, install it if not
Navigate to the WordPress root
Initialize composer.json if it doesn't exist
Run composer require vendor/package
Hope the server's PHP version matches your local environment
Hope the vendor/ directory ends up in the right place
Repeat for every site, every environment

This is assuming nothing goes wrong. In practice, you'll hit permission issues, PHP version mismatches, or a host that simply blocks Composer from running.

The workaround people actually use:

Run Composer locally, then upload the vendor/ directory to the server via FTP or rsync. This works but means you're manually syncing binary files, and the next developer who needs to add a dependency starts from scratch figuring out where everything lives.

Neither option is good.

What Loopress does differently

Loopress Full adds a Dependency Management panel to your WordPress admin. It talks to Packagist, runs Composer server-side through a sandboxed process, and handles the install without you needing a terminal or SSH access.

This is Loopress Full specifically, not Loopress Light (the free edition on wordpress.org). wordpress.org's plugin guidelines don't allow a plugin to install executable code from a third-party registry like Packagist, so this feature ships separately, from loopress.dev, rather than the official directory. Here's why, if you're curious.

Download Loopress Full

Installing a package

Here's what that looks like from the admin, in under a minute:

Your browser doesn't support HTML5 video. Download the video instead.

Navigate to WordPress Admin → Loopress → Dependencies.
Search for a package by name (guzzlehttp/guzzle, or whatever you need). Loopress queries Packagist directly and shows you available versions.
Select the version, click Install. Loopress runs composer require on the server and installs the package into a managed vendor/ directory inside the plugin's scope.

Using it in a snippet

Require the autoloader once, then use the package like any other Composer dependency. Here it is fetching and displaying data from an API in a code snippet:

Your browser doesn't support HTML5 video. Download the video instead.

require_once WP_CONTENT_DIR . '/loopress/vendor/autoload.php';

use GuzzleHttp\Client;

add_filter('the_content', function ($content) {
    if (!in_the_loop() || !is_main_query()) {
        return $content;
    }

    $client = new Client();
    $response = $client->get('https://jsonplaceholder.typicode.com/posts', ['query' => ['_limit' => 5]]);
    $posts = json_decode($response->getBody()->getContents(), true);

    $list = '<ul>';
    foreach ($posts as $post) {
        $list .= '<li style="color: red">' . esc_html($post['title']) . '</li>';
    }
    $list .= '</ul>';

    return $content . $list;
});

Why this matters for agencies

If you manage multiple client sites, the usual Composer workflow means either:

Maintaining SSH access to every server
Teaching clients how to run terminal commands (not happening)
Keeping a pile of FTP credentials and manually uploading vendor/ directories

With Loopress, the dependency management surface moves into the WordPress admin. You can install, update, and remove packages from the same interface you use to manage everything else. No server access required.

Seeing what's installed

The Dependencies panel shows:

All installed packages with their current versions
Available updates from Packagist
A one-click update path

This is the equivalent of composer show and composer outdated, surfaced in the UI.

What Loopress doesn't replace

Loopress's dependency management is designed for adding libraries to a running WordPress site, pulling in packages that your snippets or custom code need. It's not a replacement for a full Bedrock/Composer setup where WordPress itself is a Composer dependency.

If you're building on Roots/Bedrock, you already have a proper Composer workflow and probably don't need this. Loopress fills the gap for the other 90% of WordPress sites that aren't running a full stack framework: sites on shared hosting, client sites where the server environment is opaque, or projects where "set up Bedrock" isn't a conversation you can have.

Loopress Full is a free download, installed like any other plugin zip (Plugins → Add New → Upload Plugin), no server configuration required. If you only need snippet sync, Loopress Light is the free edition submitted to the wordpress.org directory instead.

Why wordpress.org Won't Let You Install Composer Packages From a Plugin

jean-smaug — Mon, 20 Jul 2026 06:55:14 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

WordPress doesn't have a package manager. If you want a PHP library in your project, be it Guzzle for HTTP calls or a PDF generation library in a snippet, you're either vendoring the code by hand or running Composer somewhere the WordPress admin can't see.

We built a feature to fix that: a Composer UI inside the WordPress admin. Search Packagist, install a package, audit it for known vulnerabilities, all without SSH access (full walkthrough here). Before shipping it, we asked the wordpress.org plugin review team whether it would be acceptable in the official directory.

The answer was no.

The rule

Here's the relevant line from Guideline 8 of the wordpress.org plugin directory:

"Plugins may not send executable code via third-party systems."

Installing a PHP package from Packagist is, by definition, downloading executable code from a third party and writing it to disk. It doesn't matter that our plugin never calls the installed code's autoloader itself, that the user has to load it deliberately from their own snippet. The review team was clear: the indirection changes nothing. The mere presence of that capability is enough to trigger the rule, whether or not it's ever used. There's no folder you can hide it in that makes it acceptable, they weren't shy about saying that outright.

If you want PHP dependencies in a plugin distributed on wordpress.org, the only accepted path is to vendor them at submission time: ship the code, with a compatible license and readable source, not fetch it dynamically.

For us, that meant Composer package management could never live in the same plugin that ships on wordpress.org. Full stop, no clever workaround changes that.

What we tried first, and undid

Our first move was the obvious one: split into two plugins. A "Core" plugin with snippet sync, distributed on wordpress.org, and a "Plus" plugin with Composer management, distributed separately, with the two detecting each other at runtime.

We built it. Two npm packages, two composer.json files, two QA configs, two release pipelines, a filter contract between them so Plus could register itself with Core. Tests passed on both. Then we looked at what we'd actually built and reverted the whole thing the same day.

The duplication cost more than the split saved us. Every config file, every CI job, every README existed twice for no product reason. Worse, one version of the idea we considered, Core dynamically loading Plus's code, would have reintroduced the exact pattern the review team had just told us was the problem. That one wasn't even a contender once we thought it through.

What we shipped instead

One codebase. Two build artifacts.

wordpress-plugin/
├── src/
│   ├── Module/, Service/, RestApi/    snippet sync, shared by both editions
│   └── Dependencies/                  all Composer code, this directory
│                                      is physically absent from the
│                                      wordpress.org build, not just inactive
├── frontend/
│   ├── full/    → App.tsx             Composer UI lives here
│   └── light/   → LightApp.tsx        never imports anything from Dependencies/
└── scripts/build-flavor.cjs           assembles each edition and zips it

pnpm pack:light produces Loopress Light: snippet sync only, no Composer code anywhere in the zip, not dead code, not a disabled feature flag, physically not present. composer.json in that build ships with an empty require. A CI step unzips the artifact after the build and greps it for Composer residue, because trusting the build script to get this right isn't good enough when the whole point is a compliance boundary.

pnpm pack:full produces Loopress Full: everything, including the package installer, the security audit, and CLI sync for your composer.json/composer.lock. It's distributed from our own site, never wordpress.org, and its plugin header sets an Update URI that stops wordpress.org from ever pushing an update over it by mistake. If Loopress Light is already active on a site, activating Loopress Full deactivates it. The two editions don't coexist. Full replaces Light, it doesn't sit next to it.

This is the same model ACF and Elementor use for their free/pro split: one codebase, one build script, two artifacts with a real feature boundary between them, not a paywall drawn in the UI.

The honest tradeoff

If you only need snippet sync, Loopress Light is a free wordpress.org install, same as any other plugin in the directory. If you want Composer packages managed from WordPress without SSH, that's Loopress Full (see how it works), a separate download from our site, precisely because wordpress.org's own rules don't allow that capability to live there. We'd rather tell you that upfront than have you discover it after installing the wrong one.

Thanks

Credit where it's due: the wordpress.org plugins review team answered our question directly and quickly, before we'd submitted anything. That single clear answer, citing the exact guideline, saved us from finding out the hard way through a full submission and rejection cycle. Loopress Light is in review now, built around that answer from the start.

WordPress Has a DX Problem, and Developers Are Paying for It

jean-smaug — Wed, 15 Jul 2026 17:34:49 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

WordPress is remarkable. It powers well over 40% of all websites, according to W3Techs. Your clients love it. Their non-technical staff can update content without calling you. The plugin ecosystem is enormous.

But if you're a developer, the moment you sit down to build with WordPress, something feels off.

You're editing files directly on the server. You're copy-pasting snippets from the admin panel. You're hoping you remember what you changed last week. You're sending a colleague a zip file with the "latest version" of some PHP function.

None of this is how modern software is built. And yet, it's the default WordPress workflow. This is the gap Loopress exists to close, and it's worth understanding exactly where the friction comes from before looking at how to fix it.

What is developer experience?

Developer experience (DX) refers to how smooth (or painful) it is to work with a tool as a developer. Good DX means: fast feedback loops, predictable environments, version-controlled code, and reproducible deployments.

Think of how you work with a modern JavaScript project:

Code lives in Git
Dependencies are declared in package.json and locked in package-lock.json
You run npm install and the project works
Staging and production match because the environment is defined in code

Now think about a typical WordPress project:

Snippets are stored in a database, edited through a UI
PHP packages require SSH access to install
"Deploying" means FTP or a database export
Staging and production drift apart over time because changes happen manually in both

This isn't a criticism of WordPress as a product; it was built for a different audience. But developers using it to build things deserve better.

What can go wrong

Here's a real scenario: you add a PHP snippet to your WordPress site using the Code Snippets plugin. It works. Three months later, a junior dev edits it and introduces a bug that takes checkout down for an hour. You have no idea what changed, when, or why. There's no diff, no history, no rollback button. You dig through admin logs hoping to find something, then end up rewriting the snippet from memory.

Or: a client wants a PDF export feature. You need to pull in a Packagist package. You SSH into the server, install Composer, run composer require, and pray nothing breaks in production. It worked, but it was thirty minutes of friction that shouldn't exist.

These aren't edge cases. They're the everyday reality of WordPress development.

What a better workflow looks like

Imagine instead:

# Pull your snippets down as files
lps snippet pull

# Edit them locally, in your editor, with Git tracking changes
git add snippets/my-function.php
git commit -m "fix: correct tax calculation logic"

# Push back to WordPress
lps snippet push

Your snippet is now version-controlled. You have a diff. You can roll back. You can review the change in a PR. This is how software is supposed to work, and it's exactly what Loopress brings to WordPress: a CLI that treats your snippets and Composer dependencies as files, plus a plugin that lets you manage PHP dependencies from the admin panel without server access.

WordPress stays WordPress. Your clients can still use it the way they love. You just work with it like a developer.

What's next

The rest of this blog will cover specific workflows in detail: version-controlling Code Snippets with Git, installing Composer packages without SSH, syncing menus and styles between environments, and managing multiple client sites as code. Those posts are coming soon; this one lays the groundwork for why they matter.

Why I Built Loopress

jean-smaug — Sat, 04 Jul 2026 14:11:46 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

I'm a frontend developer who's spent the last few years working in environments where everything is versioned, deployments are automated, and "it works on my machine" isn't an acceptable answer.

One of the jobs that shaped how I think about this was Bedrock Streaming, a streaming platform where every developer owned their infrastructure, frontend included, and the tool we used was Terraform. I remember something clicking when I started using it: your infra is just a file, which means it gets versioned, reviewed, and rolled back like any other piece of code. That idea stuck with me well past that job.

A site for my sister

My sister runs an online French tutoring business (nativefrenchteacher.com). She's not technical, and she needed to manage her own content without calling me every time. WordPress made sense.

And honestly, it worked great for her. Whatever I needed (bookings, SEO, forms, caching) there was a plugin. The ecosystem is massive.

Building with it as a developer was another thing entirely.

I used the Code Snippets plugin constantly. And every time I touched a snippet, the same thought: if something breaks, I have no history. No diff. Just hope it doesn't break.

The real moment was when I needed to manipulate PDFs and wanted to pull in a Packagist package. So I SSH'd into the server, installed Composer manually, ran the install, crossed my fingers. It worked. But it felt wrong. This is a solved problem everywhere else.

The gap

I came from a world where code lives in Git and environments are reproducible. WordPress assumes you click things in the admin, upload files via FTP, and remember what you changed. Production is always slightly different from local.

That's not a knock on WordPress. It's built for a different audience. But the developer building on top of it is left to figure things out alone.

What I built

I started building Loopress: a CLI to version-control code snippets in Git and sync them to any WordPress instance, and a plugin that brings Composer dependency management into the admin panel, no SSH needed.

The goal was to bring the same idea I took away from Terraform into WordPress: your snippets, your dependencies, your configuration, all of it living in a repo, reviewable, deployable, not scattered across admin panels and SSH sessions you'll never remember.

Still building. If any of this sounds familiar, I built it for you.

How to fix the 'Received "true" for a non-boolean attribute' error

jean-smaug — Mon, 23 Nov 2020 21:09:16 +0000

If you use styled-components, you maybe encountered the following error.

Warning: Received "true" for a non-boolean attribute

There is an official solution that you can find here. I'll present an alternative to this solution.

The trick is to use the unary plus operator to convert boolean to number.

// Convert boolean to numbers
+true; // 1
+false; // 0

// Conditions are still valid using 0 and 1
0 ? "jean" : "smaug"; // smaug
1 ? "jean" : "smaug"; // jean

In order to make a real world example, we'll style the Link component from react-router.

import styled from "styled-components";
import { Link } from "react-router";

const StyledLink = styled(Link)`
  color: ${({ inverted }) => (inverted ? "white" : "chartreuse")};
`;

function Navbar() {
  return (
    <nav>
      {# Bad #}
      <StyledLink inverted={true}>Home</StyledLink>

      {# Good #}
      <StyledLink inverted={+true}>About</StyledLink>
    </nav>
  );
}

Fixing this error is very simple. You just need to add + before your booleans values. According to MDN unary operator is the preferred way for number conversion.

You can find the banner image here.

Thanks for reading.

File upload in Javascript using fetch

jean-smaug — Mon, 26 Oct 2020 07:17:26 +0000

In this article we'll see how to upload a file using the fetch API. We'll take a PHP example and update it, in order to improve user experience.

The code is available here

jean-smaug / demo-file-upload

📖 This is a translation from this article. So there is some French in code in order to keep consistency with demonstrations GIFs

Upload in PHP

Let's take the following example :

After the form submission, we see that the URL is changing to upload.php. This page store the uploaded file and display a success message. Finally the user is redirected to the first page. The example work but it require three pages loads.

Let's see the code.

<!DOCTYPE html>
<html>
  <head>
    <!-- ... -->
  </head>
  <body>
    <form action="upload.php" method="post" enctype="multipart/form-data">
      <input type="file" name="background" />
      <button type="submit">Envoyer</button>
    </form>
  </body>
</html>

The HTML code is very common. We only have to pay attention to the enctype attribute. The value must be multipart/form-data in order to do a file upload.

<?php
    header("Access-Control-Allow-Origin: *");

    /* The superglobal variable $_FILES gives us the ability to access
    all files that were uploaded using an HTML form. The background key
    makes reference to the value of the name attribute in
    <input name="background" /> */
    $file = $_FILES["background"];
    $isFileUploaded = move_uploaded_file($file["tmp_name"], __DIR__ . "/../storage/" . $file["name"]);

    if($isFileUploaded === false) {
        http_response_code(500);
        echo "Problème serveur";
    }
    else {
        http_response_code(201);
        readfile('success.html');
    }

    // Redirection on index.html after 2 seconds
    header("Refresh:2; url=index.html", true, 303);

The server side retrieve the file and move it into the storage folder. When processing is over, we display a success message and we redirect him to the index.html page after two secondes. The main point is that the name given to the input element is important, because it's this name that the server is using to retrieve the file.

Web APIs

We'll need two web API to perform the Upload in Javascript : FormData and Fetch.

FormData

FormData is well supported by browsers.

This API gives us the ability to represent a form in Javscript. This form will have a multipart/form-data encoding, so it's not necessary to precise it in the HTML. As already mentioned, this encoding is necessary when you're uploading a file.

Fetch

Surprisingly, we have compatibilities problems with Internet Explorer.
There are two solution to avoid this :

Use a polyfill
The trick I'm will use later in the article

The fetch API is the modern way to perform HTTP requests. It's based on promise. There are various syntaxes for using promises, here we'll use the
On peut utiliser les promesses avec plusieurs syntaxe, ici on utilisera async/await.

/* The async keyword means that the await keyword
will be used inside the function. */
async function getLucky() {
  /* The await keyword means that we're wating the results of a
   function, here somethingThatTakesTime. We don't know when the
   function will return a value, so we're awaiting the end of the
   process before executing next instructions. */
  const luck = await somethingThatTakesTime()

  return luck
}

I explained it in a short way, because it's not the main subjects. You'll be able able to easily find articles that are talking about promises and async/await.

In Javascript

<!DOCTYPE html>
<html>
  <head>
    <!-- ... -->
  </head>
  <body>
    <form id="form">
      <input type="file" name="background" />
      <button type="submit">Envoyer</button>
    </form>
    <p id="message"></p>
    <script src="./app.js"></script>
  </body>
</html>

The HTML part is mainly the same. Previous form's attributes have been replaced by an id. And we're adding a paragraph where we'll display the success or failure message. And finally we load our script.

/* We get form and message elements */
const form = document.getElementById("form")
const message = document.getElementById("message")

/* We're listing for the form submission and
we're preventing the default behaviour */
form.addEventListener("submit", async function (e) {
  e.preventDefault()

  /* If your not using a polyfill for fetch, the trick for IE is to
  suggest the user to use an other browser. */
  if (!window.fetch || !window.FormData) {
    alert("R u fucking kidding me ??? Use another browser right now !")
    return
  }

  /* When we're instanciating FormData, we can pass it a form element.
  FormData will be able to detect all inputs of the form and their
  values. */
  const formData = new FormData(form)

  try {
    /* fetch() is taking two parameters, the first is URL and
    the second are options. Here we're telling fetch that we'll
    make a POST request and the body of the request, the data
    we're sending will be our formData */
    await fetch("http://localhost:4000/upload.php", {
      method: "POST",
      body: formData,
    })

    // We display a success or failure message.
    message.innerText = "Fichier uploadé avec succès \\o/"
  } catch (error) {
    message.innerText = "Il y a eu un problème /o\\"
  }

  // We clean the form
  form.reset()

  // We're removing the message after two seconds
  setTimeout(() => {
    message.innerText = ""
  }, 2000)
})

With this code, we get this result.

The last step is server optimization. You can remove these lines.

<?php
    header("Access-Control-Allow-Origin: *");

    $file = $_FILES["background"];
    $isFileUploaded = move_uploaded_file($file["tmp_name"], __DIR__ . "/../storage/" . $file["name"]);

    if($isFileUploaded === false) {
        http_response_code(500);
-       echo "Server issue";
    }
    else {
        http_response_code(201);
-       readfile('success.html');
    }
-
-   header("Refresh:2; url=index.html", true, 303);

Conclusion

Combination of FormData and fetch APIs are making file upload really easy. We're avoiding pages reload in order to improve user experience.

To perform HTTP requests, it's possible, like in this post, to use fetch. But you should consider :

Axios, XMLHttpRequest based library. XMLHttpRequest is the old way to perform HTTP request, so it's compatible with IE.
Ky, a wrapper for fetch which add some features. Ky compared to axios by Ky's creator.

Finally, it's possible to use these principles with libraries such as React or Vue.js. You'll just have to use references in order to access form element.

Thanks for reading.

An issue with a lib? Create yours!

jean-smaug — Tue, 06 Oct 2020 19:39:48 +0000

I'm working on a Node.js project that is using Koa. I wanted to use Twig as template engine in order to render views. I encountered some issues, and I want to relate how I dealt with.

Many libs and one problem

The usual way to render HTML with Koa is by using koa-views, which is using consolidate under the hood. consolidate require to add and configure manually the template engine we want to use.
There are many libs that are dependent (koa-views → consolidate → twig). This is not bad, but this requires each lib to communicate correctly with others.

I encountered a problem when I wanted to include or extend other twig files. Let's take the following code as example.

{# template.twig #}

<!DOCTYPE html>
<html lang="en">
  <head>...</head>
  <body>
    <main>{% block main %}{% endblock %}</main>
  </body>
</html>

{# home.twig #}

{% extends "template.html" %}

{% block main %}
<div>Home</div>
{% endblock %}

This code leads to the following error. Even if add some specific configuration as explained in this issue.

Error parsing twig template undefined: 
TwigException: Cannot extend an inline template.

By reading issues, it looked like there was some interferences between these libs, so I decided to reduce their numbers and make the link between Koa and Twig by myself.

The koa-twig lib

The goal of koa-twig is to enhance the Koa Context with a render function. It's heavily inspired of koa-views.

I'll present to you the first version of the code. I improved it, and I'm still improving it in order to offer the same feature as the others template engines bindings for Koa (koa-ejs, koa-hbs...).

const twig = require("twig");
const util = require("util");

// Use Promise instead of callback syntax.
const renderFile = util.promisify(twig.renderFile);

/**
 * Give the ability to use Twig template engine in Koa
 * @param {object} config
 * @param {string} config.views - the views folder path
 * @param {object} config.data - the data to pass to each view
 * @param {object} config.extension - the data to pass to each view
 */
const twigMiddleware = (config) => async (ctx, next) => {
  function render(file, data) {
    return renderFile(`${config.views}/${file}.${config.extension || "twig"}`, {
      ...config.data,
      ...data,
    });
  }

  /* `render` function will be accessible
  on ctx and on ctx.response */
  ctx.response.render = render;
  ctx.render = render;

  await next();
};

module.exports = twigMiddleware;

Here a basic use case.

const Koa = require("koa");
const koaTwig = require("koa-twig");

const app = new Koa();

// Configuration of the middleware
app.use(
  koaTwig({
    views: `${__dirname}/views`
  })
);

app.use(async (ctx) => {
  // Calling `render` will render `./views/home.twig`
  ctx.body = await ctx.render("home");
});

app.listen(8080);

So it wasn't that hard to reach a quick win. I can now develop with less intermediate. This is also something that made me remember that you don't need a lib for all of your problems!

Bonus

All the PRs I made for this little lib counted for the Hacktoberfest 🎉

Another reason to create and share what you're doing !

Conclusion

If there is an obstacle on the road and you can't go to right, try the left. If it's closed, try to go up. If it's blocked, dig under! Don't wait for someone to clean the road for you.

I still have some work to do in order to have the same features as the others Koa template engines bindings, but it's a first step I'm satisfied of!

The short version : DIY and KISS.

Thanks for reading.

Créer un bot Telegram avec Elixir

jean-smaug — Mon, 04 May 2020 10:48:17 +0000

En ces périodes de confinement, il est important de continuer de générer du lead. C'est pour cela que nous allons voir comment créer un bot Telegram pour ~~nous assister dans nos taches du quotidien~~ ne rien faire de productif.

Les sources sont disponibles ici.

jean-smaug / demo-elixir-telegram-bot

Initialisation

Côté Telegram

On commence par s'adresser au daron de tous les bots, j'ai nommé @botfather. On lui demande de créer un nouveau bot avec la commande /newbot, puis en répondant aux questions.

Une fois que le bot est créé, botfather nous affiche un token. Nous nous en servirons par la suite.

Côté code

On initialise un projet Elixir avec la commande suivante.

mix new macron_bot --sup

Nous allons utiliser la librairie ex_gram. Cette librairie est une couche d'abstraction autour des API Telegram.

Il faut ajouter cette dépendance ainsi que d'autres qui sont requises pour son bon fonctionnement.

# mix.exs

defmodule MacronBot.MixProject do
  # ...

  defp deps do
    [
      {:ex_gram, "~> 0.12"},
      {:tesla, "~> 1.2"},
      {:hackney, "~> 1.12"},
      {:jason, ">= 1.0.0"}
    ]
  end
end

On installe les dépendances.

mix deps.get

Nous allons ensuite créer un fichier de configuration. (Qui n'est plus généré automatiquement depuis la version 1.9.0 d'Elixir).

mkdir config && touch config/config.exs

Dans le fichier créer il faut ajouter les lignes suivantes en remplaçant le token par celui fourni par Botfather.

# config/config.exs

use Mix.Config

config :tesla, adapter: Tesla.Adapter.Hackney

# Remplacez ce token avec celui fourni par Botfather
config :ex_gram,
  token: "1287038449:AAHvSU4cGipZUH6i2Pbbhiz9akkE7_wP4YQ",
  adapter: ExGram.Adapter.Tesla,
  json_engine: Jason

Enfin on configure le module application.

# lib/macron_bot/application.ex

defmodule MacronBot.Application do
  use Application

  def start(_type, _args) do
    # Importe le token depuis la config
    token = ExGram.Config.get(:ex_gram, :token)

    children = [
      ExGram,
      # Lance le module MacronBot
      {MacronBot, [method: :polling, token: token]}
    ]

    # Si l'application rencontre un problème elle sera redémarrée
    opts = [strategy: :one_for_one, name: MacronBot.Supervisor]
    Supervisor.start_link(children, opts)
  end
end

L'initialisation peut sembler longue, mais par la suite, on modifie très peu ces fichiers.

Création du bot

Afin d'explorer les possibilités techniques qui sont à notre disposition notre bot aura les fonctionnalités suivantes :

Une commande slash /parle qui affichera une citation au hasard (une commande slash est un "message qui commence par le signe /").
Lorsqu'on lui pose une question le bot affichera des boutons pour permettre à l'utilisateur de répondre

# lib/macron_bot.ex

defmodule MacronBot do
  @bot :Macron_Bot

  # Si on raisonne en Orienté Objet, on peut voir
  # le use comme "un héritage".
  # Le name serait un paramètre que l'on passe
  # au constructeur parent.
  use ExGram.Bot,
    name: @bot

  # Requis si vous ajoutez votre bot à un groupe
  middleware(ExGram.Middleware.IgnoreUsername)

  # Comme nous utilisons le module ExGram.Bot,
  # il est nécessaire d'implémenter une fonction
  # nommée handle pour que le bot puisse fonctionner.
  #
  # Le premier paramètre est un tuple dont les valeurs
  # changent suivant les cas.
  #
  # Le second paramètre est le context,
  # il contient des informations sur le message reçu
  def handle(_, context) do

    # La fonction answer nous permet d'envoyer un message
    # Telgram en tant que bot
    answer(context, "J'appelle à la responsabilité")
  end
end

Désormais on peut lancer le bot avec la commande.

iex -S mix

Le bot répondera "J'appelle à la responsabilité" à chacun de nos messages.

Les commandes slash

La commande slash parle affichera au hasard, des citations que j'ai piquée, sans vergogne, sur le site du Parisien.

J'ai selectionné les phrases les plus croquignolesques mais bien sûr, adaptez selon vos envies.

# lib/macron_bot.ex

defmodule MacronBot do
  # Si l'on veut detecter une commande, le tuple
  # contiendra un atom :command à l'index 0.
  # Le nom de la commande à l'index 1.
  # Et le "message" à l'index 2,
  # c'est a dire le texte suivant la commande.
  def handle({:command, "parle", _msg}, context) do
    answers = [
      "Si j'étais chômeur, je n'attendrais pas tout de l'autre, j'essaierais de me battre d'abord.",
      "Je suis maoïste, [...] un bon programme c'est ce qui marche.",
      "Le libéralisme est une valeur de gauche.",
      "Il y a dans cette société une majorité de femmes. Il y en a qui sont, pour beaucoup, illettrées.",
      "Les Tontons Flingueurs, c'est un de mes films préférés. \"On n'est pas venus pour beurrer les sandwichs\" : ma réplique préférée.",
      "Make our planet great again !",
      "Vous n'allez pas me faire peur avec votre t-shirt, la meilleure façon de se payer un costard c'est de travailler.",
      "Je ne vais pas interdire Uber et les VTC, ce serait les renvoyer vendre de la drogue à Stains.",
      "Vu la situation économique, ne plus payer les heures supplémentaires c'est une nécessité.",
      "La tranche d'impôt de Hollande à 75 % ? C'est Cuba sans le soleil.",
      "Quand des pays ont encore sept à huit enfants par femmes, vous pouvez décider d'y dépenser des milliards d'euros, vous ne stabiliserez rien.",
      "Le kwassa-kwassa pêche peu. Il amène du Comorien.",
      "Lorsque la politique n'est plus une mission mais une profession, les politiciens deviennent plus égoïstes que les fonctionnaires.",
      "Ne laissez pas la critique de l'UE à ceux qui le détestent.",
      "L'audiovisuel public est la honte de la République.",
      "La politique sociale, regardez : on met un pognon de dingue dans des minimas sociaux, les gens sont quand même pauvres.",
      "Chaque pays a sa propre diplomatie. Faire partie de l'Europe ne signifie pas renoncer à son indépendance ou ne plus pouvoir prendre l'initiative.",
      "Je me bats sur le plan international pour qu'on arrive à faire baisser le prix du pétrole.",
      "Parce que c'est notre PROJEEEEET !!!"
    ]

    # On répond avec une phrase au hasard
    random_answer = answers |> Enum.random()

    answer(context, random_answer)
  end
end

Après avoir créé cette fonction, il faudra, au choix :

Couper le terminal et relancer iex -S mix
Taper recompile dans le terminal interactif précédemment ouvert

Question-réponse

Le mécanisme de question-réponse permet d'aborder plusieurs notions :

La détection de la question, détecter que la phrase se termine par un ?. On utilisera une REGEX.
Envoyer un message contenant des boutons
Détecter sur quel bouton l'utilisateur à cliqué

Pour parvenir à ce comportement, notre code implémentera deux nouvelles méthode handle.

# lib/macron_bot.ex

defmodule MacronBot do
  # ...

  # On alias les models nécessaire pour construire
  # des messages contenant des boutons.
  alias Exgram.Model.{InlineKeyboardMarkup, InlineKeyboardButton}

  # Appelé lorsque l'on envoit un message textuel.
  def handle({:text, text, msg}, context) do

    # On teste si la phrase se termine
    # par un point d'interrogation.
    if String.match?(text, ~r/\?$/) do

      # On supprime le message que l'on vient d'envoyer.
      # Dans la pratique cela est optionnel,
      # mais on découvre une autre fonctionnalité 👍
      ExGram.delete_message(msg.chat.id, msg.message_id)

      # La fonction answer peut prendre un troisième paramètre
      # permettant d'enrichir le message. Des boutons ici.
      answer(context, text,
        reply_markup: %InlineKeyboardMarkup{
          inline_keyboard: [
            [
              %InlineKeyboardButton{
                text: "Oui",
                callback_data: "Oui"
              }
            ],
            [
              %InlineKeyboardButton{
                text: "Non",
                callback_data: "Non"
              }
            ]
          ]
        }
      )
    end
  end


  # Appelé lorsque l'on clique sur le bouton
  def handle({:callback_query, callback_query}, context) do
    # La valeur que l'on récupère via callback_query.data
    # est celle défini dans les callback_data ci-dessus
    answer(context, "#{callback_query.data}, mais en même temps")
  end
end

Bonus

Je vous donne le code pour créer une commande slash /covid. C'est cadeau, c'est pour moi. Emballé, c'est pesé !

# lib/macron_bot.ex

defmodule Macron do
  # ...

  def handle({:command, "covid", _msg}, context) do
    {:ok, covid_summary} = Tesla.get("https://api.covid19api.com/summary")

    json = covid_summary.body |> Jason.decode!()
    global = json |> Map.get("Global")

    france =
      json
      |> Map.get("Countries")
      |> Enum.find(fn country -> country["Slug"] == "france" end)

    covid_answer = ~s"""
    🌍
    Nouveaux cas : #{global["NewConfirmed"]}
    Nouvelles morts : #{global["NewDeaths"]}
    Cas totaux : #{global["TotalConfirmed"]}
    Morts totales : #{global["TotalDeaths"]}

    🇫🇷
    Nouveaux cas : #{france["NewConfirmed"]}
    Nouvelles morts : #{france["NewDeaths"]}
    Cas totaux : #{france["TotalConfirmed"]}
    Morts totales : #{france["TotalDeaths"]}
    """

    answer(context, covid_answer)
  end
end

Conclusion

A travers cet article j'espère avoir pu vous éclairer sur le fonctionnement de la librairie ex_gram. A titre personnel j'ai eu quelques difficultés a mettre en place certaines fonctionnalités, les réponses aux boutons par exemple. La documentation manque d'exemples à mon goût.

Néanmoins, la librairie reste bien conçue et une fois que l'on a compris la philosophie, on peut développer un bot très rapidement.

Je vous invite aussi à consulter la documentation Telegram afin de mieux comprendre d'ou viennent les structures utilisées.

Merci de m'avoir lu.

Liens

Le hoisting au service des composants React

jean-smaug — Fri, 03 Apr 2020 15:03:48 +0000

À première vue, le titre est un peu barbare. Pas d'inquiétude, nous allons commencer par découvrir ce qu'est le hoisting et dans un deuxième temps nous verrons quel peut être son intérêt pour les composants React.

Hissez haut ! Santiano 🎵

Pour découvrir le hoisting, ou "hissage" en français, nous allons partir du code suivant.

print("Il s'agirait de grandir")

function print(log) {
  console.log(log)
}

// Ce code affiche : "Il s'agirait de grandir"

Même si la fonction print est déclarée après avoir été appelée ce code fonctionne.

Cela vient du fait que Javascript va "remonter" les déclarations de fonctions en haut du code. Dans la réalité, le code reste à sa place, mais est stocké en mémoire afin de pouvoir être appelé partout.

Explication issue de la MDN.

Conceptuellement, par exemple, une définition stricte du hissage suggère que les déclarations de variables et de fonctions sont déplacées physiquement en haut de votre code, mais ce n'est pas ce qui se passe en fait. A la place, les déclarations de variables et de fonctions sont mises en mémoire pendant la phase de compilation, mais restent exactement là où vous les avez tapées dans votre code.

Transformons le code précédent en utilisant une fonction fléchée.

print("Il s'agirait de grandir")

const print = (log) => {
  console.log(log)
}

// Ce code affiche : "Uncaught ReferenceError: Cannot access 'print' before initialization"

Avec const et let la remonté a lieu mais pas l'initialisation. En d'autres termes appeler print ne générera pas une erreur du type print is not defined. En revanche, print n'a pas été initialisé, donc il correspond à rien.

Au sein de React

Je me suis longtemps demandé quelle syntaxe privilégier pour les composants fonctionnels.

const Button = ({ value, onClick }) => {
  return <button onClick={onClick}>{value}</button>
}

// ou

function Button({ value, onClick }) {
  return <button onClick={onClick}>{value}</button>
}

Étant donné que l'on a parlé du hoisting juste avant, vous vous doutez que la seconde forme a un avantage sur la première.
On peut trouver un intérêt dans la déclaration des propTypes et des defaultProps.

Avec une fonction fléchée.

import React from "react"
import PropTypes from "prop-types"

const Button = ({ value, onClick }) => {
  return <button onClick={onClick}>{value}</button>
}

// Nécéssairement en dessous du composant

Button.propTypes = {
  value: PropTypes.string,
  onClick: PropTypes.func.isRequired,
}

Button.defaultProps = {
  value: "",
}

export default Button

Avec une fonction "normale".

import React from "react"
import PropTypes from "prop-types"

// Peut être déplacé au dessus du composant

Button.propTypes = {
  value: PropTypes.string,
  onClick: PropTypes.func.isRequired,
}

Button.defaultProps = {
  value: "",
}

function Button({ value, onClick }) {
  return <button onClick={onClick}>{value}</button>
}

export default Button

Les fonctions nous laissent le choix et nous permettent ainsi de réorganiser notre code en plaçant la signature du composant au début du fichier.

Conclusion

Il y a une chose à ne pas oublier lorsque l'on utilise React : "C'est juste du JS". Tous les concepts que l'on connait sont valides et tous ceux que l'on découvrira le seront.

Grace au hoisting on peut arranger notre code de façon à avoir directement accès à la signature de notre composant. Cela évite de devoir scroller en bas de fichier pour savoir quelles sont les props que l'on peut utiliser.

Une question demeure : faut-il utiliser cette astuce ?

Faites en fonction de vos préférences.

Personnellement je l'utilise mais ce n'est en rien une règle absolue.

Merci de m'avoir lu.

Liens

The git remaster command

jean-smaug — Wed, 18 Mar 2020 16:09:24 +0000

OK, OK. This command doesn't exist. It's one of the aliases that I'm using.

TL;DR

Execute this command once only.

git config --global alias.remaster '!git fetch && git clean -d -f && git reset --hard origin/master'

When you totally fucked up your local repository and you want an atomic cleaning, use this one.

git remaster

Your current branch will be in the same state as the remote master (the one which is on Gitlab, Github...)

The long version

I'm writing this article because I saw this tweet from Emma Bostian. I was doing the same until I've found a solution. Btw, you should follow her.

// Detect dark theme var iframe = document.getElementById('tweet-1232412585397571584-484'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1232412585397571584&theme=dark" }

In this part I will explain in detail the meaning of this command.

git config --global alias.remaster '!git fetch && git clean -d -f && git reset --hard origin/master'

I will explain first how to configure alias (this part git config --global alias.remaster) and secondary the meaning of the created alias (the part between quotes).

The alias

Alias is just "a shorter name for something that is normally long to write". For example in maths you're using the = sign instead of writing is equal to.

The first part of the command is git config --global alias.remaster '...'. It tells Git : "Dear Git, please create an alias named remaster in the global config. After that, everytime I type git remaster I want the command between quotes to be executed." Learn more about git configuration (it's in french 🥖🍷🇫🇷).

The commands

Let's now focus on the commands between quotes

I will use the following schema to explain what's happening.

remote repository : the git repo which is on Gitlab, Github...
local repository : the git repo which is on your machine, containing your branches, your commits... Everything that has a meaning for git
working directory : where you work, basically, it's the files and directory that you're seeing
staging area : where your modifications go when you do a git add

Before presenting the underlying effects, do you know what is origin/master ? It's a branch ! It's a copy of the remote master branch. It's updated if there are new commits appearing when you do a git fetch or a git pull. This means that the origin/master branch is safe and that we can trust it.

That's why my sensei is saying that you can delete your master branch because you already have origin/master which is the "always clean master".

Antoine Caron

Jul 25 '19

Git TIP - Why you should not keep a local master branch ?

#git #learn #beginners #tip

1 min read

git fetch we update origin/master, the copy of the remote master branch
git clean -f -d : it removes untracked files. In other terms it removes files that have never been added to the staging area
git reset --hard origin/master we want, our files (the working copy) to be in the same state as the origin/master branch

There's one thing that could remain strange : the ! at the beginning.
The ! is necessary because I'm aliasing a bash command. It's not required if you want to alias a git command. For example you can write git config alias.co = checkout without !. More informations here

One small thing

If your main branch isn't master but develop, for example.

You can use.

git config --global alias.nuke '!git fetch && git clean -d -f && git reset --hard origin/develop'

The two parts that can change are the ALIAS_NAME and the MAIN_BRANCH.

git config --global alias.ALIAS_NAME '!git fetch && git clean -d -f && git reset --hard origin/MAIN_BRANCH'

It's maybe trivial but I prefere to point it out. 😉

Conclusion

The git remaster command is just an alias. It brings all the modifications from the remote repository into your local repository.
After that, you need to bring these modifications into your working directory.

You can run this command everytime you screw a branch and you want to get back to a clean state.

Don't forget, time is too precious to reclone a repo. Hope it will be useful.

Thanks to Marvin and Émilie who've helped me with the english translation.

Thanks for reading.

DEV Community: jean-smaug

Version Control Your WordPress Code Snippets

How people try to solve this today

The Loopress approach

Setup

Pull your snippets

Edit locally

Push back to WordPress

Working across environments

One thing to keep in mind

Ship a Custom WordPress Endpoint Without Writing a Plugin

Where custom endpoints live today

One file, one route

Now call it

Built to not break your site

Endpoints your repository declares

Installing Composer Packages in WordPress Without SSH

The current workflow

What Loopress does differently

Installing a package

Using it in a snippet

Why this matters for agencies

Seeing what's installed

What Loopress doesn't replace

Why wordpress.org Won't Let You Install Composer Packages From a Plugin

The rule

What we tried first, and undid

What we shipped instead

The honest tradeoff

Thanks

WordPress Has a DX Problem, and Developers Are Paying for It

What is developer experience?

What can go wrong

What a better workflow looks like

What's next

Why I Built Loopress

A site for my sister

The gap

What I built

How to fix the 'Received "true" for a non-boolean attribute' error

File upload in Javascript using fetch

jean-smaug / demo-file-upload

Upload in PHP

Web APIs

FormData

Fetch

In Javascript

Conclusion

Links

An issue with a lib? Create yours!

Many libs and one problem

The koa-twig lib

Bonus

Conclusion

Links

Créer un bot Telegram avec Elixir

jean-smaug / demo-elixir-telegram-bot

Initialisation

Côté Telegram

Côté code

Création du bot

Les commandes slash

Question-réponse

Bonus

Conclusion

Liens

Le hoisting au service des composants React

Hissez haut ! Santiano 🎵

Au sein de React

Conclusion

Liens

The git remaster command

TL;DR

The long version

The alias

The commands

Git TIP - Why you should not keep a local master branch ?

One small thing

Conclusion

Links