Upgrade and redesign limitations

You might see limitations from the current technology and team that you have, saying that. Let's analyze the Adobe Commerce infrastructure.

The image below shows the Adobe Commerce / Magento Cloud architecture by branches and environments. As you can see, we have different branches that allow merchants and development teams to have multiple validations running. It doesn't need to have all environments enable, you can have your developers working locally. The developer doing the QA, merging, and adjustments to push to one of the environments in Magento Cloud. You can even call them "upgrade" and "redesign" environments.

If you face issues to have changes in parallel in your team, I highly recommend you to look into the Git Flow strategy. It's a very good way to have your team working in parallel without many code conflicts.

Strategical plan

You need to analyze your current scenario, but I will share a simple plan that might help you not start from scratch. Let's start talking about the redesign, you need to measure your capacity vs effort needed to allocate more or fewer developers to some tasks. The upgrade might have the same analyses.

Let's say you have 4 developers working with the redesign, on different pages. Probably you might have more than 2 developers working with the upgrade.

An easy formula to measure the number of devs required to do the extra verifications will be 4 x 2 = 8. Then get the 8 and remove the total of devs planned, so it will be 8 -- 6 = 2. It means that you might be able to predict at least 2 developers for QA, code review, and overview the implementations. You might have a CTO or TA (Technical Architect) who is going to be a final advisor of the project heath.

Linus Torvalds created GIT for this purpose, our part is to plan how to use the tools available in a way that might fit with the current scenario.

As a technical architect, my main goals during this whole process are to measure and reduce risks, predict scenarios, validate and approve approaches. Let me know how will be your next project!

Disclaimer: I prefer PWA, I love the benefits that it provides to customers and merchants. I want to show what agencies and developers won't tell you about the experience working with PWA that they had. Some things will be hidden from you but will impact a lot your business decisions. The best method for anyone to apply PWA is when it wasn't a blind decision.

Goal: I want to show you Technical Architect, developers or merchants how to identify the differences between PWA and Headless, not a PWA vs Headless because they aren't opposites, you might have PWA with or without headless architecture.

The seductive world of PWA 😍

When you hear about PWA, everyone will share their good points. You might hear it in a such manner, that seems like there no reason why you're not on it now. It's faster, cheaper, prettier and you won't have any problems anymore. The real silver bullet already exists and you're missing out. Ok, ok, telling like this you know it's not true, but when a developer or agency that usually has the more technical experience and shows many examples faster than your current store, then it feels like it's going to solve all the problems.

It's very usual to see as a sales argument numbers like these below.

• 68% increase in mobile traffic
• 15-fold improvement of load and installation speed
• 25-times reduced use of device storage
• 52% average conversion increase
• 78% average session increase
• 137% engagement increase
• 42.86% lower bounce rate when compared to that of mobile websites
• 133.67% increase in page views

The main advantages are true? 🤔

Usually when I go deep into the analyses made they aren't reporting the real truth. The words are true, but the intentional feeling looking at it, it's not. We didn't see the entire scenario to have been prepared to make a decision based on someone's words; Most of the time who sells it's hiding the bad points for a reason.

I don't believe in taking a decision alone. Without explain to the client and evaluate with them if it makes sense to their business. So, let's cover some of the main points.

1. Low Development Costs 🤑

PWAs do not require different versions for various devices; a single progressive app meets the requirements of all endpoints on which it operates. It significantly reduces of efforts that developers provide, and as a result, the cost to create a PWA decrease. The cost is three or four times lower than that of a native mobile app.

⚠️ What to consider

• If you don't have or you're not planning to have a mobile app soon, it doesn't make sense to consider. The cost of development reduces just when you have to maintain Web / Android / IOS vs PWA.
• If you just have a web store to maintain the maintenance cost is going to increase.
• 50% of your application will be running into another application. It means that if you use a Shopify or Adobe Commerce store (Magento Commerce) and you usually install apps that change something in the frontend, like apps and modules that improve the customer experience as soon as you install them, forget it, a developer most customizes the 50% of your store that's not you Shopify or Magento store anymore, but a PWA technology running in another server. It usually represents more time to implement something and more money invested to customize 100% of those apps that you usually just have to install.
• The new 50% custom part of your project will be in another language, probably Vue, React, or Angular. Probably your devs aren't familiar with these technologies, since they aren't not using them now to develop your store.

2. App-Like Experience 📱

