The essential news about content management systems and mobile technology. Powered by Perfect Publisher and XT Search for Algolia.
The News Site publishes posts to the following channels: Facebook, Instagram, Twitter, Telegram, Web Push, Tumblr, and Blogger.
Lawman is a Pest PHP plugin that makes adding arch tests to your application for your API integrations easy, with a set of Saloon Expectations!
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>This weekend I worked on something new and shiny for SaloonPHP. I'd like to introduce you to Lawman.
— Jon Purvis (@JonPurvis_) February 14, 2024
Lawman is a @pestphp plugin that makes adding arch tests to your application for your API integrations easy, with a set of Saloon Expectations!https://t.co/WUIGnHriNo
✨🤠
It is already possible to write architecture tests for Saloon with PestPHP, but Lawman aims to make it quicker to write and easier to read. Take this example of a connector arch test with and without Lawman:
// Without Lawman
test('connector')
->expect('App\Http\Integrations\Integration\Connector')
->toExtend('Saloon\Http\Connector')
->toUse('Saloon\Traits\Plugins\AcceptsJson')
->toUse('Saloon\Traits\Plugins\AlwaysThrowOnErrors');
// With Lawman
test('connector')
->expect('App\Http\Integrations\Integration\Connector')
->toBeSaloonConnector()
->toUseAcceptsJsonTrait()
->toUseAlwaysThrowOnErrorsTrait();
You can see examples and a complete list of expectations available in Lawman by checking out the plugin documentation page in the Saloon docs.
The post Add Architecture Tests to Saloon API Integrations with Lawman appeared first on Laravel News.
Join the Laravel Newsletter to get all the latest Laravel articles like this directly in your inbox.
Read more https://laravel-news.com/lawman-saloon-arch-tests
In the last few weeks, our team here at WordPress.com has rebuilt developer.wordpress.com from the ground up. If you build or design websites for other people, in any capacity, bookmark this site. It’s your new home for docs, resources, the latest news about developer features, and more.
Rather than creating a unique, custom theme, we went all-in on using Twenty Twenty-Four, which is the default theme for all WordPress sites.
That’s right, with a combination of built-in Site Editor functionalities and traditional PHP templates, we were able to create a site from scratch to house all of our developer resources.
Below, I outline exactly how our team did it.
The developer.wordpress.com site has existed for years, but we realized that it needed an overhaul in order to modernize the look and feel of the site with our current branding, as well as accommodate our new developer documentation.
You’ll probably agree that the site needed a refresh; here’s what developer.wordpress.com looked like two weeks ago:
Once we decided to redesign and rebuild the site, we had two options: 1) build it entirely from scratch or 2) use an existing theme.
We knew we wanted to use Full Site Editing (FSE) because it would allow us to easily use existing patterns and give our content team the best writing and editing experience without them having to commit code.
We considered starting from scratch and using the official “Create Block Theme” plugin. Building a new theme from scratch is a great option if you need something tailored to your specific needs, but Twenty Twenty-Four was already close to what we wanted, and it would give us a headstart because we can inherit most styles, templates, and code from the parent theme.
We quickly decided on a hybrid theme approach: we would use FSE as much as possible but still fall back to CSS and classic PHP templates where needed (like for our Docs custom post type).
With this in mind, we created a minimal child theme based on Twenty Twenty-Four.
@wordpress/create-block
We initialized our new theme by running npx
@wordpress/create-block@latest wpcom-developer
.
This gave us a folder with example code, build scripts, and a plugin that would load a custom block.
If you only need a custom block (not a theme), you’re all set.
But we’re building a theme here! Let’s work on that next.
First, we deleted wpcom-developer.php
, the
file responsible for loading our block via a plugin. We also added
a functions.php
file and a style.css
file with the expected syntax required to identify
this as a child theme.
Despite being a CSS file, we’re not adding any styles to the
style.css
file. Instead, you can think of it
like a documentation file where Template:
twentytwentyfour
specifies that the new theme we’re creating
is a child theme of Twenty Twenty-Four.
/*
Theme Name: wpcom-developer
Theme URI: https://developer.wordpress.com
Description: Twenty Twenty-Four Child theme for Developer.WordPress.com
Author: Automattic
Author URI: https://automattic.com
Template: twentytwentyfour
Version: 1.0.0
*/
We removed all of the demo files in the “src” folder and added two folders inside: one for CSS and one for JS, each containing an empty file that will be the entry point for building our code.
The theme folder structure now looked like this:
The build scripts in @wordpress/create-block
can
build SCSS/CSS and TS/JS out of the box. It uses Webpack behind the
scenes and provides a standard configuration. We can extend the
default configuration further with custom entry points and plugins
by adding our own webpack.config.js
file.
By doing this, we can:
theme.json
), but our developer
documentation area of the site uses a custom post type and page
templates that require CSS.*.asset.php
files. Without this, an empty JS file will
be generated for each CSS file.Since the build process in WordPress Scripts relies on Webpack, we have complete control over how we want to modify or extend the build process.
Next, we installed the required packages:
npm install path webpack-remove-empty-scripts --save-dev
Our webpack.config.js
ended up looking similar to
the code below. Notice that we’re simply extending the
defaultConfig
with a few extra properties.
Any additional entry points, in our case src/docs
,
can be added as a separate entry in the entry
object.
// WordPress webpack config.
const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
// Plugins.
const RemoveEmptyScriptsPlugin = require( 'webpack-remove-empty-scripts' );
// Utilities.
const path = require( 'path' );
// Add any new entry points by extending the webpack config.
module.exports = {
...defaultConfig,
...{
entry: {
'css/global': path.resolve( process.cwd(), 'src/css', 'global.scss' ),
'js/index': path.resolve( process.cwd(), 'src/js', 'index.js' ),
},
plugins: [
// Include WP's plugin config.
...defaultConfig.plugins,
// Removes the empty `.js` files generated by webpack but
// sets it after WP has generated its `*.asset.php` file.
new RemoveEmptyScriptsPlugin( {
stage: RemoveEmptyScriptsPlugin.STAGE_AFTER_PROCESS_PLUGINS
} )
]
}
};
In functions.php
, we enqueue our built assets and
files depending on specific conditions. For example, we built
separate CSS files for the
docs area of the site, and we only enqueued those CSS files for
our docs.
<?php
function wpcom_developer_enqueue_styles() : void {
wp_enqueue_style( 'wpcom-developer-style',
get_stylesheet_directory_uri() . '/build/css/global.css'
);
}
add_action( 'wp_enqueue_scripts', 'wpcom_developer_enqueue_styles' );
We didn’t need to register the style files from Twenty Twenty-Four, as WordPress handles these inline.
We did need to enqueue the styles for our classic, non-FSE templates (in the case of our developer docs) or any additional styles we wanted to add on top of the FSE styles.
To build the production JS and CSS locally, we run npm run
build
.
For local development, you can run npm run start
in
one terminal window and npx wp-env start
(using the wp-env package) in another to start a
local WordPress development server running your theme.
While building this site, our team of designers, developers, and content writers used a WordPress.com staging site so that changes did not affect the existing developer.wordpress.com site until we were ready to launch this new theme.
theme.json
Twenty Twenty-Four has a comprehensive theme.json
file that defines its styles. By default, our hybrid theme inherits
all of the style definitions from the parent (Twenty Twenty-Four)
theme.json
file.
We selectively overwrote the parts we wanted to change (the color palette, fonts, and other brand elements), leaving the rest to be loaded from the parent theme.
WordPress handles this merging, as well as any changes you make in the editor.
Many of the default styles worked well for us, and we ended up
with a compact theme.json
file that defines colors,
fonts, and gradients. Having a copy of the parent theme’s
theme.json
file makes it easier to see how colors are
referenced.
You can change theme.json
in your favorite code
editor, or you can change it directly in the WordPress editor and
then download the theme files from
Gutenberg.
Why might you want to export your editor changes? Styles can then be transferred back to code to ensure they match and make it easier to distribute your theme or move it from a local development site to a live site. This ensures the FSE page templates are kept in code with version control.
When we launched this new theme on production, the template files loaded from our theme directory; we didn’t need to import database records containing the template syntax or global styles.
Global styles are added as CSS variables, and they can be
referenced in CSS. Changing the value in theme.json
will also ensure that the other colors are updated.
For example, here’s how we reference our “contrast” color as a border color:
border-color: var(--wp--preset--color--contrast);
header.php
and
footer.php
?Some plugins require these files in a theme, e.g. by calling
get_header()
, which does not automatically load the
FSE header template.
We did not want to recreate our header and footer to cover those cases; having just one source of truth is a lot better.
By using do_blocks()
, we were able to render our
needed header block. Here’s an example from a header template
file:
<head>
<?php
wp_head();
$fse_header_block = do_blocks( '<!-- wp:template-part {"slug":"header","theme":"a8c/wpcom-developer","tagName":"header","area":"header", "className":"header-legacy"} /-->' );
?>
</head>
<body <?php body_class(); ?>>
<?php
echo $fse_header_block;
Check out our new-and-improved developer.wordpress.com site today, and leave a comment below telling us what you think. We’d love your feedback.
Using custom code and staging sites are just two of the many developer features available to WordPress.com sites that we used to build our new and improved developer.wordpress.com.
If you’re a developer and interested in getting early access to other development-related features, click here to enable our “I am a developer” setting on your WordPress.com account.
Read more https://wordpress.com/blog/2024/02/29/new-developer-home/
Signature Tech Studio's Laravel JWT package makes it easy to generate, consume, and protect routes with JWT tokens in Laravel. This package wraps the lcobucci/jwt and provides the following benefits on top of that package, specifically for Laravel:
JWT
facade with helper methods to quickly generate
and parse tokens.aud
, iss
, and exp
.You can also build tokens fluently with ease, using the provided
JWT
facade:
// Generate a token that will expire in an hour
$jwt = JWT::get('token-id', ['anything' => 'here'], now()->addMinutes(60));
// Fluently create a JWT
$token = JWT::setId('my-token-id')
->lifetime(3600)
->signWith('custom-signing-key-with-256-bits')
->issuedBy("my-app")
->permittedFor("receiving-app")
->withClaim('myclaim', 'any value')
->getToken()
->toString();
On the request side, you can parse and validate tokens, retrieve claims, and validate them via a provided route-specific JWT middleware. See the readme for use-cases and full details.
You can get started with this package on GitHub at stechstudio/laravel-jwt. You can install this package via composer with the following command:
composer require stechstudio/laravel-jwt
The post Protect Routes with JWT Tokens Using This Package for Laravel appeared first on Laravel News.
Join the Laravel Newsletter to get all the latest Laravel articles like this directly in your inbox.
Read more https://laravel-news.com/stechstudio-laravel-jwt
The Laravel team released v10.46 this week with new Enum validation methods, incrementing a rate limiter by a custom amount, Conditionable Enum validation rules, and more:
@Anton5360 contributed two new methods to the
Enum
validation rule when you don’t expect all enum
cases to be valid:
Rule::enum(ServerStatus::class)
->only([ServerStatus::Pending, ServerStatus::Active]);
Rule::enum(ServerStatus::class)
->except([ServerStatus::New]);
A status enum is a perfect example of where these methods might
be practical: after a record status moves away from
New
, you’ll likely not want to allow a record to
return to that status again. Another example from the pull request
description is once a shipment status is shipped
,
you’ll only allow delivered
, cancelled
,
or rejected
.
Sebastien Armand contributed the ability to increment a rate limit value by a custom amount:
Sometimes a rate limit doesn't map directly to an increase of 1 at a time. Some examples would be:
- a limit on bandwidth used
- a limit on # of updates across batch calls where each call could mean multiple "hits"
- a limit on time spent on some operations
Here’s an example of how you can use the
increment()
method to increase the total by a custom
amount:
use Illuminate\Support\Facades\RateLimiter;
RateLimiter::increment('send-message:'.$user->id, amount: 5);
See Manually Incrementing Attempts in the documentation for details.
Michael Nabil contributed the ability to use
the Conditionable
trait with the
Rule::enum()
validation rule:
Rule::enum(PostStatus::class)
->when(
auth()->user()->is_admin,
fn ($rule) => $rule->only([PostStatus::APPROVED]),
fn ($rule) => $rule->only([PostStatus::PADDING]),
);
You can see the complete list of new features and updates below and the diff between 10.45.0 and 10.46.0 on GitHub. The following release notes are directly from the changelog:
Conditionable
in enum rule by @michaelnabil230 in https://github.com/laravel/framework/pull/50257The post Increment a Rate Limiter by a Custom Amount in Laravel 10.46 appeared first on Laravel News.
Join the Laravel Newsletter to get all the latest Laravel articles like this directly in your inbox.
Read more https://laravel-news.com/laravel-10-46-0
There are currently very few options for individual users to control how their content is used for AI training, and we want to change that. That’s why we’re launching a new tool that lets you opt out of sharing content from your public blogs with third parties, including AI platforms that use such content for training models.
The reality is that AI companies are acquiring content across the internet for a variety of purposes and in all sorts of ways. We will engage with AI companies that we can have productive relationships with, and are working to give you an easy way to control access to your content.
We’re also getting ahead of proposed regulations around the world. The European Union’s AI Act, for example, would give individuals more control over whether and how their content is utilized by the emerging technology. We support this right regardless of geographic location, so we’re releasing an opt-out toggle and working with partners to ensure you have as much control as possible regarding what content is used.
Here’s how to opt out of sharing:
The new toggle can be found in Settings → General → privacy section. Or, you can click here: https://wordpress.com/settings/general.
We already discourage AI crawlers from gathering content from WordPress.com and will continue to do so, save for those with which we partner. We want to represent all of you on WordPress.com and make sure that there are protections in place for how your content is used. As part of that, we have added a setting to opt out of sharing your public site content with third parties. We are committed to making sure our partners respect those decisions.
Read more https://wordpress.com/blog/2024/02/27/more-control-over-the-content-you-share/
Page 10 of 1302