Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

I can't seem to insert any Gravity forms merge tags on the forms notification edit screens. It it working on the forms confirmation edit screens.

What have you tried?

• I disabled all other plugins except Gravity forms itself
• I switched form my Sage theme to the default Twenty Twenty-Two theme
• Disabled the \Roots\bootloader() call in functions.php
• Disabled all of my wordpress actions & filters
• Disabled all of my enqueued javascripts
• Moved the composer dependency from my theme to Bedrock

What insights have you gained?

• Switching to default theme fixes the issue, but that's only because it's not loading Acorn with the bootloader.

Possible solutions

• Remove Acorn as dependency

Temporary workarounds

• None

Steps To Reproduce

1. Install the Gravity forms plugin
2. Create a form and go to it's notifications page
3. Try to insert a merge tag in the from email address field

Expected Behavior

I expect a dropdown list with the all form fields merge tags to appear.

Actual Behavior

Nothing happens, I get an error in my browser console.

Relevant Log Output

Uncaught TypeError: Cannot read properties of null (reading 'value')
    at MaybeAddSaveLinkMergeTag (admin.php:1227:54)
    at admin.php:78:22
    at Array.forEach (<anonymous>)
    at Object.doHook (admin.php:70:11)
    at Object.applyFilters (admin.php:38:17)
    at gfMergeTagsObj.getMergeTags (form_admin.js:1322:21)
    at gfMergeTagsObj.getMergeTagListItems (form_admin.js:1463:24)
    at HTMLAnchorElement.<anonymous> (form_admin.js:952:35)
    at HTMLAnchorElement.dispatch (jquery.js:5430:27)
    at HTMLAnchorElement.elemData.handle (jquery.js:5234:28)

Versions

2.0.0

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

After updating Acorn from v2.0.0-beta.8 to v2.1.1, having WP_DEBUG or WP_DEBUG_DISPLAY set to false in my Bedrock environment causes PHP to throw an error.

PHP message: PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/projects/myproject/vendor/illuminate/container/Container.php:1089

Temporary workarounds

Downgrading back to v2.0.0-beta.8.

Steps To Reproduce

1. Disable either WP_DEBUG or WP_DEBUG_DISPLAY in your Bedrock environment config.
2. Try loading a page on your site.

Expected Behavior

Errors should simply not be shown when WP_DEBUG is false, as it does in v2.0.0-beta.8.

Actual Behavior

PHP throws an error:

PHP message: PHP Fatal error: Uncaught Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable. in /home/vagrant/projects/myproject/vendor/illuminate/container/Container.php:1089

Relevant Log Output

No response

Versions

2.1.1

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Summary

Asset currently has a path() function that returns the full, absolute path to the asset. Sometimes the path relative to the theme directory is also needed, as for add_editor_style. Currently, additional code/library is needed to get the path relative to theme directory from the absolute path returned by the path() function. It would be nice if also a function is added that returns the path to asset relative to the (Sage) theme directory.

Motivation

Why are we doing this?

Sometimes the path relative to the theme directory is also needed.

What use cases does it support?