Progressive web applications (a.k.a PWA) provide an advanced user experience by combining the look and feel of mobile applications and the best of website performance. They have the design and settings that are very similar to those of native mobile software. Regardless of technologies, tools, and frameworks on which PWAs are developed, they provide the same user experience as native mobile apps do, and it is considered to be superior to that of websites.

At the same time, they have the same speed, responsiveness, and comprehensive capabilities as websites with database access and automatic data. As a result, search engines index them, which is why systems such as Google or Bing can find PWA pages. When compared to mobile software that keeps its internal data only for its own use, the pages of these applications can be found on the internet, which may have a favourable impact on the number of page views.

⚠️ What to consider

• There are many PWA capabilities to match the same experience of a mobile app, each PWA solution offers its own possibilities, and it comes to the agency of developer dedicate more time to implement them, 99% of the PWA implementations that I've seen, just implemented the most basic features.
• This is unbelievable but there are companies that sell PWA as Headless then when the project is launched, the project is headless and the experience is not PWA, it doesn't even pass in the Google PWA validation tool.
• If you don't track your KPIs you will have the costs and complexity of headless PWA applications but not the advantages that paid for.

3. Fast Installation 🔥

Unlike regular mobile applications, PWAs do not require a long and complex installation process, which significantly improves user experience. Users just download an app, quickly and directly to their devices, and they do not need to go to the App Store or Google Play. It streamlines the procedure and significantly reduces user abandonment. After users have downloaded an app, they can access it via a desktop icon.

Some browsers even offer call-to-action-like teasers that prompt users to download these apps when they visit respective websites. This functionality comes built into browsers and allows the apps to enhance their credibility and reliability. As this software does not require installation on devices, users can easily access the PWA via a URL, which significantly contributes to the high shareability.

⚠️ What to consider

• If you just want the basic features of PWA, measure if the agency is overselling a whole new project attached to it.
• Basic PWA features might be achieved in a couple of days of work, but migration from Magento 2 to a Magento 2 headless structure might take a couple of months.

4. Better Performance 🚀

PWAs cache and serve text, images and other content in a specific, efficient manner, which enables them to operate like websites and significantly improves the running speed. Along with quick operation, impeccable performance is another attribute that has an impact on user experience and conversion rates.

Retailers and content providers should adopt this type of software as it enables a more positive user experience than mobile apps by improving retention and customer loyalty.

⚠️ What to consider

• There are many projects that migrated to PWA aiming performance, and the final result was a slower Google Page Speed or GTMetrix ranking and even worst SEO.
• The analyses if essential to define the performance KPIs, the styles and static files and pages must be offline, but without consuming time of the first rendering.
• In general, make sure if you have the possibility of spending 500x less time and money doing performance improvements in your current installation that would bring the same performance result to your current performance metric.

5. Platform- and Device-Agnosticism 🖥

Unlike regular applications that are very demanding on operating systems and the technical capabilities of various devices, PWAs work everywhere. A single app can satisfy the needs of various consumers and provide a uniform user experience on different endpoints. At the same time, this type of application enables cross-support to users that switch between their devices by providing them with a continuous experience. Users can access an app that has the same settings and data like that on another device.

This fact also significantly contributes to business automation, as companies that rely on PWAs know that the software their employees use performs seamlessly regardless of the platform or app version. Also, PWAs are highly responsive to various form factors, as they adapt properly to various screen sizes.

⚠️ What to consider

• Your store won't be responsive just because you migrate to PWA, it's something that might be in place today.

6. No Updating Issues 🤩

PWAs have specific functionality that allows them to update automatically, without notifying users and bothering them with permission requests. These apps update themselves every time when users visit them, thus eliminating the need to download batch changes and install them. They just provide a renewed look with no human participation.

However, some of the producers of progressive apps send push notifications to users to inform them about the arrival of a new update. All the same, producers have full control of the information and content, to which users have access.

⚠️ What to consider

• If you have an app today you know that it's a huge challenge. Basically, it's the same web experience, you deployed it, it's there for everyone.
• Make sure you have the right "cache" invalidation to different kinds of pages and files. Styles might be saved in the client machine for more time than structural files.

7. Seamless Offline Operation 📡

The capability to operate offline or in compromised networks makes PWAs much more convenient than websites. Built-in service workers cache important progressive web apps' features and information automatically, which eliminates the necessity to download it and allows users to access it without an internet connection.

It is based on the saving of information that users previously accessed, for example, pages. If they try to open those that they have not visited online, an app can show a custom offline page. This capability is crucial for retailers, as it allows them to prevent users from abandoning their catalogs and enhances customer retention.

