DEV Community: Danilo Desole

Wordpress 403 errors

Danilo Desole — Fri, 16 May 2025 07:53:05 +0000

Ever wonder why your WordPress website suddenly starts showing you a 403 error when you try to log in to the wp-admin side? It happened to me recently, and I had to do a LOT of investigation before figuring out what was wrong. All the blog posts I found suggested the following:

Check File and Folder Permissions – Your WordPress directories should have 755 permissions, and files should be 644. You can adjust these via FTP or your hosting panel.
Inspect the .htaccess File – Sometimes, hosting providers modify this file to prevent brute-force attacks, which can inadvertently block access. Try renaming it temporarily to see if that resolves the issue.
Whitelist Your IP Address – If your host has strict security settings, you may need to whitelist your IP to regain access.
Disable Security Plugins – Some security plugins may block admin access. Try renaming the plugin folder via FTP to disable it.
Check for Malware – If your site has been compromised, malware could be restricting access. Running a security scan might help.
Contact Your Hosting Provider – If none of the above work, your host might have firewall rules or restrictions causing the issue. They should be able to assist.

None of the above worked for me, except that I did not contact my hosting provider, given that I was copying a website from another host where it was working perfectly. So what happened? The reason my WordPress website was returning a 403 error when I tried to log in to the wp-admin area lay in a database dump.

To give some background on my process, I was moving a website from one hosting provider to another. I proceeded with the usual file backup and database dump. Then, I moved the files to the new hosting and imported the database dump into the new database server. I modified the wp-config file, and then the first error occurred—WordPress was telling me that tables did not exist.

Checking the wp-config file, everything seemed correct. However, upon closer inspection, I noticed that the database prefix in my wp-config file was uppercase, while the imported table prefix was lowercase. Easy fix, I thought! I simply updated the wp-config file with the lowercase prefix.

Then, the website was able to run, I had access to the end-user front-end. However, when I accessed the wp-admin area, a 403 error occurred. After trying all the above solutions, none helped. I took another look at the database, and by chance, I noticed that in the wp-usermeta table, some rows contained the table prefix in the meta_key field!

Updating the database dump to use the uppercase prefix, re-importing it, and finally updating the wp-config file helped me fix the issue.

A few things went wrong:

PhpMyAdmin exported the database with a lowercase table prefix (why?).
I had an initial issue where WordPress was not able to find some tables in the database, and I ignored it.
I updated the wp-config file table prefix without actually modifying the database.

Let me know what you think about this article—it's my first one in this community, and I really appreciate your feedback to improve.

Cheers!

Boto3 and Python unittest.mock

Danilo Desole — Wed, 24 Apr 2024 10:30:03 +0000

I start this post by saying I'm not a professional software developer, I work mainly in IT Operations, although I write especially for IAC and small lambdas functions.

When developing a Lambda function most of the time I need to interact with AWS Services via the famous boto3 library; boto3 is a powerful library developed and maintained by AWS which provides a communication framework to interact with native AWS Cloud Services.

Every time I struggle to mock the library. I even considered using the moto stubber but, I'm not happy with what is provided. I aim to

Create a mock which can stub the original call
I want the mock to expose all the methods to check which parameters have been used during the calls, how many times it has been called, etc... all the stuff included within the Mock class

In this example, we will mock boto3 while it creates a client for RDS.

Consider the following code

import boto3


class MyRDSManager:
    def __init__(self) -> None:

        self._rds_client = boto3.client("rds")

    def delete_db_cluster_snapshot(self) -> None:
        self._rds_client.delete_db_cluster_snapshot(DBClusterSnapshotIdentifier="ABC")

    def get_snapshots(self) -> list[dict]:
        snapshots = []

        paginator = self._rds_client.get_paginator("describe_db_cluster_snapshots")
        pages = paginator.paginate(DBClusterIdentifier="MyCluster")

        for page in pages:
            page_snapshots = page.get("DBClusterSnapshots")
            for snapshot in page_snapshots:
                snapshots.append(snapshot)

        return snapshots

To test the above class I developed the following tests

import pytest
from unittest.mock import Mock, patch
from datetime import datetime

