Maravel-Framework 10.70 brings Storable Array Callables to queues (and queued events) available both in the Maravel micro-framework and Maravelith.

This is a safer alternative to serializing objects when dispatching a message to the queue because PHP Object Injection is totally avoided on unserializing the payload. PHP Object Injection allows attackers to weaponize magic methods for Remote Code Execution (RCE). While this was prevented, leaking your APP_KEY removes that prevention. By avoiding serialized objects, this vulnerability is neutralized, while also optimizing Redis and SQS payload sizes.

The feature is fully backward compatible but it can also enforce the prevention via a public constant in the \App\Application class:

namespace App; class Application extends \Laravel\Lumen\Application
{ public const FORBID_SERIALIZED_OBJECTS_IN_QUEUE = true;
}

Version 10.70 will introduce the ability to dispatch standard PHP callable arrays directly to the queue (e.g., [Service::class, 'method']).

Advantages:

• Avoids unserialize(): Completely bypasses the need to serialize and unserialize closures or full object instances. This eliminates serialization bugs, reduces execution overhead, and removes the security risks natively associated with PHP's unserialize().

• Reduced Payload Size: Only the class string and method name are stored in the queue backend (Redis, database, etc.), drastically cutting down payload size compared to serialized objects or large closures.

• Fresh Container Resolution: The queue worker instantiates the class directly through the Dependency Injection container at the exact moment of execution. This guarantees the job runs with the latest application code and avoids stale state issues caused by saving an object's state at the time of dispatch.

• No Boilerplate: Allows you to execute background logic directly from existing service classes, removing the need to create and maintain dedicated Job classes for simple operations.

  Discover more https://github.com/macropay-solu...

Version 10.69.2 patches some corner cases in validation like rules that throw exception from different reasons.

The docs have been updated.

Subject: [PATCH] Document POC https://github.com/laravel/frame... cr + add return for fix https://github.com/laravel/frame... n validation.md
---
Index: validation.md
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/validation.md b/validation.md
--- a/validation.md (revision 5132a50e5a568771414403dcb7c990cc8d582287)
+++ b/validation.md (revision ffc447842142e098ac1931d685aabe0287890428)
@@ -148,6 +148,13 @@ In this example, if the `unique` rule on the `title` attribute fails, the `max` rule will not be checked. Rules will be validated in the order they are assigned. +> [!NOTE]
+> Automatic Termination for Primitive Rules
+
+> In Maravel-Framework, certain primitive type rules act as implicit "bail" rules. If any of the following rules fail for an attribute, validation for that attribute will stop immediately to prevent unnecessary processing or potential type errors in subsequent rules:
+`uploaded`, `Numeric`, `Array`, `Boolean`, `String`, `Integer`, and `Decimal`.
+> Additionally, if a rule throws an exception, that rule will act as `Bail` and no other rules will run.
+ <a name="a-note-on-nested-attributes"></a> #### A Note on Nested Attributes @@ -2385,3 +2392,10 @@ > An "implicit" rule only _implies_ that the attribute is required. Whether it actually invalidates a missing or empty attribute is up to you. > > Maravel-Framework validates the present field even if empty or null!
+
+
+> [!NOTE]
+> Implicit Behavior of Type Rules
+
+> While not strictly "Implicit", `Numeric`, `Array`, `Boolean`, `String`, `Integer`, and `Decimal` rules are treated with the same priority as implicit rules regarding the validation lifecycle. Once one of these core type expectations fails, the validator considers the attribute's state "unusable" and halts further validation for that specific field. That is why you should always precede rules that need a certain type with one of the above rules.
+> Furthermore, any rule that throws a Throwable will trigger an automatic Bail, isolating the failure to prevent system-wide crashes.
\ No newline at end of file

I chose this general patch vs changing each of the rules and duplicating is_string check for example.

Maravel PHP Ecosystem

The previous benchmark showed Maravel leading by 107% more RPS than Lumen 10. After I merged all cached files into one file in version 10.69 of Maravel-Framework, the percent increased to more than 116%.

Gemini generated image

RPS & Memory peak

These are the results for a Hello World benchmark thanks to https://github.com/myaaghubi/PHP... on an old desktop system:

PHP 8.3

Maravel-Framework 10.67.0 brings a new, faster and safer Router via Maravel 10.52.48.