⚠️ What to consider

• Make sure you make the offline content be saved in the client's device during the first access. Check if it won't be requested from the server in the subsequent pages.
• Dynamic contents might be loaded via AJAX. All public static content of your store will be saved to everyone but the dynamic content will be distributed differently.

8. No Dependence on App Distribution Services 🍎

Usually, app distribution services, such as the App Store, Google Play or Microsoft Store, set high requirements to software that is included in their databases. Meeting their requirements may become quite a time- and effort-consuming process. Also, in some cases, services remove applications from databases without notice if a company fails to meet some of the requirements. So, PWAs allow producers to avoid complex reconciliation procedures as they do not need to be stored in similar services.

⚠️ What to consider

• You might want to push your PWA app in the Apple and Google App stores, it will help you to achieve a bigger audience.

9. Push Notification Functionality ⭐️

Like native mobile applications, PWAs have access to device-specific functionality, such as push notifications. This capability can be performed in various ways and allows companies to make the best use of content advertising.

Why are push notifications especially efficient when it comes to PWAs? According to some statistical data, almost 60% of users allow their progressive applications to send them notifications, which significantly increases opportunities to promote products or services. Moreover, these notifications are displayed on the screens of mobile devices, which is why there is a high probability that they attract users' attention, especially when compared to email newsletters, blog entries or posts in social networks.

In such a way, a company can better access its target audience, and chances are, the audience will respond. Another valuable outcome is that these bouncing notifications, along with app icons on device desktops, considerably add to brand recognition, as they allow a business to draw attention to itself. However, users that have numerous applications installed on their mobile devices and that allow a great number of them to send notifications risk making their digital experiences cluttered.

⚠️ What to consider

• Most of the time that's a third-party system in the background that is going to handle it for you, have in mind that you might not need a PWA for it.

10. Enhanced Security 👮‍♀️

PWAs rely on HTTPS to provide data safety and minimize the risk of security issues, as this protocol allows to preclude snooping and content tampering. Also, the applications take advantage of Web Bluetooth technology that includes certain security capabilities.

⚠️ What to consider

• More security is completely relative, you might have even less security depending on how the structure was made.
• It seems to be a 100% guarantee by migrating to PWA but it's not.

My thoughts

I love web development and the power of PWA capabilities, I truly believe that PWA is the future and everyone can take parts of its advantages to improve their customer experience. What I don't like is when someone sells some PWA to merchants without telling the points to consider, it results in frustration, huge cost and the client thinks that PWA is what has been delivered by the agency and not what it really is. An awesome method to improve your customer experience.

Note: if you're new to Next.js check out this tutorial!

SSG

For a statically generated Next.js app, you'll first need to edit your package.json file. You'll need to change your build to next build && next export instead of just next build.

"scripts": {
  "dev": "next dev",
+ "build": "next build && next export",
  "start": "next start"
},

SSR

You don't need to change anything in your package.json for a server-side rendered app! Just keep the one that was generated by create-next-app.

Hybrid SSG + SSR

If you have an app with both SSR and SSG pages, also keep the default package.json, same as a fully SSR app!

For Both

Then, create a repository on your git provider of choice, and push your code to it.

1. Create an AWS account if you don't already have one.

2. Navigate to the Amplify Console

3. Click on the orange connect app button.

4. Choose GitHub in the From your existing code menu, and click continue

1. Type in the name of your GitHub repo you just created (it should autofill!) and then click next

1. The build settings will auto-populate, and so you can just click next on the Configure build settings
2. Click Save and deploy.

Pricing

Behind the scenes, Amplify creates AWS resources used to deploy your app -- first an Amazon S3 bucket to store your app's static assets, then an Amazon CloudFront to serve your app itself, finally a Lambda@Edge function to SSR pages. The links to each service in this paragraph leads to info about the pricing for it.

Multi-branch Deployments

In order to deploy multiple branches to AWS Amplify, you can click the orange "Connect branch" button on the Amplify Console page for your app. So, if you want to test deployments of features before they go live to the main branch, you can do so in clicks!

Pull Request Previews

You can also enable automatic pull request preview deployments. This will enable Amplify to deploy a preview of each pull request to a project so that you can click a link and see what the pull request does to the site!

First click on previews on the left side bar.

Then, click Enable previews.

Add a Custom Domain

You can also connect your domain name to your site by visiting Domain management and then add domain -- you'll see instructions for different domain providers or be able to buy one through Amazon Route53.