from main import MyRDSManager


@pytest.fixture(scope="function")
def prepare_mock():
    with patch("main.boto3.client") as mock_boto_client:
        # the first thing to do is to set the return_value attribute as itself
        # this will return the mock itself when the code runs `boto3.client("rds")`
        mock_boto_client.return_value = mock_boto_client

        def mock_paginate_describe_db_cluster_snapshots(*args, **kwargs):
            snapshot_type = kwargs.get(
                "SnapshotType"
            )  # get all the parameter passed to the call

            return [{
                "DBClusterSnapshots": [
                {
                    "DBClusterSnapshotIdentifier": "ABC",
                    "SnapshotCreationTime": "2024-01-01",
                    "SnapshotType": "manual",
                }
            ]}]

        mock_boto_client.get_paginator = Mock()
        mock_paginator = Mock(return_value=None)
        mock_paginator.paginate = Mock(return_value=None)
        mock_paginator.paginate.side_effect = mock_paginate_describe_db_cluster_snapshots

        mock_boto_client.get_paginator.return_value = mock_paginator

        mock_boto_client.delete_db_cluster_snapshot = Mock(return_value=None)

        my_rds = MyRDSManager()

        yield my_rds, mock_boto_client


def test_one(prepare_mock):
    mock_my_rds, mock_boto_client = prepare_mock

    mock_my_rds.delete_db_cluster_snapshot()

    mock_boto_client.delete_db_cluster_snapshot.assert_called_once_with(DBClusterSnapshotIdentifier="ABC")

    result = mock_my_rds.get_snapshots()

    assert result == [{
        "DBClusterSnapshotIdentifier": "ABC",
        "SnapshotCreationTime": "2024-01-01",
        "SnapshotType": "manual",
    }]

The first thing to notice is that we need to set the mock_boto_client.return_value to mock_boto_client, which is itself, and this will return the mock instance you are configuring when in MyRDSManager the code runs self._rds_client = boto3.client("rds"). If you don't set this MagicMock will return the default value, therefore a new MagicMock, and not what you are configuring!

Another important point to note is that we patch boto3 within the specific module being tested, rather than the general boto3 library. In other words, you should patch main.boto3.client, where main refers to the module you have written and are currently testing.

Next, configure the Mock as needed by adding methods and attributes. It's worth noting that setting a side_effect allows the mock to invoke the function specified in the side_effect, passing along all the arguments that the code supplies to the mock.

With this setup, you should be able to fulfil the initial requirements and therefore stub the original behaviour and use all the Mock-provided features.

Hope this will help you all!

Any feedback is appreciated.

Cheers

Post published also on Virtuability's website here.

Golden rules to live well in ITOps

Danilo Desole — Thu, 30 Nov 2023 14:26:08 +0000

Here I list some simple rules to live well in IT Operations, from my experience; these rules are to be taken as they are, with no warranty, and exceptions can apply.

1. No releases on Fridays

Friday is sacred and the weekend is spent with family, friends, or even just chilling out. Do not jeopardize your weekend with a Friday release.

2. Production is sacred

Do not touch the production environment, even if the option seems compelling. Copy the environment somewhere else, safe, and play with it. You would spend the same amount of time for copying the environment, to fix possible outages in production caused by your actions.

3. Make Team decisions and foster communication

Do not decide for yourself, always involve the team in your final decisions. Speak with your Team and with stakeholders, communication is at the base of early civilization and can be the game changer even nowadays.

4. In case of outages, focus on production

In case of outages focus on fixing the production environment, lower environments (dev, stage, etc...) can wait, but customers do not.

5. Do not overdo, and do not always follow your gut

Do what you are asked to do, and do not overdo tasks; this is not to be confused with "do the minimal acceptable", but is just a foster to follow your task guardrails and not do things that can lead to issues. For me following my gut sometimes leads to issues, so I also learned how to ignore it :)

AWS NLB and Client IP Preservation - How to create Security Group Rules

Danilo Desole — Mon, 23 Oct 2023 09:08:50 +0000

