Q: How to fix Winter CMS plugin "Class not found" on Linux when autoloading works on macOS?

This happens because macOS is case-insensitive while Linux is case-sensitive. Winter CMS's plugin autoloader supports either consistent PSR-4 directory casing or the legacy lowercase structure, but not a mix of the two. For the namespace `Aic\Account\Classes\DTO\OrderPallet`, use the PSR-4 path: ```text plugins/aic/account/Classes/DTO/OrderPallet.php ``` Alternatively, use the legacy lowercase path: ```text plugins/aic/account/classes/dto/OrderPallet.php ``` If you need to keep a custom path such as `classes/DTO/OrderPallet.php`, add an explicit PSR-4 mapping in `composer.json`: ```json { "autoload": { "psr-4": { "Aic\\Account\\Classes\\": "classes/", "Aic\\Account\\": "" } } } ``` Then run: ```bash composer dump-autoload ```

Q: Why does Winter CMS show 'parse error: failed at <?php' when compiling SASS?

A known issue causes the editor to incorrectly add '<?php' to SASS files. Manually remove the '<?php' tag from affected .scss files via filesystem (not via Winter CMS backend). After removal, recompile assets normally.

Question 1

Why are dynamically added theme fields not showing in my Winter CMS partials?

Accepted Answer

Add a dummy field definition in your theme.yaml file under the form section. For example:
```yaml
form:
  fields:
    dummy:
```
This ensures fields added via the `cms.theme.extendFormConfig` event are accessible in frontend partials. The bug (present when no fields exist in theme.yaml) is fixed in commit 4655450a4b…; upgrade to the latest dev-develop or next stable release for a permanent solution.

Question 2

How to fix Winter CMS FormBuilder::select() error: Argument #2 ($list) must be of type array, Collection given?

Accepted Answer

This occurs in Winter CMS 1.2.10 when a dropdown field's `get*Options()` method returns a Laravel Collection instead of an array. As a workaround, call `->toArray()` on the returned Collection:

```php
public function getAddressCountriesOptions()
{
    return collect(...)->toArray();
}
```

The issue was officially fixed in Winter CMS 1.2.11, so upgrading to 1.2.11 or later is the permanent solution.

Question 3

How to fix Winter CMS 1.2 Composer install/update failure with Command::alert fatal error and enshrined/svg-sanitize security block on PHP 8.2/8.4?

Accepted Answer

Root causes:
1. Winter Storm versions <1.2.14 include an incompatible `alert()` method signature with newer Illuminate Console dependencies, triggering a fatal error on PHP 8.2/8.4.
2. Winter Storm 1.2.14+ requires `enshrined/svg-sanitize ~0.16`, a package with 4 published security advisories blocked by default Composer security auditing.

Workaround steps:
1. For existing project updates: Run the upgrade as your web server user (e.g. `www-data` for Debian/Ubuntu) with the `--no-security-blocking` flag to bypass security checks and install the compatible Winter Storm release:
```bash
sudo -u www-data composer require 'winter/storm:^1.2.14' -W --no-security-blocking
```
2. For fresh `composer create-project` installations: Add the flag directly to the create command:
```bash
sudo -u www-data composer create-project wintercms/winter example.com "dev-develop" --no-security-blocking
```
3. Optional permanent bypass (not recommended for production): Add the following to your `composer.json` `config` section to ignore the specific advisories or fully disable insecure package blocking:
```json
"config": {
  "audit": {
    "ignore": ["PKSA-8j6w-3kr7-s9xk", "PKSA-6j95-1jtb-x6wc", "PKSA-cbx2-m9db-bmzd", "PKSA-4g5g-4rkv-myqs"],
    "block-insecure": false
  }
}
```
4. Optional cache permission fix: Resolve the "Cannot create cache directory" warning by updating ownership of the Composer cache path:
```bash
sudo chown -R www-data:www-data /var/www/.cache/composer
```

Security warning: This workaround deploys a version of `enshrined/svg-sanitize` with known vulnerabilities. Remove the bypass configuration once Winter CMS releases an update that uses a patched, non-vulnerable release of the dependency.

Question 4

How to fix Winter CMS plugin "Class not found" on Linux when autoloading works on macOS?

Accepted Answer

This happens because macOS is case-insensitive while Linux is case-sensitive. Winter CMS's plugin autoloader supports either consistent PSR-4 directory casing or the legacy lowercase structure, but not a mix of the two.

For the namespace `Aic\Account\Classes\DTO\OrderPallet`, use the PSR-4 path:

```text
plugins/aic/account/Classes/DTO/OrderPallet.php
```

Alternatively, use the legacy lowercase path:

```text
plugins/aic/account/classes/dto/OrderPallet.php
```

If you need to keep a custom path such as `classes/DTO/OrderPallet.php`, add an explicit PSR-4 mapping in `composer.json`:

```json
{
  "autoload": {
    "psr-4": {
      "Aic\Account\Classes\": "classes/",
      "Aic\Account\": ""
    }
  }
}
```

Then run:

```bash
composer dump-autoload
```

Question 5

Why does Winter CMS show 'parse error: failed at <?php' when compiling SASS?

Accepted Answer

A known issue causes the editor to incorrectly add '<?php' to SASS files. Manually remove the '<?php' tag from affected .scss files via filesystem (not via Winter CMS backend). After removal, recompile assets normally.

Winter CMS

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects