DEV Community: Daniel Mabadeje

What a Failing Test Suite Taught Me About a Silent Laravel Security Gap

Daniel Mabadeje — Tue, 28 Jul 2026 12:28:08 +0000

This is more like a heads-up article and a little mortification that I didn't realize this quickly…
Just a little… 😂

I recently spent an evening working through a batch of failing tests in a Laravel API. The failures looked unrelated on the surface. One endpoint was throwing a cryptic cURL error, another was silently accepting data it should have rejected, and a third was returning the wrong HTTP status code entirely. First of all, that was weird… It's an anti-pattern to test a third-party endpoint. So… why is my test calling an endpoint when I have set mocks???

Different endpoints, different symptoms. Same one-line root cause, every single time.

The bug, in its natural habitat
Here’s a simplified version of what I kept finding:

class VerificationController extends Controller
{
    public function verifyBvn(Request $request)
    {
        return $this->verificationService->verify($request);
    }
}

Nothing here looks wrong. It compiles. It runs. In the happy path, where the client sends well-formed data, it works exactly as expected.

The problem only shows up when someone sends bad data, a BVN that’s 3 characters instead of 11, an amount that’s negative, or a required field that’s just missing. Because nothing in this controller ever validates the input, that bad data doesn’t stop here. It flows straight into the service layer:

public function verify(Request $request)
{
    return $this->bvnProvider
        ->startVerification($request->bvn); // whatever the client sent, unchecked
}

And straight out to wherever that service layer talks to next. In my case, a real external API call, which then failed with a Guzzle exception that had nothing obviously to do with “the BVN was too short.” A validation problem disguised itself as an infrastructure problem, several layers downstream from where it should have been caught.

The fix looks almost too small.

class VerifyBvnRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'bvn' => ['required', 'digits:11'],
        ];
    }
}

class VerificationController extends Controller
{
    public function verifyBvn(VerifyBvnRequest $request)
    {
        return $this->verificationService->verify($request);
    }
}

That’s it. One class, one changed type-hint. No new logic in the controller, no new logic in the service. And yet this one change is the entire fix.

Why this isn’t just cosmetic and what Laravel actually does
It’s easy to see Request vs. SomeCustomRequest as a style preference... maybe even a lazy shortcut when you're prototyping and don't want to bother writing rules yet. But in Laravel, the type hint on a controller method parameter isn't just for documentation sake. It's an instruction to the service container about what to construct and how.

Jeffrey Way put it best on one of his Laracasts years ago—"The code in your controller method literally never executes unless the request passes validation first."

I am probably paraphrasing it, but yeah 😂.

When Laravel sees a parameter type-hinted as a class extending FormRequest, it doesn't just hand your controller the raw request. It:

Instantiates your FormRequest class through the container.
Calls authorize() . If it returns false, the request is rejected with a 403 before your controller ever runs.
Runs the input against rules().
If validation fails, it throws a ValidationException immediately. Laravel's exception handler turns that into a 422 JSON response automatically. Your controller method body never executes.
This happens because FormRequest implements Illuminate\Contracts\Validation\ValidatesWhenResolved, and Laravel's container checks for that interface as part of resolving the object—validation is wired into object construction itself, not into something you have to remember to call inside your method.

Type-hint a bare Illuminate\Http\Request instead, and none of that machinery exists. Laravel just hands you the request as-is. There's no gate. Whatever arrived over the wire is what your code operates on, unfiltered, all the way down the call stack.

Why I’m calling it a security gate, not just a bug
It’s tempting to file this under “validation bug” and move on. I’d push back on that framing a little.

A missing FormRequest doesn't just mean “bad UX” (a confusing 500 instead of a clean 422). It means the boundary between untrusted input and your business logic doesn't exist for that endpoint. Every layer downstream—services, external API calls, database writes—is implicitly trusting that validation already happened. When it didn't, that trust is misplaced, and the failure mode is whatever the least forgiving layer in the chain happens to do with garbage input.

In a low-stakes case, that’s a bad error message. In a codebase moving money, verifying identity, or writing to a ledger, “the input was never actually checked” is a much bigger sentence than it sounds.

How I’d catch this faster next time
The good news: this is very greppable.

grep -rn '(Request \$request)' app/Http/Controllers modules #if you use modules

Every match is worth five seconds of attention. Some will be legitimately fine … a GET endpoint with nothing to validate. But on any POST/PUT/PATCH method, a bare Request type-hint is a flag worth chasing down, not a style nit to skip past.

The tests didn’t tell me why things were broken, but they told me where. But the pattern, once I saw it in one place, was exactly the same in four or five others across a codebase I hadn’t fully mapped yet. That’s usually a good sign you’ve found something systemic rather than a one-off typo.

Oh, and the mock issue from the top? Turned out the mock was working exactly as intended the whole time. 😂 I’d just misattributed a failure to the wrong test method a few debugging rounds earlier. Dont underestimate how much time you can lose staring at the right error message for the wrong test.😂

I’m done ranting, I think. 😁

You can connect with me on Twitter: https://twitter.com/mabadejedanphp

Deploying your Laravel app to AWS from GitHub—A cost-effective way

Daniel Mabadeje — Tue, 28 Jul 2026 12:16:00 +0000

Okay… where do I start…
I have been kind of running away from AWS for a while now. Not because I hate it; I just felt it had so much going on, and I usually find myself involved more in building applications than setting up cloud infrastructures (until recently). So I thought, as I am practically getting my hands dirty, why not also walk you through what I am doing myself? And yes, also have something as a reference too. 😀

Why does this guide exist?
First, this is basically to show you my thought process of how I manage monolithic applications with a small team, especially for staging environments.

And also... most “deploy Laravel to AWS” tutorials show you a happy path. I feel like they don’t really tell you about the silent billing plan block that kills your EC2 launch, the Nginx document root trap, the security group CIDR gotcha that times out your database, or the PHP version mismatch that breaks Composer mid-deploy.

Oh yes, and this goated tweet here on a lighter note. 😂

One more meme picture I saw on my good friend Elisha Ukpong’s status. 😂

At the end of this guide, you should have the following:

A Laravel app deployed to AWS Elastic Beanstalk
A GitHub Actions CI/CD pipeline using OIDC (no static AWS keys stored in GitHub)
A managed RDS MySQL database
Automatic migrations on every deploy
SSH access for debugging And an estimated monthly cost of ~$15–25/mo (t2.micro EB instance + db.t4g.micro RDS), compared to ~$60–70/mo for an ECS Fargate + ALB + NAT setup.

What do I need to continue this guide?

An AWS account
A Laravel app on GitHub (we’ll make reference to a dev branch for staging)
A domain (we’ll connect it at the end)
AWS CLI and EB CLI installed locally If you don’t have the AWS CLI and EB CLI installed locally for Mac, you can type the command:

brew install awscli
brew install awsebcli

Please note, I am really going to take my time on this one. from setup to deployment, so there may be some things you may already know as someone who may have used or is using AWS. And heads up, this is going to be a longgggggg article.

Alright, let’s get started.

AWS Account Setup

Create an IAM Admin User

The first thing you need to have in mind is… never use your root AWS account for day-to-day work!!!. Instead, create a dedicated admin user:

How do I do that?

Go to your AWS Console and go to IAM (you can as well use the search bar to search for “IAM”)
Click on "create group"; you can name it "admin" and attach "AdministratorAccess."
Then in users, create a new user, maybe something like [your-name-admin], and then add it to the admins group
On the security credentials tab, enable MFA for the user

Upgrade Your AWS Account to Pay-As-You-Go
This is one of the most commonly missed steps. New AWS accounts are sometimes placed on a “Free Plan” that silently blocks EC2 instance launches (even t2.micro) with cryptic errors like “instance type not eligible for Free Tier.” I had this issue too.

How do you fix this? In the AWS Console, go to Billing and Cost Management and look for the upgrade plan button. Click it and confirm.
Without this, Elastic Beanstalk environments may fail to launch with no clear error message.

OIDC Authentication for GitHub Actions
Instead of storing AWS access keys as GitHub secrets, which is a security anti-pattern, we use OpenID Connect (OIDC). GitHub’s CI runner proves its identity to AWS directly; no long-lived credentials are needed.

Adding GitHub as an OIDC Identity Provider
Head over to IAM in the AWS console and select Identity providers. Click Add provider.

Select OpenID Connect as the provider type.
token.actions.githubusercontent.com as the provider URL
and sts.amazonaws.com as the audience

Press enter

Create the GitHub Actions IAM role.
Still on the IAM page, click on “Roles” under Access Management. Click on the Create Role button.
Here is the information you will need.

Trusted entity type: Web Identity
Identity Provider: token.actions.githubusercontent.com
Audience: sts.amazonaws.com
Attach policy: AdministratorAccess (you can scope this down to least privilege once you're stable).

After creation, you may need to edit the trust policy to scope it to your specific repository. See code below:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:YOUR_ORG/YOUR_REPO:*"
        }
      }
    }
  ]
}

Copy the role ARN; you’ll need to add this to GitHub Secrets as AWS_ROLE_ARN.

Up next? RDS MySQL Database 😆

Let's create this database.
On the AWS console, search for RDS, enter RDS, and click "Select Database."

Now fill in the following details.

Engine: MySQL
Template: Dev/Test (this disables Multi-AZ and saves cost)
DB instance class: db.t4g.micro
Storage: 20 GB gp3
VPC: default VPC
Public access: No (the app connects internally; never!) ever! expose RDS to the internet)
Create a new security group: [your-app]-rds-sg
Initial database name: [your_app]_staging
You will need to take note of the endpoint hostname (an example is your-db.xxxxx.us-east-1.rds.amazonaws.com), port (usually 3306), username, and password.

Let's talk about the security group too (I think this is a critical detail for me).
The RDS security group needs an inbound rule allowing MySQL (port 3306) from the EC2 security group that Elastic Beanstalk will assign to your instance… not an IP address (CIDR).

A CIDR-based inbound rule (like 0.0.0.0/0 or “My IP”) will not work correctly for EB-to-RDS communication. You will get connection timeouts. The rule must reference the EC2 security group by its ID. We’ll come back to this after the EB environment is created.

Now to the main part… Elastic Beanstalk Setup 😁

Creating EB Service Roles
Before creating an EB environment, two IAM roles are needed:

The Service role (EB in itself):

Trusted entity elasticbeanstalk.amazonaws.com
Use case: Environment
Name: aws-elasticbeanstalk-service-role
EC2 instance role (your actual server):

Trusted entity: EC2
Use case: Elastic Beanstalk-Compute
Name: aws-elasticbeanstalk-ec2-role

Creating the EB Application and Environment
Application name: your-app-backend
Environment name: your-app-backend-staging
Platform: PHP (choose the PHP version matching your composer.json PHP constraint—check with php -v locally)
Instance type: t2.micro (this is free-eligible, about $8–10/month)
Single instance (no load balancer — this is what keeps costs low)

Set the Document Root
Just a quick notice….
Laravel’s entry point is public/index.php, not the project root. By default, EB’s nginx config serves from the project root, which causes a 403 Forbidden on every request.

You can fix this via the official EB setting (you don’t need any extra nginx configuration).

Add the Nginx rewrite rule.
Even with the document root set, Nginx needs a rewrite rule to send all non-file requests to index.php (Laravel’s front controller). Without this, every route except / returns 404.

Create this file in your repo:

.platform/nginx/conf.d/elasticbeanstalk/01_laravel.conf

with this code...

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

Commit and push this file to your deploy branch. This file is minimal by design: it only adds the rewrite and lets EB’s platform-managed config handle everything else (document root, PHP-FPM connection, and fastcgi params).

Set Environment Variables
Rather than shipping an .env file (insecure), inject all config as EB environment properties. The fastest way is via the EB CLI:

# If its first time setup, run from your project root
eb init        # select us-east-1, select your application
eb use your-app-backend-staging

# Then set all variables in one command
eb setenv \
APP_ENV=staging \
APP_KEY=base64:your-generated-key \
APP_DEBUG=false \
APP_URL=https://staging-api.yourdomain.com \
DB_CONNECTION=mysql \
DB_HOST=your-db.xxxxx.us-east-1.rds.amazonaws.com \
DB_PORT=3306 \
DB_DATABASE=your_app_staging \
DB_USERNAME=your_db_user \
DB_PASSWORD=your_db_password \
CACHE_DRIVER=file \
SESSION_DRIVER=file \
QUEUE_CONNECTION=sync \
LOG_CHANNEL=stack \
# ... add all provider keys here

Some gotchas...

EB has a ~4096 character limit on the combined environment variable payload passed through CloudFormation. If you have very long values (e.g. a JWT token over 2000 characters), eb setenv will fail with the template format error: Parameter ‘EnvironmentVariables’ default value length is greater than 4096. Drop the oversized variable and add it separately via AWS Secrets Manager or SSM Parameter Store instead.

GitHub Actions CI/CD Pipeline

Create .github/workflows/deploy-staging.yml:

name: Deploy to AWS Staging

on:
  push:
    branches:
      - dev

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: us-east-1

      - name: Install PHP dependencies
        run: |
          composer install --no-dev --optimize-autoloader --no-interaction

      - name: Create deployment package
        run: |
          zip -r deploy.zip . \
            --exclude "*.git*" \
            --exclude ".github/*" \
            --exclude "node_modules/*" \
            --exclude "tests/*" \
            --exclude ".env*"

      - name: Upload to S3
        run: |
          VERSION_LABEL="v-$(date +%Y%m%d%H%M%S)"
          aws s3 cp deploy.zip s3://elasticbeanstalk-us-east-1-YOUR_ACCOUNT_ID/deploy.zip
          echo "VERSION_LABEL=$VERSION_LABEL" >> $GITHUB_ENV

      - name: Create EB application version
        run: |
          aws elasticbeanstalk create-application-version \
            --application-name your-app-backend \
            --version-label ${{ env.VERSION_LABEL }} \
            --source-bundle S3Bucket=elasticbeanstalk-us-east-1-YOUR_ACCOUNT_ID,S3Key=deploy.zip

      - name: Deploy to Elastic Beanstalk
        run: |
          aws elasticbeanstalk update-environment \
            --environment-name your-app-backend-staging \
            --version-label ${{ env.VERSION_LABEL }}

Add AWS_ROLE_ARN to your GitHub repository secrets (Settings → Secrets and variables → Actions).

Fix the RDS security group.
After your first successful deploy, the EC2 instance’s security group ID will be visible. You need to allow it in the RDS security group:

EB Console → Configuration → Instance traffic and scaling → Note the EC2 security group ID (format: sg-xxxxxxxxxx)
EC2 Console → Security Groups → Find your-app-rds-sg → Inbound Rules → Edit Inbound Rules
Now here’s where it gets tricky…

The natural instinct is to type your IP address as the source. Don’t do this.

CIDR-based inbound rules cause connection timeouts for EB-to-RDS communication. And when you try to switch an existing CIDR rule to a security group reference, AWS throws that error above. This is because the rule types are fundamentally different. You can’t convert one to the other in place.

The fix:

Delete the existing CIDR rule entirely
Click Add rule
Type: MySQL/Aurora, Port: 3306, Source: Custom → paste/select the EC2 security group ID
Save rules

Important: Every time your EB environment is recreated (e.g, when adding SSH access, changing platform version, or running eb ssh --setup), check this rule. The EC2 security group ID can change, and you'll get a Connection timed out error that looks completely unrelated to what you just did.

Running Migrations

EB doesn’t give you a terminal out of the box. To run php artisan commands, you need SSH access first:

eb ssh --setup

This terminates and recreates your EC2 instance. There will be a brief downtime on staging; it's completely fine.

Once connected, there’s another gotcha nobody tells you about: EB environment variables aren’t loaded in your SSH session. The web server process gets them injected automatically, but your interactive shell doesn’t. You’ll know this hit you when you run. Artisan and see:

SQLSTATE[HY000] [2002] Connection refused
Host: 127.0.0.1

That 127.0.0.1 is the giveaway… it's the local fallback, not your RDS endpoint.

Fix it by sourcing the EB env file manually every SSH session:

sudo cat /opt/elasticbeanstalk/deployment/env | sed 's/^/export /' > /tmp/eb_env.sh
source /tmp/eb_env.sh

Verify it worked:

php artisan tinker --execute="echo config('database.connections.mysql.host');"
# Should print your RDS endpoint, not 127.0.0.1

Then navigate to the app directory and run migrations:

cd /var/app/current
php artisan migrate --force

The --force flag is required because Laravel blocks migrations in production environments without explicit confirmation.

Automate Migrations on Every Deploy

You don’t want to SSH in every time you add a migration. EB supports post-deploy hooks—scripts that run automatically after every deploy. Create this file in your repo:

.platform/hooks/postdeploy/01_migrate.sh

#!/bin/bash
set -e

cd /var/app/current
if [ -f /opt/elasticbeanstalk/deployment/env ] ]; then
    export $(cat /opt/elasticbeanstalk/deployment/env | sed 's/^export //' | xargs)
fi
php artisan migrate --force

Make it executable and commit:

chmod +x .platform/hooks/postdeploy/01_migrate.sh
git add -A
git commit -m "Add postdeploy hook to auto-run migrations"
git push origin dev

From this point on, every push dev automatically runs pending migrations after the new code deploys.

Connect Your Domain

If your frontend is on Vercel, your domain’s DNS is managed there and not in your domain registrar’s panel. Namecheap (or wherever you registered) is just the registrar. The actual DNS records need to go into Vercel Dashboard → your team → Domains. yourdomain.app → DNS Records:

NameTypeValueTTLstaging-api CNAME your-app-staging.eba-xxxxxxxx.us-east-1.elasticbeanstalk.com60

If a conflicting A record already exists for it, delete it first. A CNAME and A record cannot coexist on the same name. Vercel will show an error if you try.

Confirm DNS is propagated:

ping staging-api.yourdomain.com

The ping will always timeout: EC2 blocks ICMP by default. That’s normal. What matters is that it resolves to your EB instance IP address. If you see the IP, DNS is working.

Adding SSL with Let’s Encrypt

Since we’re running single-instance EB without a load balancer, we can’t use ACM certificates directly (those attach to ALB listeners). Instead, we use Certbot to get a free Let’s Encrypt certificate that runs on the instance itself.

Create .platform/hooks/postdeploy/02_certbot.sh:

#!/bin/bash
set -e

DOMAIN="staging-api.yourdomain.com"
EMAIL="your@email.com"
if ! command -v certbot &> /dev/null; then
    dnf install -y certbot python3-certbot-nginx
fi
if certbot certificates 2>/dev/null | grep -q "$DOMAIN"; then
    certbot renew --quiet --nginx
else
    certbot --nginx \
        --non-interactive \
        --agree-tos \
        --email "$EMAIL" \
        --domains "$DOMAIN" \
        --redirect
fi

Also open port 443 in the EB EC2 security group automatically. Create .ebextensions/https-sg.config:

Resources:
  sslSecurityGroupIngress:
    Type: AWS::EC2::SecurityGroupIngress
    Properties:
      GroupId:
        "Fn::GetAtt":
          - AWSEBSecurityGroup
          - GroupId
      IpProtocol: tcp
      ToPort: 443
      FromPort: 443
      CidrIp: 0.0.0.0/0

Use "Fn::GetAtt" with the list syntax, EB's YAML parser rejects the shorthand and gives you this error:

Invalid Yaml: could not determine a constructor for the tag !GetAtt

I spent more time on this than I’d like to admit. 😅

Make the hook executable and push:

chmod +x .platform/hooks/postdeploy/02_certbot.sh
git add -A
git commit -m "Add Let's Encrypt SSL via Certbot and open port 443"
git push origin dev

The DNS CNAME must be live and propagated before this hook runs. Certbot verifies domain ownership by making an HTTP request to your domain. If the domain doesn’t resolve to your server yet, the cert request will fail.

One more nginx gotcha (I promise this is the last one).

Even after Certbot successfully gets the cert, you might still see ERR_CONNECTION_REFUSED when hitting the HTTPS URL. This happened to me: Certbot installed the cert, but nginx wasn't actually listening on port 443.

Check it:

sudo ss -tlnp | grep -E '80|443'

If you only see port 80 and not 443, Nginx didn’t pick up Certbot’s SSL config. The fix is to manually create the HTTPS server block:

sudo tee /etc/nginx/conf.d/https.conf > /dev/null << 'EOF'
server {
    listen 443 ssl;
    server_name staging-api.yourdomain.com;
    ssl_certificate /etc/letsencrypt/live/staging-api.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/staging-api.yourdomain.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

root /var/www/html/public;
    index index.php index.html index.htm;
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ \.(php|phar)(/.*)?$ {
        fastcgi_pass php-fpm;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }
}
server {
    listen 80;
    server_name staging-api.yourdomain.com;
    return 301 https://$host$request_uri;
}
EOF
sudo nginx -t && sudo systemctl reload nginx

Check if port 443 is now listening:

sudo ss -tlnp | grep -E '80|443'
# LISTEN 0   511   0.0.0.0:443   ← this is what you want to see
# LISTEN 0   511   0.0.0.0:80

That’s it. You’re live.

To recap what we built:

Laravel app deployed to AWS Elastic Beanstalk (single instance, ~$15–25/mo)
GitHub Actions CI/CD via OIDC: no static AWS keys stored anywhere
RDS MySQL with proper security group configuration
Automated migrations on every deploy via postdeploy hooks
Free SSL via Let’s Encrypt/Certbot
Custom domain connected

Common Errors and Fixes

I had the liberty to draft out a few errors that you may experience during this deployment process, and I have suggested some solutions too.

And yeah, I guess… we are done. 😂🎉

Whew!!! That was a long one, and I do hope you found one or two things helpful. I am also curious about how you handle your own deployments too with Docker and all the other approaches that aid development.

Happy Cost savingg!!

You can connect with me on Twitter: https://twitter.com/mabadejedanphp

Writing Smart Contracts in PHP — Bringing PHP to the Blockchain

Daniel Mabadeje — Thu, 23 Apr 2026 20:15:55 +0000

What if PHP developers didn’t have to leave their ecosystem to build in Web3?

I have been writing PHP for years. Laravel, Filament, APIs, admin systems, etc. I have written applications in JavaScript and some in .NET too. But PHP has been my home. But like a lot of PHP developers, I noticed that whenever blockchain came up in a conversation, it felt like a conversation happening in another room. The Web3 space has its own languages, its own tooling, its own ecosystem. Solidity for Ethereum. Rust for Solana. Move for Aptos. If you wanted to build smart contracts, the unspoken assumption was: learn a new language first (most likely Rust or Solidity 😂). But I kept wondering… does it have to be that way?

The Web3 PHP Packages Already Exist

Before I go further, I want to be clear: PHP is not absent from Web3. There are already some excellent packages that let you interact with blockchains from PHP:

web3p/web3.php : connect to Ethereum nodes, sign transactions, call contracts
php-solana-sdk : interact with the Solana blockchain
kornrunner/keccak : Keccak-256 hashing in pure PHP

These packages are great. Using them, a PHP developer can read from a smart contract, send transactions, listen to events, and build blockchain-powered applications entirely in PHP. In fact, I tried building a web3 giveaway app at some point to test how I can implement transactions with Solana, Ethereum, and Bitcoin (Solana was successful though 😂).

But there is a ceiling. You can talk to smart contracts. You cannot write them in PHP.

There is a big barrier…

Virtual Machine Compatibility: Popular blockchains like Ethereum run on the EVM, which only executes bytecode compiled from languages like Solidity or Vyper. PHP is a server-side scripting language meant to be interpreted by the PHP engine (Zend VM), not a blockchain VM.

Lack of Determinism: Smart contracts must be deterministic, meaning they must produce the exact same result on every computer in the network. PHP has many features (like random number generation and time-based functions) that could cause different nodes to reach different results, breaking blockchain consensus. You can have some more information written by Ramchandhar Rapolu here.

The moment you need to deploy a new contract, you leave the PHP world and open a .sol file. You need to learn Solidity. You need to understand the EVM type system. You need to configure Hardhat or Foundry.

This gap is what I am trying to close (or shorten, at least)

The Inspiration: NativePHP!!

If you are in the PHP community, you have probably heard of NativePHP.

