I feel like it's important to update often and transparently. It's been less than a month since 3.2 and we have a feature packed 3.3 release for you and it is 100% backwards compatible.
- Installer now attempts to create database if missing.
- Installer can be automated with HTTP / CLI usage.
- Released a Pyro installer.
- Repeater field type has been moved into core.
- Datetime field type has been vastly improved.
- Navigation menu is now sortable.
- Module section's can now use labels.
- Form section tabs can now stack vertically.
- Form sections can now define rows and columns of fields.
- Image service automatically guesses alt tags if not provided.
- Asset service automatically versions asset URLs.
- System-wide query optimization.
- Various bug fixes.
To update simply modify your
Next bump the version found in
3.3.0 and run
composer update. Lastly run
php artisan asset:clear to force assets to recompile.
We are always working towards more automation for developer tasks. Automating the installer is a big step in allowing developers to automate their workflow further with Pyro.
Check out documentation for Automating the Installer via cURL.
And also for Automating the Installer via CLI.
While we're on the installer topic we have also released a local Pyro installer. Currently this is not much more than Composer installation but we will be soon adding more automation to allow spinning up Pyro applications based on a template.
Repeater/Datetime Field Types
We have pushed the Repeater field type into core! This means that it will now be included in base installations of Pyro.
We have also drastically updated the Datetime field type while maintaining backwards compatibility. We've struggled and have heard reports of others suffering the same struggles with the pickers in the Datetime field type. They're great for administrative purposes but often find themselves in public forms as well. This causes a few big issues including poor user experience, painful integration of dependencies, and poor validation / rigid input restrictions.
The Datetime 3.0 field type is very close to native datetime input behavior. It allows simple spinner behavior for configurable date/time formats and also accounts for format changes by the user. As long as the datetime can pass
strtotime validation it will be accepted. This prevents small adjustments (spacing / commas / etc) from breaking the user experience and throwing a wrench into validation.
In the 3.2 release we reworked the navigation so that it would make sense for custom navigation sorting. In 3.3 we have executed the feature! You can now head to Settings > Themes and update the
default sort order of the main navigation. You can also navigate to Preferences > Themes and sort the navigation specific to your liking as well.
We have introduced
labels for sections. If a section specifies a label string or translation key then a navigation label separator will be displayed above the section in the menu:
'payments' => [ 'label' => 'Sales', 'buttons' => [ 'new_payment' => [ 'data-toggle' => 'modal', 'data-target' => '#modal', 'href' => 'admin/store/payments/choose', ], ], ],
This is helpful for addons that have a larger number of sections.
Form section tabs can now define
'stacked' => true to make section tabs stack vertically instead of the traditional horizontal orientation.
Form sections can now also define rows and columns of fields:
'general' => [ 'rows' => [ [ 'columns' => [ [ 'classes' => [ 'col-lg-12', ], 'fields' => [ 'page_title', ], ], [ 'classes' => [ 'col-lg-12', ], 'fields' => [ 'page_slug', ], ], ], ], ], ],
Image class now automatically guesses alt tags by default if none is provided. It does this by "humanizing" the the filename. An image named "my-favorite-animal.jpg" would have a default alt tag "My Favorite Animal".
Asset classes now automatically return version IDs in URI paths as to make it easier to bust browser cache as files change.
We've taken some elegant steps to optimize queries across the system with smarter eager loading. We have also implemented intuitive runtime cache in order to prevent developers from having to implement arbitrary cache mechanisms for identical queries through common services across the platform.
All in all 3.3 feels SOLID. We love it and we hope you do too!
A note on Laravel 5.4
We have started the migration process to Laravel 5.4 but the
$container->make(...) API change really throws a wrench into a quick turnaround. With that said we will continue making changes necessary to get Laravel 5.4 included with upcoming releases as fast as we can. Though admittedly it feels less important than the 5.3 update did as features are not as enticing.
The Store development is humming along. We've overcome some intense hurdles in design and architecture of the Store solution and are on a consistent work schedule with it as well.
The Store bundle/suite has been consolidated into the Store module. It will contain shipping, cart, products, orders, payments, etc, etc in one addon. With many extensions available for product types, payment providers, checkout strategies, etc. This has made the development much more sane now that we don't have to worry about the massive overhead of keeping everything decoupled. The Store components will be tightly coupled but extremely extensible through extensions and customization options. More news on the Store soon as development continues!
Thanks again for all the continued support and PRO developers bringing their skill and experience to the project through feedback and support. Could not be more exciting to be involved with Pyro right now!
Go forth and build.