Have you ever created a Network Load Balancer on AWS, its target group and its target, and some security rules attached to it, to end up giving out to your browser because you couldn't reach the target?

It happened to me last week and I interestingly found out about this cool AWS feature named Client IP Preservation.

Client IP Preservation is a target group feature that allows the traffic from the Network Load Balancer to preserve the client IP. Therefore the traffic to your target will keep the IP from the original client. Disabling this option will overwrite the traffic IP with the NLB private IP (the NLB is likely to have more than one IP, it will override the traffic IP with the IP of the ENI that handles the traffic).

By default, AWS enables client IP preservation if the Target Group type is one of the following

EC2 instance (ASG, EC2 instances)
IP type, protocol UDP or TCP_UDP

This means that the only case Client IP Preservation is OFF by default is if your target type is IP and the protocol is TCP or TLS.

But what does this mean?

It means that you need to remember to allow internet public cidrs in your security group if your target is: one or more EC2 instances or any other target with type IP and protocol UDP or TCP_UDP.

Instead, if your target is of type IP and the protocol is TCP or TLS, you can simply allow traffic from the NLB private IPs. For example, if you set an ECS cluster as the target of your NLB, its tasks' security group can only contain rules that allow the NLB private IPs.

Is it any better to enable Client IP Preservation?

For target types IP + UDP/TCP_UDP and Instances (except some instance types), you cannot disable Client IP Preservation; you can though enable Client IP Preservation for target type IP + TCP/TLS. You should enable Client IP Preservation considering the following

Targets must be in the same VPC as the Network Load Balancer, and traffic must flow directly from the Network Load Balancer to the target;
Client IP preservation is not supported when using a Gateway Load Balancer endpoint to inspect traffic between the Network Load Balancer and the target;
Client IP preservation is not supported when a target group contains AWS PrivateLink ENIs or the ENI of another Network Load Balancer.
Client IP preservation has no effect on traffic converted from IPv6 to IPv4.
When you specify targets by Application Load Balancer type, the client IP of all incoming traffic is preserved by the Network Load Balancer and is sent to the Application Load Balancer.

I hope this solution proves helpful to you!
Any feedback is much appreciated!
Enjoy

Post published also on Virtuability's website here.

WordPress Flamingo GDPR

Danilo Desole — Wed, 14 Jun 2023 14:48:00 +0000

The Flamingo WordPress plugin allows you to keep track of Contact Form events. It's an excellent tool for logging every sending and creating a "history" of emails sent over time.

The only drawback is that the plugin is not GDPR compliant and lacks a feature for deleting old records.

To address this issue, I created a plugin that automatically cleans up data on your WordPress site after seven days to ensure GDPR compliance. You can find the plugin here, it deletes flamingo_inbound (contact form) records older than 7 days, and all the flamingo_contact (emails).

I hope this solution proves helpful to you!
Enjoy

Break the rules of virtualization, build Lambdas container images for any platform, from any platform, with CDK & Docker buildx

Danilo Desole — Tue, 09 May 2023 08:10:55 +0000

How often are you deploying a Lambda container image, basically a Lambda running on a Docker image, for a platform that doesn't match your localhost platform? Often I deploy functions running on ARM rather than on X86_64, this is a personal preference and it doesn't come with any massive advantage (there are online some comparison), and although my laptop is ARM-based, the CI/CD server is not :/

This is true even for GitHub Workflows which run on X86_64, rather than ARM if you don't create your custom runner.

So if you have a piece of code like the following, and you try to deploy it via a CI/CD server which is X86_64 it will fail with the error

The error

Warning: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested

exec /bin/sh: exec format error
The command '/bin/sh -c ...' returned a non-zero code: 1

The code

from aws_cdk import (    
    Stack,
    aws_lambda,
    aws_ecr_assets as ecr
)
from constructs import Construct

class LambdaMultiplatDemStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        my_function = aws_lambda.DockerImageFunction(
            self, 
            "MyDifferentPlatformFn",
            code=aws_lambda.DockerImageCode.from_image_asset(
              "."
            ),
            architecture=aws_lambda.Architecture.ARM_64
        )

The Dockerfile