add_editor_style requires either an URI (that currently cause an issue post-processing CSS in Gutenberg editor to rewrite URLs relative to stylehsheet) or a path to a local file relative to the theme directory (that doesn't cause this issue).

What is the expected outcome?

Elimination of additional code/library for making the absolute asset path (from path()) relative to the theme directory path, so it can be used by functions like add_editor_style.

Potential conflicts / foreseeable issues

One more API function in acorn, paths and their handling shouldn't change in the foreseeable future, so once the code (and tests) for a theme-directory-relative path function is in place, no changes should be expected any time soon. As this functionality would be requires in any theme that adds the frontend styles in the expected way (using add_editor_style), this should justify adding such an additional function.

Additional Context

https://discourse.roots.io/t/absolute-domain-relative-path-for-asset-urls-in-css/23121/4

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

After upgrading Acorn to the 3.0.0-alpha.3 version (but it also happens on alpha.1 & alpha.2), the Template dropdown in the Page attributes metabox has completely disappeared somehow. When viewing my template sin the frontend I get a Target class [sage.view] does not exist. error?

What have you tried?

• I tried installing all 3.0.0-alpha versions and running all of these commands afterwards:

wp acorn acorn:init
wp acorn package:discover
wp acorn vendor:publish
wp acorn config:clear
wp acorn optimize:clear
wp acorn optimize
wp acorn view:cache

All without errors and I can also see my log1x/acf-composer fields & log1x/poet types in the backend.

• I disabled all of my plugins.
• I disabled all of my wordpress actions/filters in my theme.

What insights have you gained?

I think Acorn possible is not recognising my template files inside the resources/views folder even though get_theme_file_path('/resources/views') is returning the correct path?

Possible solutions

Downgrading to Acorn 2.1, but then I'm bumping into this bug again.

Temporary workarounds

Switch to a default Wordpress theme

Steps To Reproduce

1. Install roots/acorn 3.0.0-alpha.3 with composer in your Bedrock folder: composer require roots/acorn:3.0.0-alpha.3
2. Call the bootloader in your functions.php: \Roots\bootloader()->boot();
3. Go to an edit page in your Wordpress backend and have a look at the Page attributes box in the right sidebar.
4. Switch to a default Wordpress theme and repeat step 3.

Expected Behavior

The Page attributes box in the right sidebar should have a Template dropdown.

Actual Behavior

The Page attributes box in the right sidebar does not have a Template dropdown anymore.

Relevant Log Output

No php errors whatsoever

Versions

Acorn 3.0.0-alpha.3 PHP 8.0.22 Composer version 2.4.1

For a while I use a solution for better handling WordPress filters and actions.

Every filter class is stored in configuration as class name string and it is build on application bootstrap by container. By this filter class can have easily access to dependency injection on construct. Every filter instance must have handle method which is handle by default. Count of arguments for handle method is automatically calculated by reflection mechanism. Filter priority is object property with 10 value by default. Filter is applied by \Roots\add_filters and removed by Roots\remove_filters

All is contracted and fully typed, in all my cases this solution was doing great.

• [x ] I've read the guidelines for Contributing to Roots Projects
• [ x] This request isn't a duplicate of an existing issue
• [ x] I've read the docs and followed them (if applicable)
• [ x] This is not a personal support request that should be posted on the Roots Discourse community

Description

For the Sage 10 project we wanted to disable the escalation of notices to errors because some plugins still have notices. There is a fix implemented that works in the main branch of roots/acorn.

https://github.com/roots/acorn/issues/100

When using the roots/acorn main branch, the error handler is working as expected again but the system gets a fatal error in the Bootloader.php.

When loading the app (Line 203, $app = $this->appClassName::getInstance();) the appClassName is Application but the Illuminate/Container is loaded. The next line is setBasePath but the Container does not contain this function.

When rewriting this line (For testing) to $app = new \Roots\Acorn\Application; the application works as expected.

Could you tell me what went wrong here? We would like to use the most recent version so we can change the behaviour of the Error handler.

I added a few screenshots of my changes and the information xDebug is giving me.

Hope to hear from you soon.

With kind regards,

Jochem

Steps to reproduce

1. Checkout the sage 10 main branch
2. run a composer require in the sage 10 folder on dev-main of the roots/acorn to update the roots/acorn package.
3. Try to run any action in the installation

Expected behavior:

The line: $app = $this->appClassName::getInstance(); should get the instance of the appClassName. Not the container.

Actual behavior:

The line: $app = $this->appClassName::getInstance(); Got the Container class that does not have the function setBasePath.

Reproduces how often:

Every time.

Versions

Sage --> main branch Roots/Acorn --> from beta to main branch. Alpha does not contain this error and has different code for getting the application: $app = new $this->appClassName($basePath, $this->usePaths());

Additional information

This is a fairly significant restructuring of things.

I haven't extensively tested everything, but I did make sure a sage 10 site loads without any errors and the wp-cli commands are working.

Tests are going to be failing because they need to be refactored. I can handle that this weekend.

(I'll document all of the changes I made later.)

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

Sometimes packages cannot be published.

What have you tried?

Please see steps below.

What insights have you gained?

None.

Possible solutions

None I am aware of.

Temporary workarounds

Adding the Laravel service provider manually to /config/app.php will work occasionally.

Steps To Reproduce

Add ACF Composer to /sage/composer.json and update.

  "require": {
    "php": "^7.4|^8.0",
    "log1x/acf-composer": "^2.0",
    "roots/acorn": "^2.0.3"
  },

Discover packages:

wp acorn package:discover
Discovered Package: log1x/acf-composer
Discovered Package: nesbot/carbon
Discovered Package: roots/sage
Package manifest generated successfully.

Publish packages: (ACF Composer not in the list):

wp acorn vendor:publish

 Which provider or tag's files would you like to publish?:
  [0] Publish files from all providers and tags listed below
  [1] Provider: Roots\Acorn\Providers\AcornServiceProvider
  [2] Tag: acorn
 > 

Checking cache reveals ACF composer entry in array. /current/web/app/cache/acorn/framework/cache:

<?php return array (
  'log1x/acf-composer' => 
  array (
    'providers' => 
    array (
      0 => 'Log1x\\AcfComposer\\Providers\\AcfComposerServiceProvider',
    ),
  ),

Other packages can be discovered and published:

  "require": {
    "php": "^7.4|^8.0",
    "andreiio/blade-iconoir": "^1.4",
    "blade-ui-kit/blade-heroicons": "^1.3",
    "blade-ui-kit/blade-icons": "^1.2",
    "codeat3/blade-weather-icons": "^1.4",
    "log1x/acf-composer": "^2.0",
    "log1x/navi": "^2.0",
    "log1x/poet": "^2.0",
    "log1x/sage-html-forms": "^1.0",
    "roots/acorn": "^2.0.3"
  },

Discovered Package: andreiio/blade-iconoir
Discovered Package: blade-ui-kit/blade-heroicons
Discovered Package: blade-ui-kit/blade-icons
Discovered Package: codeat3/blade-weather-icons
Discovered Package: log1x/acf-composer
Discovered Package: log1x/navi
Discovered Package: log1x/poet
Discovered Package: log1x/sage-html-forms
Discovered Package: nesbot/carbon
Discovered Package: roots/sage
Package manifest generated successfully.

Which provider or tag's files would you like to publish?:
  [0 ] Publish files from all providers and tags listed below
  [1 ] Provider: AndreiIonita\BladeIconoir\BladeIconoirServiceProvider
  [2 ] Provider: BladeUI\Heroicons\BladeHeroiconsServiceProvider
  [3 ] Provider: BladeUI\Icons\BladeIconsServiceProvider
  [4 ] Provider: Codeat3\BladeWeatherIcons\BladeWeatherIconsServiceProvider
  [5 ] Provider: Log1x\Poet\PoetServiceProvider
  [6 ] Provider: Roots\Acorn\Providers\AcornServiceProvider
  [7 ] Tag: acorn
  [8 ] Tag: blade-heroicons
  [9 ] Tag: blade-heroicons-config
  [10] Tag: blade-iconoir
  [11] Tag: blade-icons
  [12] Tag: blade-weather-icons-config
  [13] Tag: blade-wi
  [14] Tag: config
 > 0

Copied Directory [/vendor/andreiio/blade-iconoir/resources/svg] To [/public/vendor/blade-iconoir]
Copied Directory [/vendor/blade-ui-kit/blade-heroicons/resources/svg] To [/public/vendor/blade-heroicons]
Copied Directory [/vendor/codeat3/blade-weather-icons/resources/svg] To [/public/vendor/blade-weather-icons]
Publishing complete.

Additional information and users with same problem can be found here: https://github.com/Log1x/acf-composer/issues/109

Expected Behavior

Expecting ACF Composer to be listed in the set of available packages to publish:

 [0 ] Publish files from all providers and tags listed below
  [1 ] Provider: AndreiIonita\BladeIconoir\BladeIconoirServiceProvider
  [2 ] Provider: BladeUI\Heroicons\BladeHeroiconsServiceProvider
  [3 ] Provider: BladeUI\Icons\BladeIconsServiceProvider
  [4 ] Provider: Codeat3\BladeWeatherIcons\BladeWeatherIconsServiceProvider
  [5 ] Provider: Log1x\Poet\PoetServiceProvider
  [6 ] Provider: Roots\Acorn\Providers\AcornServiceProvider
  [7 ] Tag: acorn
  [8 ] Tag: blade-heroicons
  [9 ] Tag: blade-heroicons-config
  [10] Tag: blade-iconoir
  [11] Tag: blade-icons
  [12] Tag: blade-weather-icons-config
  [13] Tag: blade-wi
  [14] Tag: config

Actual Behavior

ACF Composer package not becoming available.

Attempting to generate ACF Field, wp acorn acf:field Fleet results in: There are no commands defined in the "acf" namespace.

After adding and publishing additional packages, ACF Composer is listed in cache but not functioning:

<?php return array (
  'andreiio/blade-iconoir' => 
  array (
    'providers' => 
    array (
      0 => 'AndreiIonita\\BladeIconoir\\BladeIconoirServiceProvider',
    ),
  ),
  'blade-ui-kit/blade-heroicons' => 
  array (
    'providers' => 
    array (
      0 => 'BladeUI\\Heroicons\\BladeHeroiconsServiceProvider',
    ),
  ),
  'blade-ui-kit/blade-icons' => 
  array (
    'providers' => 
    array (
      0 => 'BladeUI\\Icons\\BladeIconsServiceProvider',
    ),
  ),
  'codeat3/blade-weather-icons' => 
  array (
    'providers' => 
    array (
      0 => 'Codeat3\\BladeWeatherIcons\\BladeWeatherIconsServiceProvider',
    ),
  ),
  'log1x/acf-composer' => 
  array (
    'providers' => 
    array (
      0 => 'Log1x\\AcfComposer\\Providers\\AcfComposerServiceProvider',
    ),
  ),
  'log1x/navi' => 
  array (
    'providers' => 
    array (
      0 => 'Log1x\\Navi\\Providers\\NaviServiceProvider',
    ),
    'aliases' => 
    array (
      'Navi' => 'Log1x\\Navi\\Facades\\Navi',
    ),
  ),
  'log1x/poet' => 
  array (
    'providers' => 
    array (
      0 => 'Log1x\\Poet\\PoetServiceProvider',
    ),
  ),
  'log1x/sage-html-forms' => 
  array (
    'providers' => 
    array (
      0 => 'Log1x\\HtmlForms\\HtmlFormsServiceProvider',
    ),
  ),
  'nesbot/carbon' => 
  array (
    'providers' => 
    array (
      0 => 'Carbon\\Laravel\\ServiceProvider',
    ),
  ),
  'roots/sage' => 
  array (
    'providers' => 
    array (
      0 => 'App\\Providers\\ThemeServiceProvider',
    ),
  ),
);

Relevant Log Output

No response

Versions

Acorn 2.0.3, Big Sur 11.6.1

• [ ] I've read the guidelines for Contributing to Roots Projects
• [x] This request isn't a duplicate of an existing issue
• [ ] I've read the docs and followed them (if applicable)
• [x] This is not a personal support request that should be posted on the Roots Discourse community

Description

The Symfony error handler is never rendering which leads to blank pages on errors when WP_ENV is not set to development

Steps to reproduce

1. Set WP_ENV to "local"
2. Trigger an error/exception

Expected behavior: Symfony error page

Actual behavior: Blank page

Reproduces how often: 100%

Versions

2.0.1

Im updated my packages withcomposer update` command, as usualy. And after yhat - whole application is broked. Everything worked fine before updating packages.

Here is the most recent stacktrace: https://prnt.sc/11plccz

`ErrorException thrown with message "Undefined index: url"

Stacktrace: #24 ErrorException in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php:87 #23 Illuminate\Foundation\Bootstrap\HandleExceptions:handleError in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php:87 #22 Roots\Acorn\Assets\Manager:resolve in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Roots/Acorn/Assets/Manager.php:66 #21 Roots\Acorn\Assets\Manager:manifest in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Roots/Acorn/Assets/AssetsServiceProvider.php:22 #20 Roots\Acorn\Assets\AssetsServiceProvider:Roots\Acorn\Assets{closure} in /var/www/html/web/app/themes/zcci-theme/vendor/illuminate/container/Container.php:829 #19 Illuminate\Container\Container:build in /var/www/html/web/app/themes/zcci-theme/vendor/illuminate/container/Container.php:714 #18 Illuminate\Container\Container:resolve in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Illuminate/Foundation/Application.php:841 #17 Illuminate\Foundation\Application:resolve in /var/www/html/web/app/themes/zcci-theme/vendor/illuminate/container/Container.php:652 #16 Illuminate\Container\Container:make in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Illuminate/Foundation/Application.php:826 #15 Illuminate\Foundation\Application:make in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/Roots/Acorn/Application.php:304 #14 Roots\Acorn\Application:make in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/helpers.php:42 #13 Roots\app in /var/www/html/web/app/themes/zcci-theme/vendor/roots/acorn/src/helpers.php:67 #12 Roots\asset in /var/www/html/web/app/themes/zcci-theme/app/setup.php:21 #11 App{closure} in /var/www/html/web/wp/wp-includes/class-wp-hook.php:292 #10 WP_Hook:apply_filters in /var/www/html/web/wp/wp-includes/class-wp-hook.php:316 #9 WP_Hook:do_action in /var/www/html/web/wp/wp-includes/plugin.php:484 #8 do_action in /var/www/html/web/wp/wp-includes/script-loader.php:2027 #7 wp_enqueue_scripts in /var/www/html/web/wp/wp-includes/class-wp-hook.php:292 #6 WP_Hook:apply_filters in /var/www/html/web/wp/wp-includes/class-wp-hook.php:316 #5 WP_Hook:do_action in /var/www/html/web/wp/wp-includes/plugin.php:484 #4 do_action in /var/www/html/web/wp/wp-includes/general-template.php:3009 #3 wp_head in /var/www/html/web/app/themes/zcci-theme/index.php:7 #2 include in /var/www/html/web/wp/wp-includes/template-loader.php:106 #1 require_once in /var/www/html/web/wp/wp-blog-header.php:19 #0 require in /var/www/html/web/index.php:6 `

As mentioned in #1 I will add more unit tests to the code.

Tests added for following namespaces:

• Roots\Acorn\Assets
• Roots\Acorn\Clover
• Roots\Acorn\Exceptions

I made as little changes to the code base as possible, I will document them here:

• Added ext-json to composer.json as JsonSerializable was in use
• Added <directory>./tests</directory> to whitelist in phpunit.xml.dist to correctly calculate coverage
• Removed unused Roots\Acorn\Assets\RelativePathManifest and fixed type hints in AssetManager.php
• Fixed types RelativePathManifest.php and added missing array initialization
• Fixed type in Acorn/Bootstrap/LoadBindings.php
• Added missing dependency to illuminate/http and fixed type hint in Acorn/Exceptions/Handler.php render method

Updates the requirements on dealerdirect/phpcodesniffer-composer-installer to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

First, I'd like to apologize because I went into a hypnotic deep dive into ACF and WP's code to try to figure out a way to solve this without the need to change the end user's code, but I don't think it's possible right now.

What's wrong?

AcfFields View Composer traits uses "get_fields" to get all the field values, but blocks "example" data can't be fetched with this.

What insights have you gained?

ACF is able to retrieve the example fields with "get_field" only (not "get_fields"), because "get_fields" only fetches metadata about fields that have previously been saved. Since this check internally doesn't happen against example data, and uses field keys instead of field names, it fails.

Possible solutions

Create another trait, (AcfBlockFields?) specifically for blocks.

Temporary workarounds

Since the only way to get the proper data all the time, either from the block's saved values or from the example data, is to pass through "get_field", we need to get all the fields assigned to the block with another method than "get_fields". Here's what I ended up with.

<?php

namespace Roots\Acorn\View\Composers\Concerns;

use Illuminate\Support\Fluent;
use Illuminate\Support\Str;

trait AcfBlockFields
{
    /**
     * ACF data to be passed to the view before rendering.
     *
     * @param  int $post_id
     * @return array
     */
    protected function fields($name)
    {
        $data = [];
        $field_groups = acf_get_field_groups([
            'block' => $name
        ]);
        foreach ($field_groups as $fg_key => $field_group) {
            $fields = acf_get_fields($field_group['key']);
            foreach ($fields as $f_key => $field) {
                $data[$field['name']]=get_field($field['key']);
            }
        }
        return $data;
    }
}

Notes

As mentionned at the beginning, I tried to create a patch on the current trait that would work for both posts and blocks without changing much of the code as I was trying to avoid needing the end users to change their local code, but the problem arises when we need to get the current block's field name. Once we're inside a block rendering loop, there's nothing passing down the current block data, it doesn't seem to be saved by WP in a global(?). The only way to get the current block's name is by passing it down ourselves. I went down the rabbithole of trying to find how ACF stores / re-instates get_the_ID and I found acf_get_instance( 'ACF_Local_Meta' )->post_id which is the current block's ID or the current post's id, for field data retrieval purposes. That being said... nothing allows us to link the block id to the block's name since now the block ids are generated non absolute values. I feel like I'm going insane because it should be easy to detect wether or not we are currently rendering a block and get the block's data / name so that we can shortcircuit the trait's method ``ìf(is_block()) { $this->get_blocks_data(); }```.

On the other hand, creating another trait would probably be the best solution since changing the code in the trait could result in unexpected data changes in previews if people are using sub-views with the existing trait.

Steps To Reproduce

1. Add a block rendered with a view composer
2. Pass example data when registering the block
3. Look at the example previews the block editor pops up in the blocks list when hovering the mouse on the block's names, or previewing a block style

Expected Behavior

Data passed as "example" in acf_register_block_type should be rendered

Actual Behavior

No preview can be generated because example data is not passed down by "get_fields".

Relevant Log Output

No response

Versions

2.1.2

Terms

• [X] I have read the guidelines for Contributing to Roots Projects
• [X] This request is not a duplicate of an existing issue
• [X] I have read the docs and followed them (if applicable)
• [X] I have seached the Roots Discourse for answers and followed them (if applicable)
• [X] This is not a personal support request that should be posted on the Roots Discourse community

Description

What's wrong?

This is not really a bug, but is functionality that results in confusing behavior.

During service provider registration, providers that encounter errors are silently skipped and reported to the logger.

In a vanilla Sage 10 install, this is not obvious to the developer as logging is disabled out of the box.

What have you tried?

N/A

What insights have you gained?

N/A

Possible solutions

There are a few things we could do to make this a bit less painful.

1. Enable logging by default when WP_ENV is set to development.
2. Show provider exceptions when WP_ENV is not set to production.

Either of the above (or both) would make it more manageable (without having to bring down configs).

Temporary workarounds

Right now the only way to get any sort of errors/feedback is to dump Acorn's configs and manually set default in logging.php to stack.

Steps To Reproduce

N/A

Expected Behavior

N/A

Actual Behavior

N/A

Relevant Log Output

No response

Versions

v2.1.2

This adds illuminate/routing as a dependency.

• [ ] conditionally add auth, cookie, session, etc. middleware if they exist (x-ref laravel/laravel/blob/9.x/app/Http/Kernel.php)

This bumps the 1.x branch to Laravel 8 from 7, also increasing the minimum PHP version to 7.3.

This specifically addresses compatibility with newer versions of log1x/acf-composer as it uses Str::remove, which was introduced in Laravel 8.41.0.

Ref: https://github.com/Log1x/acf-composer/blob/33e2b7529fbd7190f024dd3d66a6e9a2b95e6f5b/src/AcfComposer.php#L91 Ref: https://github.com/laravel/framework/releases/tag/v8.41.0