Conclusion

These are just some of the things you can do when you deploy an app to AWS Amplify Hosting! There are also ways to add testing, monitoring, custom headers, access control and more. I hope this guide was helpful for those of you looking to deploy a Next.js app to Amplify.

Downgrade Composer

The first thing to check is the versions available to you, running this command below you will be able to see and select which version you want to migrate to.

brew log composer

Downgrade Composer with Brew on macOS

Then install Composer and change the version, doing the downgrade directly via Composer command.

brew install composer
composer self-update 1.10.15

What’s the Composer purpose

Composer is an application-level package manager for PHP that provides a standard format for managing dependencies of PHP software and required libraries. Composer is strongly inspired by Node.js package manager npm, and the Ruby one called bundler.

You can run Composer from the command line and installs dependencies. It also allows users to install PHP applications that are available on Packagist, using the main repository containing available packages.

Thanks!

If you or your team is struggling with your development workflow using Composer, please don’t hesitate to let me know. We might be able to evolve your development process by seeing how your processes are set up.

This post was a question and answer that I created in the Apple StackExchange.

Magento Cloud panel

When you access the main project panel you might see the gear on the left side of the screen, right after the project name.

You might see in the user tab an add button, entering the user email, you will send an invite.

If you don't know the right permission, you can consult the table of restrictions and descriptions in this post.

For a project administrator account, select Super User. This role provides Admin rights to all settings and environments. If not selected, the account has only view options for all project environments.\ Select permissions per specific environment (or branch) in the Integration environment:

• No access
• Admin (change settings, execute an action, merge code)
• Contributor (push code), or Reader (view only)

When you add active environments, you can modify permissions per user.

Assign project-level roles

Magento CLI Commands

Specifically to control your users you have these available commands.

Add a user to the project

magento-cloud user:add

Delete a user

magento-cloud user:delete

List project users

magento-cloud user:list [users]

View or change the user role

magento-cloud user:role

The following examples use the CLI to add a user, configure roles, and modify project assignments and assigned user roles.

To add a user and assign roles:

Use the CLI to add the user. magento-cloud user:add

Follow the prompts to specify the user email address, set the project and environment roles, and add the user:

Enter the user's email address: alice@example.com

Email address: alice@example.com

The user's project role can be 'viewer' ('v') or 'admin' ('a').

Project role [V/a]: a

The user's environment-level roles can be 'viewer', 'contributor', or 'admin'.

development environment role [V/c/a]: c

Summary: Email address: alice@example.com

Project role: contributor

Adding users can result in additional charges.

Are you sure you want to add this user? [Y/n]

Adding the user to the project

This operation triggers the Cloud build and deploy process, which takes your site offline until deployment completes. For production environments, we recommend completing this operation during off-peak hours to prevent service disruptions.

After you add the user, Magento sends an email to the specified address with instructions for accessing the Magento Commerce Cloud project.

The following example changes the environment-level role that is assigned to a user:

magento-cloud user:role alice@example.com --level environment --environment development --role admin

The magento-cloud list command displays all the magento-cloud CLI commands.

The mindset to perform the upgrade most of the time must be to avoid bottlenecks, mistakes and predict risks. Facing two ways to go, time and cost versus risks and tests, you’ll want to either go to the slower and safest than to the quicker and broken way.

How to detect not trustable estimation

We have exceptions to almost everything upgrading Magento 2, there are many different scenarios, but to someone who doesn't have a technical architect background, these easy points might help to do the right questions to your agency and developers.

• Template of estimation to upgrade any project or version.
• There’s no analysis phase.
• Unique overall estimation.
• There’s no timeline for each phase.
• Not predict the out-of-the-box modules and bug fixes to the next version.
• You don’t have a list of risks and critical points to take business decisions.
• The same amount of hours to upgrade a small version to a bigger version, e.g. from Magento 2.4.1 to Magento 2.4.2 and from Magento 2.3.6 to Magento 2.4.3.

A clear vision of what will be done, when, and how your team will achieve it is the goal of the doc, I personally don’t see many developers doing these analyses with clients, you will have it from a Technical Architect, Business Analytics, or Lead Developer.

Upgrading Magento 2 in 6 steps

These below are the main steps that I recommend going through to understand your customer and project.

• Getting information
• Measuring risks
• Preparing for the technical step
• Step-by-step
• Clean as you go
• Finishing and measuring

1. Getting information

The getting information step is the data that you have today about the current project setup. E.g. the number of products, customers, product variations, particularities of the project, integrations, age of the project, current Magento version…