FROM public.ecr.aws/lambda/python:3.8

COPY requirements.txt  .

RUN  pip3 install -r requirements.txt --target "${LAMBDA_TASK_ROOT}"
COPY my_py_app.py ${LAMBDA_TASK_ROOT}

CMD [ "my_py_app.handler" ]

This is true even for the simplest Docker image because Docker is pulling executable dependencies for your it that are not compatible with your execution platform. How to solve this issue? Thanks to Docker and CDK!

Let's start with Docker

Is not news that Docker offers the possibility to build images for a platform different than yours using buildx, to find out more just visit the official documentation link.

So first thing first, we need to check if buildx is installed on our machine; you can follow the official doc here, but if you want to simplify the process

Run docker buildx ls to list all the builders on your machine, if the output presents something similar to what is below you should be good (see the various platform available)

[panilo@fedora ~]$ docker buildx ls 
NAME/NODE DRIVER/ENDPOINT STATUS  BUILDKIT PLATFORMS
default * docker                           
  default default         running 23.0.1   linux/arm64, linux/amd64, linux/amd64/v2, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/mips64le, linux/mips64

If the output doesn't present the platform you're interested in, you need to
- run the following command docker run --privileged --rm tonistiigi/binfmt --install all
- run again the docker buildx ls command, this time the platforms available should be more

Now we can build images for other platforms, great!

Step 2: CDK

Just modify the stack to add a special platform property in the aws_lambda.DockerImageCode.from_image_asset definition

from aws_cdk import (    
    Stack,
    aws_lambda,
    aws_ecr_assets as ecr
)
from constructs import Construct

class LambdaMultiplatDemStack(Stack):

    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        my_function = aws_lambda.DockerImageFunction(
            self, 
            "MyDifferentPlatformFn",
            code=aws_lambda.DockerImageCode.from_image_asset(
              ".",
              platform=ecr.Platform.LINUX_ARM64 # Magic Switch!
            ),
            architecture=aws_lambda.Architecture.ARM_64
        )

By adding this little parameter CDK will know to use Docker's buildx build command and prepare the image for the specified platform.

We can now deploy anywhere, building anywhere :)

Please find a complete example here.

I hope this helped you,
as usual, any feedback is more than appreciated!

Cheers
Danilo

Post published also on Virtuability's website here.

Deploy a static website on AWS for FREE!

Danilo Desole — Wed, 19 Apr 2023 15:02:10 +0000

Yes, you read it right! It's possible to host a static website, for FREE, on AWS.

Before starting you need a hosted zone in Route53 for the website's domain you're deploying.

To do that we're going to deploy our static files on S3, create a CloudFront distribution, create a valid TLS certificate in ACM, and finally we'll add an alias record in Route53; let's start!

So first we need to create a CDK app, I'll not take too much time on this as there are tons of articles around the web on how to do that, therefore once you've done it we can start coding!

We'll divide the app into two stacks

One stack will create the TLS certificate;
The other stack will create an S3 bucket and the CloudFront distribution;

This is because we need to create the TLS certificate in the same region as the CloudFront distribution (us-east-1) and for some reason, CDK handles well the CloudFront distribution creation in that region, regardless if the stack defines the region or not, rather than the TLS certificate stack need a region to be specified.

So let's start by defining the stack for the TLS certificate, we need first to define a cdk_environment variable which holds info about the environment in which CDK will be executed (region and account number). For the region, we will use us-east-1 so the certificate will be compatible with CloudFront. Then we need to pass to the super constructor the env variable we just declared, and an attribute cross_region_references=True, this little one will help us to reference the certificate's ARN in the other stack.

Everything else is just CDK construct to define the TLS certificate and its validation method (in the stack below is Route 53).

class SSLCertificateStack(Stack):
    def __init__(self, scope: Construct, domain: str, **kwargs) -> None:
        cdk_environment = Environment(
            region="us-east-1", account=os.getenv("CDK_DEFAULT_ACCOUNT")
        )
        super().__init__(
            scope,
            f"SSLCertificateStack-{domain.replace('.', '-')}",
            env=cdk_environment,
            cross_region_references=True,
            **kwargs,
        )

        website_hosted_zone = HostedZone.from_lookup(
            self, "domain_hosted_zone", domain_name=domain
        )

        self.certificate = Certificate(
            self,
            "website_certificate",
            domain_name=domain,
            subject_alternative_names=[f"www.{domain}"],
            validation=CertificateValidation.from_dns(website_hosted_zone),
        )