The idea behind it is elegant: you already know PHP and Laravel. What if you could use those exact skills to build native mobile and desktop applications without learning Swift, Kotlin, or React Native?

NativePHP does not run PHP inside your iPhone. It uses PHP as a syntax and logic layer, compiling or bridging that code into something the native runtime understands. That mental model stuck with me. And one day it just clicked…

“What if we did the same thing for smart contracts?”
PHP does not need to run on the Ethereum virtual machine. It just needs to be the layer where you write the contract. We parse the PHP, understand its intent, and output valid Solidity.

That is the idea behind PHP-Solidity.

What PHP-Solidity Is (and Is Not)

Let me be direct about what this project does, because the name might suggest something it is not 😂.

PHP-Solidity is a transpiler. You write a PHP class using special EVM types and PHP 8 attributes. The transpiler reads that file, parses it into an abstract syntax tree, and outputs a .sol file with valid Solidity source code, which you then compile and deploy with standard tooling like Hardhat or Foundry.

PHP never runs on the blockchain. The EVM never executes PHP. What PHP-Solidity gives you is the ability to express a smart contract using syntax you already know, in a language your IDE already understands.

Here is what it looks like in practice. This is a simple ERC-20 token written entirely in PHP:

<?php

use PhpSolidity\Attributes\Contract;
use PhpSolidity\Attributes\SolidityEvent;
use PhpSolidity\Attributes\Storage;
use PhpSolidity\Attributes\External;
use PhpSolidity\Attributes\View;
use PhpSolidity\Attributes\Constructor;
use PhpSolidity\Attributes\Modifier;
use PhpSolidity\Attributes\Guarded;

#[Contract(license: 'MIT', version: '^0.8.20')]
#[SolidityEvent('Transfer', ['address indexed from', 'address indexed to', 'uint256 value'])]
class MyToken
{
    #[Storage(public: true)]
    private uint256 $totalSupply;

    #[Storage]
    private mapping $balances;

    #[Storage]
    private address $owner;

    #[Constructor]
    public function __construct(uint256 $initialSupply)
    {
        $this->owner       = msg::sender();
        $this->totalSupply = $initialSupply;
        $this->balances[msg::sender()] = $initialSupply;
        Event::emit('Transfer', address::zero(), msg::sender(), $initialSupply);
    }

    #[Modifier]
    private function onlyOwner(): void
    {
        EVM::require(msg::sender() == $this->owner, "Not the owner");
    }

    #[External, View]
    public function balanceOf(address $account): uint256
    {
        return $this->balances[$account];
    }

    #[External]
    public function transfer(address $to, uint256 $amount): bool
    {
        EVM::require($this->balances[msg::sender()] >= $amount, "Insufficient balance");
        $this->balances[msg::sender()] -= $amount;
        $this->balances[$to]           += $amount;
        Event::emit('Transfer', msg::sender(), $to, $amount);
        return true;
    }

    #[External, Guarded('onlyOwner')]
    public function mint(address $to, uint256 $amount): void
    {
        $this->totalSupply   += $amount;
        $this->balances[$to] += $amount;
        Event::emit('Transfer', address::zero(), $to, $amount);
    }
}

You run one command:

php bin/phpsolidity compile contracts/MyToken.php

And you get this valid, deployable, (beautiful😏) Solidity:

How It Works Under the Hood
The pipeline has four stages:

1. Validation
Before any parsing happens, the source file is scanned for things that make no sense on a blockchain: float literals (the EVM has no floating point), rand() (unsafe on-chain. Miners can influence block randomness), file_get_contents(), superglobals, and so on. If you write something invalid, you get a clear error immediately:

2. Parsing
The PHP source is parsed using nikic/php-parser, one of the most mature PHP AST libraries available. This gives us a complete abstract syntax tree of the PHP class. We walk to that tree looking for a class decorated with #[Contract], then extract everything from it: state variables (from PHP 8 attributes on properties), functions (from methods and their attributes), events (from class-level attributes), and modifiers.

The function bodies are translated line by line
$this->balances[msg::sender()] becomes balances[msg.sender], EVM::require(…) becomes require(…). Event::emit(‘Transfer’, …) becomes emit Transfer(…).

3. AST to ContractNode
The PHP AST is converted into our own internal representation, a ContractNode containing FunctionNode, StateVariableNode, EventNode, and ModifierNode objects. This intermediate layer keeps the parser and emitter completely decoupled. In the future, this same AST could target Vyper or Yul instead of Solidity.

4. Emitting Solidity
The SolidityEmitter walks the ContractNode and builds the Solidity source string—license header, pragma, state variables, events, modifiers, constructor, and functions. The output is formatted, readable Solidity that you would not be embarrassed to share.

The EVM Type System in PHP

One of the trickiest parts of this project is the type system. Solidity has types like uint256, address, bytes32, and mapping that simply do not exist in PHP.
The solution is a set of PHP stub classes in stubs/evm.php. These classes: uint256, address, mapping, msg, and block… exist purely for the IDE and the transpiler. They give your editor autocompletion and type checking, and they give the transpiler something to map.

// In your contract file — valid PHP that your IDE understands
private uint256 $totalSupply;
$this->balances[msg::sender()] = $initialSupply;

// What the transpiler emits
uint256 private totalSupply;
balances[msg.sender] = initialSupply;

There is one notable constraint: PHP treats require as a language construct, not a function. You cannot shadow it. So instead of require(condition, “message”), you write EVM::require(condition, “message”).which the transpiler converts to Solidity’s require().

The Limits

Am I happy it works on my machine? Yes. 😂🔥

Are there real limitations? Also yesss

PHP-Solidity is a v0.1 project. It works, but it is not magic. Here are the real limitations I think you should know:

No floating point. The EVM has no float type. All arithmetic must be integer-based, scaled by a factor (usually 1e18 for ETH values). This is a Solidity limitation, not ours though (but you should know😉).

Supported PHP subset only. You cannot use closures, dynamic arrays, reflection, or most of PHP’s standard library inside a contract. The transpiler enforces this with clear errors.

Body translation is pattern-based. The function body translator works by recognising common patterns ($this->, msg::sender(), etc.) and replacing them. Complex PHP expressions that have no Solidity equivalent will not transpile correctly.