It all started after I finished refactoring the deferred service providers to gain boot speed (see history:

• Maravel-Framework 10.64.17 brings domain routes restriction to Maravel Micro-Framework,

• The Zero-Cost Boot Hack Every Maravel Developer Needs to Know

• Maravel 10.52.47 Doubles Lumen s 10 Throughput in PHP 8.3

Maravel-Framework 10.66.8 enables Maravel Micro-Framework 10.52.47 to obtain with 107% more RPS than Lumen 10 in a Hello world https://github.com/myaaghubi/PHP... benchmark on PHP 8.3.

This result comes after the deferred providers logic in Maravel was improved.

In previous benchmarks, Maravel was with 62% faster than Lumen 10 in PHP 8.1:

Press enter or click to view image in full size

I had to configure the mail on Maravel.

The Lumen usual path would had been:

// bootstrap/app.php
$app->configure('mail'); $app->alias('mail.manager', Illuminate\Mail\MailManager::class);
$app->alias('mail.manager', Illuminate\Contracts\Mail\Factory::class); $app->alias('mailer', Illuminate\Mail\Mailer::class);
$app->alias('mailer', Illuminate\Contracts\Mail\Mailer::class);
$app->alias('mailer', Illuminate\Contracts\Mail\MailQueue::class); $app->register(Illuminate\Mail\MailServiceProvider::class);

But this will execute those on each request even if the request will not send any email.

Version 10.52.35 of Maravel Micro-Framework is out with built-in cruFd (Create, Read, Update, Filter and Delete).

Forget about implementing filters for each of your resource. MaravelQL handles that for you.

It requires the latest Maravel-Framework 10.65 and the laravel-crud-wizard-free lib suite composed of:

• laravel-crud-wizard-free

• laravel-crud-wizard-decorator-free

• laravel-crud-wizard-generator

Now you can define your relations like this, in one place in your model:

// model protected function segregatedRelationsDefinitionMap(): array { return [ 'relName' => fn(): HasOne => $this->hasOne(Model::class, 'model_id', 'id'), // Reuse the segregatedrelation inside another segregated relation: 'relNameScoped' => fn(): HasOne => $this->relName()->where('col', '=', 'text'), 'relNameScoped2' => fn(): HasOne => $this->callSegregatedRelation('relName')->where('col', '=', 'text'), // Reuse the method relation: 'relNameAsMethod' => $this->relNameAsMethod(...), 'relNameAsMethod' => fn(): HasOne => $this->relNameAsMethod(), // AVOID THIS BECAUSE IT IS NOT Closure and it will not work: 'relNameAsMethod' => [$this, 'relNameAsMethod'], // AVOID THIS 'relNameAsMethod' => fn(): HasOne => [$this, 'relNameAsMethod'](), // DO NOT USE IT LIKE THIS!: 'relNameAsMethod' => fn(): HasOne => $this->relNameAsMethod(...)(), // executes the relation inside the map. ]; }

And get the whole list by calling segregatedRelationList:

/** * Get the list of all currently identified relationship keys. * * This list includes: * 1. Explicitly defined relations from * @see segregatedRelationsDefinitionMap() * 2. Implicit method-based relations that have been "promoted" to the global * static map via @see resolveSegregatedRelationClosure() * * @param bool $discoverMethods If true, performs a one-time SLOW REFLECTION scan to identify and * promote all typed relationship methods to the global map. * * @note This list is usage-dependent when $discoverMethods is false. If true, the static * map is force-populated for the remainder of the request lifecycle. * THE FASTEST WAY for execution is to refactor all method relations by moving them into that map or * manually promote all method relations to segregated relations via: * @see segregatedRelationsDefinitionMap() * return [ * 'relNameAsMethod' => $this->relNameAsMethod(...) * ] * * @return string[] */
final public function segregatedRelationList(bool $discoverMethods = false): array
{ if ($discoverMethods) { $this->promoteMethodRelationsToSegregatedRelations(); } return \array_keys($this->thisSegregatedRelationDefinitionMap());
}

Challenged by this discussion which proposes PHP attributes for the relation definition to avoid the method definition issues that arise for identifying if a method is relation or not in an active record, after this PR you can segregate the relation definition from the model s methods without using Reflection.

More details.

This was the missing piece after version 10.64.14 of Maravel-Framework brought full view support to Maravel, including view:cache, session (CSRF), cookie and FormRequest.

domain keyword can be used as single valid url or as list of valid urls.

The global helper function route( alias ) will return full URLs instead of URIs.

Maravelith API vs WEB RPS increased by 90% and memory decreased by 3% after I converted View, Cookie and Session service providers into deferred providers in version 10.64.14 of Maravel-Framework that also brought full view support to Maravel as well, including view:cache, session (CSRF), cookie and FormRequest.

As mentioned here, it is not fair to compare Maravelith WEB with Maravel API or Laravel WEB with Lumen API routes. Analog for any php micro-framework that is compared with full framework. Comparisons should be done on API vs API because the session middleware brings an important slow down on the web routes.

After version 10.64 introduced the FormRequest to Maravel, version 10.64.8 brings Session and Cookies support also as OPT IN.

The reason for this feature is that you might need to use csrf tokens and/or cookies in your views WITHOUT migrating to Maravelith and trading boot speed just for that.

Because Maravel-Framework is a DI centered framework, the efficiency of its container is crucial.

Version 10.64 introduces FormRequest in Maravel Micro-Framework 10.52.25.

Version 10.64 of Maravel-Framework removed the \Illuminate\Foundation\Providers\FormRequestServiceProvider, leading to faster registration and boot times.

Please note that using $app-beforeResolving, $app->resolving or $app->afterResolving events, the speed of the container decreases because for each resolve, all events are looped to search via === or instanceof/is_subclass_of for the ones that need to be triggered.

• 10.8k dev commands

• 10.2k test classes

• 3.7k remaining test classes in v10.63.5

The tests using these MOVED classes must be updated with \MacropaySolutions\MaravelFrameworkDev\ instead of Illuminate\ FQN prefix.

The old tests will fail for sure because of this but production code should not if it does not use fake/test code/classes.

Versions 2.0.0 of laravel-crud-wizard-decorator-free and version 7.1.0 of laravel-crud-wizard-free introduce an important response time improvement by eliminating useless json_decode and json_encode calls between the controller and the middlewares.

Because the controller resolves the JsonResponse from DI, the CrudProvider registers a binding for it in which the json_encode is skipped when the data needs decoration.

This follows Maravel-Framework s design of DI first logic and it works also in Laravel and Lumen.

Because I dislike runtime reflection, I improved the autowiring:cache command to include also constructors, not just methods.

If the concrete has contextual bindings (and constructor parameters) the old reflection is still used.

If the parameters are sent as array list, concrete will be instantiated directly with them. On failure, it will default to the old reflection but at the cost of building an Exception.

The official web page https://maravel-framework.com/docs/ now holds links to the official updated documentation of the Maravel-Framework s Templates.

• Maravel Micro-Framework Docs

• Maravelith Docs

• Maravel-Framework Wiki

The docs were updated, starting from Lumen and Laravel 10 docs, with the fixes and improvements up to Maravel-Framework 10.62.8.