Let's now define the other stack for S3 and the CloudFront distribution. Again we will need to define a cdk_environment variable which will hold the info on where to deploy the resources defined in the stack, including the website assets. In this scenario, we deploy in a different region than before, eu-west-1. Again we need to pass the magic cross_region_references=True to get the output from the precedent stack.

class WebsiteStack(Stack):
    def __init__(
        self, scope: Construct, domain: str, tls_certificate: Certificate, website_assets_path: str, **kwargs
    ) -> None:
        cdk_environment = Environment(
            region="eu-west-1", account=os.getenv("CDK_DEFAULT_ACCOUNT")
        )

        super().__init__(
            scope,
            f"WebsiteDeploy-{domain.replace('.', '-')}",
            env=cdk_environment,
            cross_region_references=True,
            **kwargs,
        )

        domains = [domain, f"www.{domain}"]

        website_bucket = s3.Bucket(
            self,
            "website_bucket",
            access_control=BucketAccessControl.PRIVATE,
            encryption=BucketEncryption.S3_MANAGED,
        )

        website_bucket.apply_removal_policy(RemovalPolicy.DESTROY)

        BucketDeployment(
            self,
            "website_deployment",
            destination_bucket=website_bucket,
            sources=[Source.asset(website_assets_path)],
        )

        oai = OriginAccessIdentity(self, "origin_access_identity")
        oai.apply_removal_policy(RemovalPolicy.DESTROY)

        website_bucket.grant_read(identity=oai)

        distribution = Distribution(
            self,
            "website_distribution",
            default_root_object="index.html",
            default_behavior=BehaviorOptions(
                origin=S3Origin(website_bucket, origin_access_identity=oai),
                viewer_protocol_policy=ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
            ),
            domain_names=domains,
            certificate=tls_certificate,
        )

        CfnOutput(
            self,
            "distribution_url",
            value=distribution.domain_name,
            export_name=f"DistributionDomainName-{domain.replace('.', '-')}",
        )

        CfnOutput(
            self,
            "bucket_arn",
            value=website_bucket.bucket_arn,
            export_name=f"WebsiteBuckerARN-{domain.replace('.', '-')}",
        )

Notes of attention are

an OAC (Origin Access Control) for S3 which allow requests through the CloudFront distribution
the CloudFront distribution Viewer Protocol Policy to redirect all the requests to HTTPs
the two outputs which can be used to test the website deployment (see distribution_url)

Now left to do is add two records in Route53, both pointing to the CloudFront distribution. For instance, say we're deploying example.com, we can add:

example.com
www.example.com

Now, if you want to take a look at the whole code, here is the repo :)

What is free

S3 offers the first 5 GB of data for free, if you have less than 5 GB around S3 it should be good. More info here.
CloudFront distribution offers the first tera of data out for free, see here.
AWS ACM TLS certificates are completely free, see here.

The only service you pay for is Route 53, min .50 cents per month (see here).

Happy to answer any questions, please let me know if you'd like to see more pictures and if this article is clear :)

Cheers
Danilo

AWS CDK + API Gateway and Integrations. A little guide how to.

Danilo Desole — Tue, 14 Feb 2023 16:19:32 +0000

I've been working with CDK and I think is brilliant, the way it let you define resources and infrastructure using your fav coding language is awesome, I personally use Python. Though sometimes what happens is that CDK takes over a lot of control and creates resources as it thinks is proper... Also, documentation lacks some advanced configuration.

For instance, I come across this AWS documentation page to develop a proxy to S3 using API Gateway. I thought to reproduce the same in CDK, but I faced some issues in defining the integrations.

In this post, I'm going to show how I created the API Gateway, the challenges I faced, and how I solved them, with the hope it might help you too!