No struct support yet. Solidity structs, which map to complex value types are not yet supported. This is on the roadmap.

No interface or abstract contract support yet. I hope to add this in future versions or leave it open for others who may want to contribute in this way too.

You still need Solidity tooling to deploy. PHP-Solidity produces .sol files. You still use Hardhat, Foundry, or Remix to compile and deploy them. PHP-Solidity does not replace that step; it just means you write in PHP first.

The Potential

Despite those limits, the potential here is real.

You have heard this many times but here I go again 😂… “PHP is one of the most widely used languages in the world." Laravel alone powers hundreds of thousands of applications. I personally think that the Web3 ecosystem desperately needs more developers. And right now, the barrier to entry is high because developers have to learn an entirely new language and toolchain before they can contribute anything.

PHP-Solidity lowers that barrier. A Laravel developer can write their first smart contract on day one, using concepts they already understand: classes, typed properties, methods, and attributes. They can contribute to DeFi projects, NFT platforms, and DAO tooling without spending months learning Solidity from scratch.

And the design is extensible. The internal AST is language-agnostic. A Vyper emitter, a Yul emitter, or even a Cairo emitter (for StarkNet) could be built on top of the same parser. The PHP syntax layer stays the same; only the output target changes.

It Is Open Source (Come Build With Me)🎉

PHP-Solidity is published on Packagist and completely open source:

composer require danielmabadeje/php-solidity

The GitHub repository is at https://github.com/DanielMabadeje/php-solidity

There is meaningful work to do at every level:

Beginners: add new EVM types (bytes16, bytes4), improve error messages, and write example contracts.

Intermediate: improve the body translator to handle more PHP expression patterns and add struct support.

Advanced: build the interface/abstract contract system, explore a Vyper emitter, write a formal test suite.

The CONTRIBUTING.md in the repo walks through exactly how the transpiler works, how to add a new type, how to add a validator rule, and the code standards we follow.

We have watched NativePHP prove that PHP developers do not have to abandon their ecosystem to work on mobile applications. The same principle applies here.

You do not have to learn Solidity to contribute to Web3. You do not have to leave Laravel to build DeFi tooling. PHP-Solidity is an early, honest attempt to build that bridge.

It is not perfect. It is not complete. But it works (on my laptop and hopefully in yours 😁) and every open source project starts somewhere. If this resonates with you, install the package, write a contract, break something, and open a PR. That is how this gets better.

You can connect with me on twitter : https://twitter.com/mabadejedanphp

Automating Laravel CI/CD with GitHub Actions on Namecheap

Daniel Mabadeje — Tue, 23 Apr 2024 10:18:50 +0000

Who is this article for?

Have you had some struggles hosting your Laravel application on namecheap? Or you have been looking for a way to automate your deployments to your namecheap server? This article is for you.

Lets talk about Github actions a bit🙂

GitHub Actions is a powerful tool for automating various workflows and tasks within the GitHub ecosystem. Here are some of the key benefits of using GitHub Actions:

Continuous Integration and Deployment (CI/CD): GitHub Actions enables you to set up automated CI/CD pipelines, allowing you to build, test, and deploy your applications with ease. You can define custom workflows that trigger actions based on events like pushes, pull requests, or scheduled intervals. (This is what we will be focusing in this article)
Flexibility and Customization: GitHub Actions provides a flexible and customizable platform where you can define workflows using YAML syntax. You have granular control over the steps, dependencies, and conditions of your actions, allowing you to create tailored workflows that fit your specific needs.
Seamless Integration with GitHub: Since GitHub Actions is tightly integrated with the GitHub platform, it offers seamless integration with your repositories, issues, pull requests, and other GitHub features. You can leverage this integration to create workflows that interact with your repository, update issues, trigger notifications, and more.
Scalability: GitHub Actions is designed to scale with your needs. You can run workflows on different types of virtual machines and specify resource allocation for each job. Additionally, parallel and matrix strategies allow you to distribute workloads across multiple machines, enabling faster execution times.
Cross-Platform Support: GitHub Actions supports a wide range of platforms and operating systems, including Linux, macOS, and Windows. You can test your applications across different environments, ensuring compatibility and reliability.
Cost-Efficient: GitHub Actions provides a generous amount of free usage every month, allowing you to automate your workflows without incurring additional costs. If you require more resources or have high-demand workflows, you can choose from various pricing options that align with your needs.
Vast Ecosystem and Community Support: GitHub Actions has a large ecosystem of pre-built actions that you can use to perform common tasks. These actions, created by both GitHub and the community, cover a wide range of functionalities, from building and testing applications to deploying to various platforms. You can also create and share your own actions with others.

With all these mentioned, It is safe to say that Github actions is the real IDAN (magic but colloquially means boss.)😂

So How Do I Setup this Github Actions?

So first of all lets head to our cpanel, you shouls see something like this.

This particular step here should be followed if you want to deploy to a sub domain. If you want to deploy to the main domain itself, you may skip this step

Click on Subdomains

Fill in the details for your sub domain and click on create.
This would automatically create the subdomain and also create the document root.

Sidenote: I prefer to use the subdomain I created as the actual document root. So I can have my subdomain field as danielsub, my document root would be danielsub.myazabox.site.
After we have successfully created the sub domain, we create an FTP account

What is an FTP Account?🤔
According to Techopedia, A file transfer protocol account (FTP account) is a type of user account that enables the transfer of files with a host computer by using FTP services.
So basically we are creating an account to facilitate file transfer to a server.

On your CPanel, Navigate to the files section as shown in the image

Click on FTP Accounts. At this point you should have something like this.

Put in your desired login details and ensure you stored those details properly in maybe your notes or somewhere safe (you would need them). Also select domain you want to assign the ftp account to. In this case it would be the subdomain that we created recently.

When you are done, you can click on the "Create FTP Account" button.

If you look below, you should see a new ftp account created as shown below

to view your ftp details like Username, server details and in some cases Port. click on "Configure FTP Client"
Now we are done with CPANEL, lets move over to github and perform this magic.

At this point I believe you already have your Laravel project pushed to Github. If this has not been done, ensure you have pushed your laravel project to your repository. (This deployment procedure works for both personal and organisation account).