As an initial report, we’ll obtain the most important information to proceed, but it’s essential to keep a wiki to keep your finds.

2. Measuring risks

Measuring risks is the most missed point by merchants and agencies. Here we’ll make sure we’ll measure the risk of upgrade to one version or another based on your current and future scenario, checking if we have integrations with PIM, POS, ERP, OMS, CMS, or other systems. We will check the modules bought, custom modules created, and everything that will change the estimation, risk, and cost. Most of the time we will need to discuss the topics with a business decision-maker in order to decide if something worth the risk of each approach.

3. Preparing for the technical step

You will see agencies doing the initial plan, then starting to code to do the upgrade. Doing the initial strategy and business analyses but not the technical strategy to achieve it. At this point, the lead developer and the technical architect must talk with the team and create a “getting started” documentation.

The goal is to show where to go, the technical architect and the lead developer will be the most experienced technical persons to predict bottlenecks. A simple example is when the guidance is to use the out-of-the-box feature instead of building a module or to avoid implementing something that caused issues in other projects.

4. Step-by-step

With the experience of the lead developer, technical architect, and development team we can have a step-by-step to create a feedback cycle. The goal of this strategy is to have frequent and continuous validations and deploys.

If you see complaints about it, it’s probably because they aren’t predicting possible scenarios or because they are focused on the cost and not the reliability. When we have a production store the cost of losing customer experience is higher in the long term than perform more validations.

5. Clean as you go

If you don’t have a clean routine, it’s good to set up one as soon as possible. In case you left things to be cleaned (e.g. old modules, bugs, code to refactor) this is the time to cleaning them and to set up a new cleaning routine. More important than do the cleaning is to do it constantly, it’ll be cheaper and faster for your team. I highly recommend setting up automated tests to check the code quality and the maintainability of the code.

The lead developer is the one that might take the main role in this step. The pattern to follow the tools to use and the logic of it will most of the time is created and monitored by the lead developer.

6. Finishing and measuring

When finishing an upgrade, we must follow the same approach as new implementations, which is to monitor it and measure it. Since we had a clear vision about what has been updated and the metrics already set, we might put in place tools to check the impact of the changes in the layout, performance, customer experience, or security that might change due to the new implementations. As sooner as you notice something wrong, as better and cheaper it will be to you. But if you’re not keeping an eye on it, your client must call you to complain about something broken to your team see that the implementation made 2 months ago didn’t work well.

The measurement is not applied once at the end, it’s running since the first phase continuously.

Thanks

Thank you for checking this article, if you need help to predict scenarios and measure possible risks during your integrations and new implementations please let me know!

Since one and a half year I switched again to a better Macbook Pro which allowed me to return to Docker with no problems, then I decided to keep my Valet Plus installation just to have the basic commands locally, for example, composer, CLIs from Magento Cloud, Platform.sh and others. Even though we all know that Valet Plus brings a lot of issues because of its instability, and most of the time a definitive fix might be achieved by executing a complete removal of it and reinstall it.

Remove Valet+

To remove it completely I use a gist that contains all the required commands, you can run it directly via this command below.

