On a shared host I have problems with getting Acorn to work correctly.
Acorn is installed as a normal plugin. Acorn does create and write to a cache folder on the server and most things work fine.
However when I try to install a package such as log1x/acf-composer it doesn’t work
I noticed that some things are missing in the Acorn cache folder on the server.
In the services.php these entries are missing under ‘providers’:
I am using Acorn 2.1.2 (the php8 version) on a fresh install with the latest Bedrock/Sage/Bud
I did add "post-autoload-dump": ["Roots\\Acorn\\ComposerScripts::postAutoloadDump" ]
to the scripts in Bedrock’s composer.json, but I don’t think it works.
Locally I had to to run this to get acf-composer to work:
wp acorn package:discover
followed by: wp acorn vendor:publish --provider="Log1x\AcfComposer\Providers\AcfComposerServiceProvider"
Any ideas on how I could get this to work on the server?
Maybe related: When I run composer update in the Bedrock root folder (locally) I get this:
Nothing to install, update or remove
Generating optimized autoload files
Class Roots\Acorn\ComposerScripts is not autoloadable, can not call post-autoload-dump script
So adding the ‘autoload’ script to Bedrock’s composer.json doesn’t do anything when you install Acorn as a plugin, as I already suspected.
I tried that, but couldn’t get it to work on the shared host where cannot run composer install etc. Basically I need something similar to the ‘dist’ we had in Sage 8, where you don’t need to install anything on the server.
Acorn as a plugin is also recommended for shared hosts I believe.
I don’t understand why I shouldn’t do that when also using composer packages? I assumed that the Acorn plugin would take care of handling the ACF/block templates created with acf-composer when I upload them, just as it does for the regular blade templates. And as it does locally
composer require log1x/acf-composer from my theme folder.
I move the vendor files to the server. Not ideal I’m sure, but it works for Sage 10 vendor files, and I think this was also recommended in the docs
I feel it may also have to do with a similar issue that I found on github, which is related to either acorn or acf-composer.
Both issues were closed but seem unresolved.
For my situation, if this is just an isolated problem with acf-composer then I’ll just stop using that. I am just worried that I will encounter more problems in the future though.
Hence my more general question whether using modern Bedrock/Sage 10 on a shared host is still a viable/recommended path these days (in principle)? I realize that may be difficult to answer.
So I am mostly talking to myself here;) But I am still hoping for some insights. It is kind of crucial for me. I think the 3 questions below are the most important to me:
Should I be able to use Bedrock and Sage on a server that I cannot manage? (Acorn as plugin, assets and vendor folders uploaded as recommended in the docs?
Should I be worried that App\\Providers\\ThemeServiceProvider is not added to Acorn cache, for instance to the services.php file (on the server)?
If I cannot get Acorn to work, would it be bad practice/a bad idea to simply upload the local Acorn cached views to my remote server?
I can’t really speak to acf-composer—@Log1x might be able to explain what’s going on there.
In theory, sure. So far as I know, the docs don’t recommend using Acorn as a plugin, though. In fact doing so is explicitly not officially supported:
Although not officially supported, the following options should work. Please file a bug report (opens new window) for future consideration if you run into issues.
What do you mean by “couldn’t get it to work”? What failed? What errors did you run into? You shouldn’t need to run composer install on your remote host, just run it locally with --no-dev and then upload vendor. Acorn is, essentially, just a composer package. If you can install other composer packages and they work, Acorn should also work.
The cache is transient; it’s a cache. If something isn’t there that may be a concern, but you aren’t going to be able to reliably fix it by manually uploading something to the cache: If the cache contents are incorrect, either the thing(s) that should be writing to them aren’t working, or they can’t write to the cache directory (i.e. permissions issues). Either of which are the problems you should be looking at.
Yes, see above. Even if this “works” it’s not going to work.
These issues shouldn’t be related. Give what Ben said a try (running composer install --no-dev and uploading the vendor folder).
If this doesn’t work, try including ACF Composer in the theme instead and doing the same thing as above (running composer install --no-dev and uploading the vendor folder) and let me know if that works.
Thanks, yes I mainly read that as ’ it should probably work’ when I originally made the move to Sage 10 (from 8). But it is not as common a use case as it used to be in this community I feel.
I tried that, see my answer to log1x which I’ll post in a minute
That’s what I figured too. Acorn is able to write to cache though, so I don’t think it is a permissions problem
I got the idea to sync the cache to the server from a post in this thread, so it seemed like a viable approach:
After this I have the same results as before. There is no Example field on a new post. Acorn cache has the ‘normal’ views and entries, but misses all entries and views related to a Log1x\\AcfComposer\\Providers\\AcfComposerServiceProvider
and App\\Providers\\ThemeServiceProvider (see my opening post). The acorn log folder is empty by the way.
For now, can you try manually adding the provider Log1x\AcfComposer\Providers\AcfComposerServiceProvider::class to providers in config/app.php and see if that works?
Also make sure you’re requiring sage-directives in as non-dev. It looks like it removed it when you ran composer install --no-dev
Alternatively you can dump all of Acorn’s configs by doing wp acorn vendor:publish and choosing the Acorn service provider – but that shouldn’t be necessary in this case and I’d try the above first.
You mentioned logging not working, if you want to enable logging, you need to dump or bring over logging.php and change the default log channel from null to stack.
Sorry about that! I put the app.php to the config folder and added the provider. I also copied the logging.php file to the config folder and changed null to stack 'default' => env('LOG_CHANNEL', 'stack'),
Now we are getting somewhere! I can add fields now on the server. Cached views for the fields are generated. (The entries for acf-composer in services.php and packages.php are still missing)
You don’t need to worry about this now that it’s added to app.php – services.php and packages.php deal with package discovery which for some reason isn’t picking up ACF Composer in your server’s environment.
Nonetheless, you should be good to go. If you add more packages down the road, you will probably have to add them to app.php still but there’s no negative side to doing this.
Again I had to run wp acorn package:discover before I could publish the config file. But this time it seems to work fine on the server without adding the provider to config/app.php
Anyway if this is a viable workaround I am very happy.
So in summary the workaround to get acf/composer (and probably some other packages) to work when you use Acorn as a plugin:
Install the package in your theme folder
Publish (If needed use wp acorn package:discover)
Upload everything to server except node_modules, .budfiles, dev-only vendors and dev-only files (you may want to run composer install --no-dev first)
If acf-composer is not working on your server:
Copy the app.php from the Acorn version you are using to my-theme/config/
Manually add the provider
Upload again
edit: I assume it is also a good idea to add the App\\Providers\\ThemeServiceProvider in the same way, in case you want to register any application services in ThemeServiceProvider.php.