So for the purpose of this article, I will use a laravel application that I have pushed long ago.
Navigate to the repository that houses your laravel project, and click on the actions tab.

Click on "setup new workflow for yourself -> "

This would create a .yml file for you to work with (mostly a main.yml file)

Copy the code below and paste it in your main.yml



name: Deploy Laravel Project on push
on:
  push:
    branches:
      - main
jobs:
  web-deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
      - name: Get the latest code
        uses: actions/checkout@v2.3.2
      - uses: actions/setup-node@master
      - name: Copy .env
        run: php -r "file_exists('.env') || copy('.env.example', '.env');"
      - name: Install Dependencies
        run: composer update --ignore-platform-reqs
      - name: Generate key
        run: php artisan key:generate
      - name: Generate storage link
        run: php artisan storage:link
      - name: Directory Permissions
        run: chmod -R 777 storage bootstrap/cache
      - name: 📂 Sync files
        uses: SamKirkland/FTP-Deploy-Action@v4.3.4
        with:
          server: ${{ secrets.YOURSITE_FTP_SERVER}}
          username: ${{ secrets.USERNAME }}
          password: ${{ secrets.YOUR_PASSWORD }}

You can use the code above in your main.yml or you could go to Samkirkland to view other use cases to deploy your application with Github actions. Note that it is best practice to create secret keys rather than hard coding the values.

The code above basically checks if there is a new push to the branch you specified. (In this case the main branch). Runs a composer update, generates a key with the laravel commands and also links the storage.

After this is done, it uploads the files to the document directory in your CPanel. Do not forget to change the username, ftp and password field to their respective values which you saved earlier on. To take it a notch higher, you can store them as SECRETS on github.

It is Important to note that your first deployment may take a long time to sync its files as it copies the newly created vendor folder (which houses a lot of files).
One more thing, If you are using an Apache server, there may be need to create a .htaccess in your root directory. After the .htaccess file creation, add the following code.



# RewriteEngine on

# # serve existing files in the /public folder as if they were in /
# RewriteCond %{DOCUMENT_ROOT}public%{REQUEST_URI} -f
# RewriteRule (.+) /public/$1 [L]

# # route everything else to /public/index.php
# RewriteRule ^ /public/index.php [L]

# DirectoryIndex index.php
<IfModule mod_rewrite.c>

    RewriteEngine On
    # RewriteBase /public_html/

    RewriteRule ^$ public/index.php [L]

    RewriteRule ^((?!public/).*)$ public/$1 [L,NC]

</IfModule>

And Voila!!!🎉🎉🎉🎉🎉
You have successfully deployed a laravel application to your cpanel through github actions.

Follow me on twitter : https://twitter.com/mabadejedanphp

How to Preview Laravel Notification Emails

Daniel Mabadeje — Tue, 23 Apr 2024 10:13:22 +0000

It’s a hassle trying to test your the HTML of your notification class by sending multiple requests to trigger the Notification to your mail. Do you want to preview your emails in the browser and see what they would look like in the recepients mailbox without having to go through the hassles of sending multiple requests to trigger the notifications? Here are a few lines of codes that can help you with that.

The Snippet below shows how you can preview your notifications with your web routes. I am assuming you have created a Notification called TemplateNotification (for this example) or you replaced TemplateNotification with your custom class name. In the example below, my notification class did not require any parameters.

Route::get(‘mailable’, function () {
  return (new App\Notifications\TemplateNotification())->toMail((object) [])->render();
});

Let’s try this with a class that requires a parameter let’s say the UserRegisteredNotification class that requires the User Object. The code would look like this.

Route::get('mailable', function () {
    $user = App\Models\User::inRandomOrder()->first();
    return (new App\Notifications\UserRegisteredNotification($user))->toMail((object) [])->render();    

});

If you observed in the examples above, you would see that I typecasted an empty array as an object to the toMail method. This is because the toMail method is expecting an object as a parameter.
I hope this helps

Follow me on twitter : https://twitter.com/mabadejedanphp

How to create tables on Heroku Postgresql

Daniel Mabadeje — Wed, 03 Mar 2021 20:38:39 +0000

So you want to deploy this your idea or project for demo on heroku. Probably, you are deploying from Github, then it’s time for you to migrate or create postgres databases and tables, but then you get confused especially when it’s not a laravel application where you can use the console to migrate tables. so you check the documentation and you get even more confused. this article is for you.
I encountered this some time ago and I felt bad so I decided to do an article on this.
Here we are going to cover everything concerning database and table creation starting from :

Adding heroku-postgres as an add-on
Attaching it as a database
Getting configuration
Creating table using dataclips

In this article I believe you have a heroku account and you have add your project there so we move over to adding heroku-postgres as an add-on

Adding Heroku-Postgres as an add-on

On the tabs menu you will see the resources link, when clicked should take you to something like this

https://dashboard.heroku.com/apps/{your_app}/resources
you will see something like this..

so click on find more add-ons and search for Heroku postgres you will see this

click on heroku postgres which will take you to this page..

click on install heroku postgres and add it to your project.
now we move over to attaching it as a database

Attaching as a Database

if you check your resources page you will see that heroku-postgres has been installed and you will see a button that says Attach As Database, click on it which will give you your configuration details. Once this is done, check your settings page and click reveal config var you will a url added there. It contains your database name, password, database host, database name. those are the credentials you add to your app to connect to database.

Creating Tables Using Dataclips

If you want to know about dataclips you could check here.
So “Heroku Dataclips enable you to create SQL queries for your Heroku Postgres databases and share the results with colleagues, third-party tools, and the public” — heroku.
so see them as saved queries or as endpoints or as shortcodes (for wordpress people) where you write your SQL queries and they are saved and can be ran.
So we going to use this to create a users table with a dataclip
Note: Datclips by default allow users to read only i.e you can write queries to select data from database but you can’t manipulate it.
for you to alter this setting, you need to write this



set transaction read write;

before writing your queries.
Now back to creating our table.
so when we select new dataclip it takes us to a page we can write our queries
we select the project we want the query to execute in and also give a title to our dataclip. then we write our query.



CREATE TABLE user( user_id serial PRIMARY KEY, username VARCHAR ( 50 ) UNIQUE NOT NULL, password VARCHAR ( 50 ) NOT NULL, email VARCHAR ( 255 ) UNIQUE NOT NULL, created_on TIMESTAMP NOT NULL, last_login TIMESTAMP );

once this written click on save and run.
Voila!!
You have created your first table on Heroku..
Congrats!!
If you like this article, feel free to check my profile for more amazing content
also check me on github as:

https://github.com/DanielMabadeje
Thanks

PHP Getting Started

Daniel Mabadeje — Wed, 04 Nov 2020 09:06:41 +0000

So you want to start PHP?
Welcome, because in this article we will be looking at getting started with PHP

First of all what is PHP?
PHP is an acronym for "PHP: Hypertext Preprocessor". PHP is a widely-used, open source scripting language. PHP scripts are executed on the server. That means PHP is a server-side language i.e scripts executed on the server mostly backend.

Before we go into installation, lets see what PHP can do. PHP can do this and more:

PHP can generate dynamic page content.
It can create, open, read, write, delete, and close files on the server.
It can collect form data.
This language also, can send and receive cookies.
PHP can add, delete, modify data in your database, in other words, it can manipulate the database.
As a server-side language, it can be used to control user-access.
It can encrypt data.
PHP files can contain HTML,CSS and Javascript.

so Why PHP?

PHP runs on various platforms (Windows, Linux, Unix, Mac OS X, etc.)
PHP is compatible with almost all servers used today (Apache, IIS, etc.)
PHP supports a wide range of databases
PHP is free. Download it from the official PHP resource: www.php.net
PHP is easy to learn
It runs efficiently on the server side

Installation

At the time this article was written the version of PHP was version php 7.
At the moment PHP is much faster than previous PHP versions, it supports new operators and it also has an improved error handling technique.

Getting started with PHP.

To start using PHP, you can:

Find a web host with PHP and MySQL support.
Install a web server on your own PC, and then install PHP and MySQL. Most web hosts used are Laragon, Xampp, Wamp etc.

If your server has activated support for PHP you do not need to do anything.

Just create some .php files, place them in your web directory, and the server will automatically parse them for you.

You do not need to compile anything or install any extra tools.

Because PHP is free, most web hosts (locally or production) like the ones listed above offer PHP support.

However, if your server does not support PHP, you will need to:

install a web server.
install PHP.
install a database, such as MySQL.

After doing all this, create a file with .php extension in the folder provided for you to put your projects. E.g In Laragon, every project you want create is in www folder. while in xampp, it is in the htdocs folder.

now lets write our first line of code in the newly created file..
Please note that PHP codes start with <?php and end with ?>

so let's try..

<?php
$txt = "PHP";
echo "I love $txt!";
?>

And Voila!! you have setup PHP on your PC.

MATERIALS

In order to get full documentation on PHP

check www.php.net

As other languages have their frameworks, so does PHP

Frameworks like..

and many others

for tutorials check
https://www.w3schools.com/php/default.asp
https://www.tutorialspoint.com/php/php_introduction.htm
and others..

for Online Code editors or environments you could check
https://phpsandbox.io/

feel free to check me out on Github:https://github.com/DanielMabadeje

How Web Browsers and Servers Communicate

Daniel Mabadeje — Tue, 03 Nov 2020 16:25:58 +0000

Have you ever wondered how you are able to go to website on the browser and it views it or wondered why the website you opened in country is not allowed in another country? Or have you wanted to have a sneak peak of the behind the scenes that happen on the web? Then this is the right article for you there are protocols in which your browser follows in order to have access to a particular website which we will cover in this article.

Please note that Web servers are what supply the content for web browsers. What the browser requests, the server delivers through internet network connections.

In this article we will cover

Client-Server Network Design and the Web
Network Protocols for Web Browsers and Servers

First of all let me just start by saying Web browsers and servers communicate using TCP/IP. … The browser initiates a TCP connection to the web server or server pool (using port 80 by default) through its IP address as published in DNS. As part of this process, the browser also makes DNS lookup requests to convert the URL to an IP address.

Client-Server Network Design and the Web

Web browsers and web servers function together as a client-server system. In computer networking, client-server is a standard method for designing applications where data is kept in central locations (server computers) and efficiently shared with any number of other computers (the clients) on request. All web browsers function as clients that request information from websites (servers).
Numerous web browser clients can request data from the same website. Requests can happen at all different times or simultaneously. Client-server systems conceptually call for all requests to the same site to be handled by one server. In practice, however, because the volume of requests to web servers can sometimes grow very large, web servers are often built as a distributed pool of server computers.
For websites popular in different countries around the world, this webserver pool is geographically distributed to help improve the response time to browsers. If the server is closer to the requesting device, the time it takes to deliver the content is faster than if the server were further away.

Network Protocols for Web Browsers and Servers

Web browsers and servers communicate using TCP/IP. Hypertext Transfer Protocol is the standard application protocol on top of TCP/IP supporting web browser requests and server responses.
Web browsers also rely on DNS to work with URLs. These protocol standards enable different brands of web browsers to communicate with different brands of web servers without requiring particular logic for each combination.
Like most internet traffic, web browser and server connections typically run through a series of intermediate network routers.
A basic web browsing session works like this:
A person specifies a URL in a browser.
The browser initiates a TCP connection to the server or server pool (using port 80, by default) through its IP address, as published in DNS. As part of this process, the browser also makes DNS lookup requests to convert the URL to an IP address.
After the server completes the acknowledgment of its side of the TCP connection, the browser sends HTTP requests to the server to retrieve the content.
After the server replies with content for the page, the browser retrieves it from the HTTP packets and displays it accordingly. Content can include embedded URLs for advertising banners or other external content, which in turn triggers the browser to issue new TCP connection requests to those locations. The browser may also save temporary information, called cookies, about its connections to local files on the client computer.
Any errors encountered during the request for the content might appear as HTTP status lines.
Ok so thats basically everything you need to know about client-side and their protocols
I did this with some help from https://www.quora.com/How-does-a-browser-communicate-with-a-web-server and https://www.lifewire.com/web-browsers-and-web-servers-communicate-817764
You can email me at: mabadejedaniel1@gmail.com
Github: https://github.com/DanielMabadeje/