So let's start from the beginning.

Defining REST APIs

To define a REST API you can use the following snippet, in a single row, in CDK, you can define a new set of REST API



my_apig = apig.RestApi(self, "ApigAndS3")

Defining Resources

Now it's time to define a couple of resources, to be clear our final goal is to create something like the following: http://myapigateway/bucketName/item where bucketName and item are placeholder the client will pass along with a request body. Whatever is passed in the body will be saved in bucketName/item. Of course, you need to own write permissions on the bucket defined by bucketName.



bucket_resource = my_apig.root.add_resource("{bucketName}")
item_resource = bucket_resource.add_resource("{item}")

Here again a couple of lines defining two resources. Awesome!

Defining the integration

Here I started to sweat, as defining the integrations per se is not complicated



bucket_integration = apig.AwsIntegration(service="s3", integration_http_method="PUT", path="{bucket}/{object}", region="eu-west-1", options=integration_options)

Is the integration_options really hard to define, considering I got the error apigateway Invalid mapping expression parameter specified: method.request.path. many, many, times... I couldn't find an answer online and even the AWS Post here added confusion.

First: what are integration options? Well in integration options you can define how API Gateway will integrate with the defined service, in particular, you can map URL/Body parameters with parameters for your integration. What we aim to do is to use the URL path parameters bucketName/item to define the S3 path where to save the request body payload.

In the AWS console, you do something like this, very far from what you do in CDK

Instead in CDK, you will define something like