bash <(curl -s https://gist.githubusercontent.com/dannygsmith/5b74ba708d7bf8621c1cb6b959ece99f/raw/f1b0e88ba4e0a753b112bd2187c22bf8eaa9a234/valet-plus-destroy)

You will see this screen below at the finish.

What does it run?

The raw script is this one below in case you want to run command by command.

#!/usr/bin/env bash

#styles
VP_NONE='\033[00m'
VP_RED='\033[01;31m'
VP_GREEN='\033[01;32m'
VP_YELLOW='\033[01;33m'
VP_PURPLE='\033[01;35m'
VP_CYAN='\033[01;36m'
VP_WHITE='\033[01;37m'
VP_BOLD='\033[1m'
VP_UNDERLINE='\033[4m'

# clear the screen
clear

# cache sudo password so it will only need to be entered once.
echo -e "${VP_RED}${VP_BOLD}You may be asked to enter your password twice….${VP_NONE}"
sudo -v

# update homebrew
brew update

# upgrade homebrew formulas
brew upgrade

# cleanup mess
brew doctor
brew cleanup
brew prune

# stop Valet
#==================
valet stop
sudo valet stop
composer global remove laravel/valet
composer global remove weprovide/valet-plus
brew services stop  --all

# Uninstall dnsmasq
#==================
sudo launchctl unload homebrew.mxcl.dnsmasq.plist
brew uninstall dnsmasq
sudo rm -rf /usr/local/etc/dnsmasq.conf
sudo rm -rf /usr/local/Cellar/dnsmasq
sudo rm -rf /usr/local/opt/dnsmasq
sudo rm -rf /etc/resolver
sudo rm /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
sudo killall dnsmasq

# Uninstall nginx
#================
sudo launchctl unload homebrew.mxcl.nginx.plist
brew uninstall nginx
sudo rm -rf /usr/local/etc/nginx/
sudo rm -rf /usr/local/Cellar/nginx
sudo rm -rf /usr/local/opt/nginx
sudo rm /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
sudo killall nginx
killall nginx

# Uninstall PHP72
#================
sudo launchctl unload homebrew.mxcl.php72.plist
brew uninstall php72 php72-mcrypt php72-xdebug php72-opcache php72-apcu php72-geoip php72-intl php72-opcache n98-magerun n98-magerun2
sudo rm -rf /usr/local/etc/php
sudo rm -rf /usr/local/Cellar/php72*
sudo rm -rf /usr/local/opt/php72*
sudo rm -rf /usr/local/opt/php72
sudo rm -rf /usr/local/sbin/php*
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php72.plist
sudo killall php-fpm

# Uninstall PHP71
#================
sudo launchctl unload homebrew.mxcl.php71.plist
brew uninstall php71 php71-mcrypt php71-xdebug php71-opcache php71-apcu php71-geoip php71-intl php71-opcache n98-magerun n98-magerun2
sudo rm -rf /usr/local/etc/php
sudo rm -rf /usr/local/Cellar/php71*
sudo rm -rf /usr/local/opt/php71*
sudo rm -rf /usr/local/opt/php71
sudo rm -rf /usr/local/sbin/php*
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php71.plist
sudo killall php-fpm

# Uninstall PHP70
#================
sudo launchctl unload homebrew.mxcl.php70.plist
brew uninstall php70 php70-mcrypt php70-xdebug php70-opcache php70-apcu php70-geoip php70-intl php70-opcache n98-magerun n98-magerun2
sudo rm -rf /usr/local/etc/php
sudo rm -rf /usr/local/Cellar/php70*
sudo rm -rf /usr/local/opt/php70*
sudo rm -rf /usr/local/opt/php70
sudo rm -rf /usr/local/sbin/php*
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php70.plist
sudo killall php-fpm

# Uninstall PHP56
#================
sudo launchctl unload homebrew.mxcl.php56.plist
brew uninstall php56 php56-mcrypt php56-xdebug php56-opcache php56-apcu php56-geoip php56-intl php56-opcache n98-magerun n98-magerun2
sudo rm -rf /usr/local/etc/php
sudo rm -rf /usr/local/Cellar/php56*
sudo rm -rf /usr/local/opt/php56*
sudo rm -rf /usr/local/opt/php56
sudo rm -rf /usr/local/sbin/php*
sudo rm /Library/LaunchDaemons/homebrew.mxcl.php56.plist
sudo killall php-fpm

# Uninstall Mysql
#================
brew uninstall mysql
brew cleanup
sudo rm /usr/local/my.cnf
sudo rm /usr/local/etc/my.cnf
sudo rm /usr/local/mysql
sudo rm -rf /usr/local/var/mysql
sudo rm -rf /usr/local/mysql*
sudo rm ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
sudo rm -rf /Library/StartupItems/MySQLCOM
sudo rm -rf /Library/PreferencePanes/My*
sudo rm -rf /usr/local/Cellar/mysql
sudo rm -rf /usr/local/var/mysql

launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist
rm ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

rm -rf ~/Library/PreferencePanes/My*
sudo rm -rf /Library/Receipts/mysql*
sudo rm -rf /Library/Receipts/MySQL*
sudo rm -rf /private/var/db/receipts/*mysql*
sudo killall mysqld

# Uninstall Valet
#================
brew uninstall mailhog
brew uninstall redis
sudo launchctl unload homebrew.mxcl.mailhog.plist
sudo launchctl unload homebrew.mxcl.redis.plist
sudo rm /Library/LaunchDaemons/homebrew.mxcl.*
sudo killall mailhog
sudo killall redis

sudo rm -rf ~/.valet
sudo rm -rf ~/.composer/vendor/weprovide/
brew services stop  --all

# remove composer from path
before='export PATH="$PATH:$HOME/.composer/vendor/bin"'
after=''
sed -i  "s#${before}##g" ~/.bash_profile

# update homebrew
brew update
# upgrade homebrew formulas
brew upgrade
# cleanup mess
brew doctor
brew cleanup
brew prune

echo " "
echo -e "${VP_GREEN}${VP_BOLD}user brew services list to see if any services are running${VP_NONE}"
brew services list

echo " "
echo -e "${VP_GREEN}${VP_BOLD}use ps to see if any process's are running${VP_NONE}"
ps  aux | grep DesktopServer.app       | grep -v grep| head -1
ps  aux | grep "Local by Flywheel.app" | grep -v grep| head -1
ps  aux | grep -i "xamp"               | grep -v grep| head -1
ps  aux | grep -i "mamp"               | grep -v grep| head -1
ps  aux | grep dnsmasq                 | grep -v grep| head -1
ps  aux | grep nginx                   | grep -v grep| head -1
ps  aux | grep php                     | grep -v grep| head -1
ps  aux | grep mysql                   | grep -v grep| head -1

echo -e "${VP_RED}${VP_BOLD}REBOOT NOW BEFORE YOU RUN THE INSTALL${VP_NONE}"

Valet vs. Valet+

Valet+ is a third-party fork of Laravel Valet. Valet+ adds functionality to Valet with the goal of making things even simpler and faster. We are very grateful to the Laravel team for providing the base that we built Valet+ on. Since this is a fork we'll pull in changes from the original Valet regularly as they are released.

Some of the documentation in this readme was taken from the Valet website and provided here for convenience so that you can read this document and know about all features provided. The original documentation can be found here: laravel.com/docs/valet.

Since Valet+ is intended to replace Valet, it still uses the same valet command-line name. Any changes in its interface are documented below.

Why Valet/Valet+?

Valet+ configures your Mac to always run Nginx in the background when your machine starts. Then, using DnsMasq, Valet+ proxies all requests on the *.test domain to point to sites installed on your local machine.

In other words, a blazing fast development environment. Valet+ provides a great alternative if you want flexible basics or prefer extreme speed.

Differences from Valet

Here are a few key differences compared to the original Valet:

• PHP version switch
• Xdebug (on/off mode)
• PHP extensions (mcrypt, intl, opcache)
• Optimized PHP configuration using opcache
• MySQL (with optimized configuration)
• Redis
• Elasticsearch (optional)

To install the TTFB Terminal you just need to run the command below.

bash <(curl -s https://raw.githubusercontent.com/rafaelstz/ttfb-terminal/master/setup-ttfb)

Why?

You can use this tool to check the server response and detect some kind of issues, for example:

• Network issues
• Dynamic content creation
• Web server configuration
• Amount of traffic

What's TTFB?

According to KeyCDN. TTFB, which stands for time to the first byte, is the amount of time it takes from when a client makes an HTTP request to it receiving its first byte of data from the webserver. TTFB is an important aspect of website optimization since the faster the TTFB, the faster the requested resource can start being delivered to the browser.

The time to the first byte is made up of three separate components.

• The time needed to send the HTTP request
• The time needed for the server to process the request
• The time needed for the server to send back the first byte of the response to the client

Thanks!

How do you usually check the TTFB? Do you know some other alias that can easily become a tool? Let me know in the comments below.

You can install it on Linux, macOS or Windows 10, I used it in my MacOs via Homebrew, if you use Linux or macOS these descriptions below will be exactly what you need to know, on Windows you might have some headaches because you will need to install RubyInstaller for Windows or some VM.

Installing Shopify CLI ⚡️

The process to install it and configure it is very simple, as soon as you have the requirements you can set it up in minutes.

Requirements

• Shopify partner account
• Shopify development store to install and test apps
• Ruby 2.5.1+

macOS

$ brew tap shopify/shopify
$ brew install shopify-cli

Debian/Ubuntu Linux

1. Download the .deb file from the releases page
2. Install the downloaded file:

$ sudo apt install /path/to/downloaded/shopify-cli-x.y.z.deb

CentOS 8+/Fedora/Red Hat/SUSE Linux

1. Download the .rpm file from the releases page
2. Install the downloaded file:

$ sudo yum install /path/to/downloaded/shopify-cli-x.y.x.rpm

Start to use it 👨‍💻

The first step is to create our app automatically via the Shopify CLI, the CLI will ask you some questions, like what’s store that you would like to install it, which Shopify Partner account would you like to use. As soon as you have your base app created you can access the app folder and run the command to start the local server to test it.

1. Create the app in your terminal.

$ shopify create

1. Start it.

$ shopify serve

Core commands

These below are all the commands available to you to use after creating the NodeJS app like mine.

connect: Connect (or re-connect) an existing project to a Shopify partner organization and/or a store. Creates or updates the .env file, and creates the .shopify-cli.yml file.

Usage: shopify connect

create: Create a new project.

Usage: shopify create [ node | rails ]

logout: Log out of a currently authenticated partner organization and store, or clear invalid credentials

Usage: shopify logout

version: Prints version number.

Usage: shopify version

deploy: Deploy the current Node project to a hosting service. Heroku is currently the only option, but more will be added in the future.

Usage: shopify deploy [ heroku ]

generate: Generate code in your Node project. Supports generating new billing API calls, new pages, or new webhooks.

Usage: shopify generate [ billing | page | webhook ]

open: Open your local development app in the default browser.

Usage: shopify open

populate: Populate your Shopify development store with example customers, orders, or products.

Usage: shopify populate [ customers | draftorders | products ]

serve: Start a local development node server for your project, as well as a public ngrok tunnel to your localhost.

Usage: shopify serve

tunnel: Start or stop an http tunnel to your local development app using ngrok.

Usage: shopify tunnel [ auth | start | stop ]

Thank you

Let me know what do you think of this CLI if you have used it, if you had some difficulties you can check the original Shopify documentation about it.

Advantages

• Work in an environment exactly as production.

• Don’t install all the packages to all projects directly on your machine.

• Be more productive, avoiding issues and mistakes with node version or Shopify CLI version.

How to start

You just need to create these two files in your project’s root folder.

.devcontainer/devcontainer.json

{
  "name": "Node.js",
  "build": {
    "dockerfile": "Dockerfile",
    // Update 'VARIANT' to pick a Node version: 10, 12, 14
    "args": {"VARIANT": "14", "SHOPIFYCLI": "1.8.0"}
  },

  // Set *default* container specific settings.json values on container create.
  "settings": {
    "terminal.integrated.shell.linux": "/bin/bash"
  },

  // Add the IDs of extensions you want installed when the container is created.
  "extensions": ["dbaeumer.vscode-eslint"],

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  "forwardPorts": [80, 3456, 4040],

  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "npm install",

  // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
  "remoteUser": "node"
}

.devcontainer/Dockerfile

ARG VARIANT="14-buster"

FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:0-${VARIANT}

RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
    && apt-get -y install --no-install-recommends ruby

ARG SHOPIFYCLI="1.8.0"

RUN wget https://github.com/Shopify/shopify-app-cli/releases/download/v${SHOPIFYCLI}/shopify-cli-${SHOPIFYCLI}.deb \
    && sudo apt install ./shopify-cli-${SHOPIFYCLI}.deb && rm ./shopify-cli-${SHOPIFYCLI}.deb

To finish it, you just need to open your VSCode and type CMD + Shift + P, and execute the command below.

> Remote-Containers: Open Folder in Container

How Remote Containers feature works?

The Visual Studio Code Remote – Containers extension lets you use a Docker container as a full-featured development environment. It allows you to open any folder inside (or mounted into) a container and take advantage of Visual Studio Code’s full feature set. A devcontainer.json file in your project tells VS Code how to access (or create) a development container with a well-defined tool and runtime stack. This container can be used to run an application or to sandbox tools, libraries, or runtimes needed for working with a codebase.

Workspace files are mounted from the local file system or copied or cloned into the container. Extensions are installed and run inside the container, where they have full access to the tools, platform, and file system. This means that you can seamlessly switch your entire development environment just by connecting to a different container.

This lets VS Code provide a local-quality development experience — including full IntelliSense (completions), code navigation, and debugging — regardless of where your tools (or code) are located. In case you want more details about this feature, you can check the official doc.

If we try to change the Docker container configuration, it will be missed during the container reloads, in order to customize it and keep using the native Docker from WordPress you just need to access your server, create a file uploads.ini which is including your changes, and set this file as persistent, I created a file in this path below with the respective content.

Path in App: /usr/local/etc/php/conf.d/uploads.ini

Path on Host: /var/lib/docker/volumes/caprover–rafael-wp-data/uploads.ini

file_uploads = On
memory_limit = 500M
upload_max_filesize = 500M
post_max_size = 500M
max_execution_time = 600

Setting it in our CapRover, our WordPress container will be reloaded and our panel will show the new persistent directory like this image below.