integration_response = apig.IntegrationResponse(status_code="200")
integration_options = IntegrationOptions(request_parameters={        "integration.request.path.bucket":"method.request.path.bucketName",          "integration.request.path.object":"method.request.path.item",credentials_role=role, 
integration_responses=[integration_response])

As you can notice the correct path URL to be passed are integration.request.path.bucket and integration.request.path.object mapped to method.request.path.bucketName and method.request.path.item.

What really helped me is the CLI, commands



aws apigateway get-integration --rest-api-id abcd --resource-id 1234 --http-method POST

aws apigateway get-method --rest-api-id abcd --resource-id 1234 --http-method POST

Final thoughts

CDK is really cool, the documentation needs to be expanded to care also for advanced scenarios, and be extensive to describe all you can actually do.

Use the CLI when in doubt... This always helps.

The full code for this mini-POC can be found here.

Happy to answer any questions, please let me know if you'd like to see more pictures and if this article is clear :)

Cheers
Danilo

Post published also on Virtuability's website here.

How to virtualise on Apple M1

Danilo Desole — Tue, 17 Jan 2023 11:57:00 +0000

I recently got a new MacBook Pro backed by the "almost" new Apple M1 socket, it's just brilliant and the battery life it's just astonishing, I'm able to run multiple workloads, have a always-on Fedora VM, and the battery won't die before the second day.

I usually run a separated environment for my development, this allows me to keep my machine pristine (I used to do that with my previous laptop, Dell XPS 15) from dev dependencies and files that I'll never remove. In this article I'd like to show you how I virtualise on Mac and how I use VM to develop.

Please note that I'm not affiliated with any of the software/vendor below. What I'm writing is from my own experience.

Virtualisation Options

UTM

UTM is an Open Source virtualisation software able to run Linux, Windows and OSX even on Apple M1. UTM allows you to run the virtualisation as-is or to use Rosetta and emulate an intel-like processor. I really like the UI simplicity and the software itself is just made to do what's supposed to, without too many features that sometime can be overwhelm.

PRO

Free / paid for 12€ on mac store
Same features as Parallels (as much as I’m concerned)
Open Source
Offer different types of virtualisation (even with Rosetta)

CONS

Sometimes it can be challenging to create a new VM (the install process may fail if virtualisation is not set correctly)
Need at least an additional settings screen to setup the IP ranges for the created VMs
Installing Windows is really challenging as you need to basically create the ISO file (from a Windows machine...)
Graphic acceleration doesn't work well on Windows

Parallels

Parallels is a top-tier emulation software, the VM creation process is straightforward with a Wizard that guide you through all the steps, many automated. It provides a lot of customisations and options to literally unleash the real virtualisation power. This is my fav if you use virtualisation for business reason as you get extensive support with the business version.

PRO

It is straightforward and intuitive
Creation process easy
Mapping of CMD to CTRL

CONS

License is annual and expensive
Doesn’t offer that much more rather than UTM (for my daily usage)

VSCode

Now VSCode allows you to SSH into a Linux VM, then it installs a VSCode-Server and let you code on the connected machine as you were in local. Additionally, to my surprise, it also automatically set port-forwarding, therefore if you start a web-server it will automatically forward your localhost:something to you ssh-machine:something.

What I've done is

I created an SSH key and installed it on my VM
I set a static IP so it won't change on reboot
Open VSCode and install the Remote SSH extension
Connect to the VM
Happy coding!

Happy to answer any question, please let me know if you'd like to see more pictures and if this article is clear :)

Special thanks to Morten for his tips and tricks.

Cheers
Danilo

Cookiebot and Slider Revoltion

Danilo Desole — Wed, 02 Jun 2021 08:51:30 +0000

Recently I noticed an issue in my WordPress website: I had configured the CookieBot plugin, by CookieBot, to automatically block all the cookies until the user accept/reject those (more info here), and the slider (on all pages) has stopped to work.

The slider I'm mentioning is Slider Revolution by ThemePunch.

I struggled to came up with a solution, online the only proposed fix was to set the CookieBot plugin to manually block all the cookies, though using this way I needed to code a bunch of JS in order to effectively block the cookies from being downloaded to the user browser storage. Too lazy to do that!

So I investigate a little bit and I figured out that Google Fonts doesn't set cookie, but it's collecting IPs and other info (more comprehensive description here) hence CookieBot is blocking the script execution until the user explicitly accepts that its identity (IP and other stuff mentioned before) can be recorded by Big G.

Bottom of the bottle: disable Google Fonts load in Slider Revolution and load them as a separate resource, if your theme doesn't load them already.

Happy Blogging!

Develop and debug a WordPress plugin from the scratch

Danilo Desole — Wed, 28 Apr 2021 14:05:01 +0000

I had never been a PHP fan, I born as a C# developer and honestly is quite a fun and easy life with all the IDE and tools doing most of the stuff automagically.

When I started with PHP many years ago, one of the main difficulty I found was not being able to debug properly and that always affected my development decisions.

Recently I decided to get back on PHP and specifically I was interested in developing a WordPress plugin.

Here I want to share with you what I've learned and done in order to debug and properly create a simple WordPress plugin from the scratch.

We will use Laragon and VS Code.

Let's start :)

Install Laragon and WordPress on the local machine

The first thing to do is to install a web server and add a WordPress project. I used Laragon as the web server.

Download and install Laragon
Download WordPress and extract it in the Laragon project folder (e.g. C:\laragon\www)
Start Laragon
Laragon in automatic will add to the host file a reference to your project as {project_name}.test (project_name is the folder name)

In my case I extracted WordPress under a folder named wp (e.g. C:\laragon\www\wp)

Install PHP

Then we can install PHP, before doing so check the PHP version installed with Laragon, you can verify that by going in the Laragon installation folder then \bin\php, here you will find a folder named like php-7.2.19-Win32-VC15-x64 in this case 7.2.19 is the version.

We can now go to the official PHP website and download the same version as Laragon, be careful and download the Thread Safe PHP version.

Once the download ends, extract the content of the archive in a folder on your disk, I use C:\libs for all the libraries I download.

You need to add the path where you’ll extract PHP to the environment path (user environment path).

Configure VSCode to properly debug PHP

Open VS code, go to settings and check the following values

php.validate.enable true
php.validate.executablePath e.g. C:\libs\php\php.exe
php.validate.run onSave

Then install the following extensions

Install xDebug

Debugging CLI PHP Scripts

To install xDebug first we need to gather the PHP information for our local environment, to do that run php.exe -i > output this will print out, in the output file, all the info we need to proceed with the installation.

Go to xdebug.org/wizard and paste the PHP information stored in the output file, the wizard will inform you on what’re the next steps.

In my scenario I’ve

Download php_xdebug-3.0.4-7.4-vc15-x86_64.dll
Move the downloaded file to C:\php\ext (this might different, check your installation folder)
Create php.ini in the same folder as where php.exe is and add the line zend_extension = C:\php\ext\php_xdebug-3.0.4-7.4-vc15-x86_64.dll

Pretty straightforward ;)

Enable remote debugging

In the php.ini file, you just placed the zend_extension configuration, add the following lines

xdebug.mode = debug
xdebug.start_with_request = yes
xdebug.client_port = 9000

Debugging Laragon projects

Because we will debug projects deployed via Laragon we need to repeat the above configuration steps for the PHP executable installed under the Laragon folder, it’s store in the bin folder under the Laragon installation folder.

Test all together with a simple script

To test all together I’ll script a simple PHP program to output Hello World, what a fantasy eh! The goal is to run and debug the script.

Create a folder, open it in VS Code and create a simple PHP script. The folder part is important we’ll need to create a launch configuration file launch.json.

<?php
  echo "Hello World";
  echo "end";
  end();
?>

Then we can configure the debug options. Hit the debug icon, click create a launch.json file and select PHP, this will create a launch configuration file with two configurations Listen for Xdebug and Launch currently open script. Let’s see what these two configurations mean

Listen for Xdebug: this config will start listening on the specified port (usually xDebug uses port 9000). Every time you make a request with a browser to your webserver or launch a CLI script, xDebug will connect and VS code will stop on breakpoints, exceptions, etc…
Launch currently open script: this config is an example of CLI debugging, it will load and start the current script in CLI, showing all the stdout/stderr output in the debug console. The debug session will be automatically closed once the script ends.

In the end, we should see two debug configurations, in this very case we need to use the second Launch currently open script.

Done :)

Test all together with WordPress

Now let’s take a look at how we can debug a WordPress plugin, is intuitive that we need to use the Listen for Xdebug debug configuration to do that.

The simplest plugin we could try to debug is hello dolly, a built-in WordPress plugin.

I’ll start by launching my Laragon servers, this will spawn up WordPress I previously installed as a project.

Then I’ll go to my WordPress project folder/wp-content/plugins and open the hello.php file in VS Code, this is the hello-dolly plugin let’s try to debug it.

In VS Code go to the debug tab and create a new configuration, then click on Listen to Xdebug, for test reason place a breakpoint in the hello_dolly_get_lyric() return statement (line 49).

Now open a browser and navigate to your WordPress wp-admin service, as you log in the breakpoint should be hit, that is the confirmation our debug process works.

Finally, we can take care of folder-mapping this particular feature will allow us to store and work on the code not directly placed under our WordPress folder, this is crucial to avoid issues like deleting your own code or overwrite the plugin with outdated files.

Let’s copy the hello.php file in a folder somewhere else, could be your desktop, open VS Code and prepare a debug configuration, this time we need to add a little twist to map our PHP file to the one deployed server-side (on another folder on our PC, consider the procedure is valid also for a remote server if that server allows PHP debug).

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9000,
      "pathMappings": {
        "C:\\laragon\\www\\wp\\wp-content\\plugins": "${workspaceFolder}"
      }
    },
    {
      "name": "Launch currently open script",
      "type": "php",
      "request": "launch",
      "program": "${file}",
      "cwd": "${fileDirname}",
      "port": 9000
    }
  ]
}

The lines from 12 to 14 describe how VS code should map the current workspace code to the server deployed code.

Now if you run again the debug, you got to your WP instance in the wp-admin section, you should be able to debug. Consider some errors that might occur when you hit the debug button, this is because in your folder there’re no WP files and Laragon needs to load them; if that happens just start the debug session again and you should be grand. You'll be also able to deeply debug WP files.

Conclusions

Honestly, I found PHP development and debug pretty easy, I remember nightmares and high difficulty in my past it might be me, improving my skills, or better tools on the market.

Let me know what you think about this article, is my first one on this community and I really appreciate your feedback to improve.

See you soon in my next article of WordPress Pluging Developement Series.

Cheers ✌