wintercms / winter Goto Github PK

Hi there,

after moving to WinterCMS, controllers lists got broken. As you can see from the attached image, the title column content is invisible because an inline "display: none;" style is attached somehow. I didn't managed to solve this issue and I don't understand why this happens only on that column. Hope there's a solution. Thank you for your efforts.

columns:
    title:
        label: Title
        type: text
    status:
        label: Completed
        searchable: false
        sortable: true
        type: switch
        width: 10%

Result:

The plugin replacement functionality is nearly perfect, but maintaining data integrity is still a bit tricky. It would be ideal if we had a MigrationHelper that could do the following:

• Rename Settings model's codes (this could potentially be done at the core level with aliases, or we could just not rename these in the first place)
• Iterate over all models in the plugin & all of their relationships that store class information in the database (i.e. attachOne, attachMany, morphOne, morphMany, all when not using a morph map) and run migrations to migrate the data in the database to support the new class names.

Ideally this helper would also support being run in reverse.

NOTE: We could also explore the idea of having Laravel replace these values at the query level seeing as it's highly likely that other plugins could be extending the replaced plugins and referencing those models in their own data structure.

Plugins that should at the very least have manual migrations added to them prior to 1.1.3 being launched:

• Winter.Blog
• Winter.Builder
• Winter.GoogleAnalytics
• Winter.Mailchimp
• Winter.Twitter
• Winter.User

In https://github.com/octobercms/october/blob/develop/modules/backend/widgets/Lists.php#L502-L504 the select property of a column that references a relation with multiple associated record is automatically wrapped in a group_concat() call to automatically concatenate all of the results of the select query into a comma separated string.

This is fine behaviour by default, but a problem arises when attempting to use a DB engine that doesn't support group_concat (i.e. Postgres or SQL Server) or when attempting to do more complex select queries, such as summing a column on all the related records.

A new property, selectAutoConcat(open to suggestions for better names) should so that the current behaviour can be disabled by the developer when they want to handle those more advanced use cases.

Refs: octobercms/october#5461

Refs: octobercms/october#5530

It's great to see the origin of Winter after leaving back October!!! 😁

I gave it a try today because everything went very well, and I liked the CLI install interface.
Only I got an error while installing the Builder plugin through the CLI install menu but showed me 520 origin error.

I also suggest having a marketplace completely based on GitHub.
Is there any way we can directly clone plugins using GitHub API or any other way from PHP and install them in winter.
Not sure if I am sounding meaningful, but I don't like the idea of having a marketplace server, as someone has to maintain it and if something like October happens then there is no way anyone can depend on it.

We should add a preprocessor to YAML files to prevent the breaking changes in newer versions of symfony/yaml from affecting the ecosystem (i.e. unquoted string keys that could be interpreted as numbers no longer work in newer versions).

Refs: octobercms/october#5271

Originally reported by @multiwebinc in octobercms/october#5523.

With the current markdown editor in split mode, a request is sent to the server for every single keystroke. This doesn't play well with DDoS prevention mechanisms, such as Apache's mod_evasive, which quickly causes a 403 error after just a few keystrokes. Would it be possible to use a client-side markdown parser, or at the very least throttle the number of requests sent to the server to something more sensible?

It should be possible to throttle the requests after a given delay of no keystrokes, if that hasn't already been implemented (I seem to remember something similar being implemented, but I can't remember if it was specifically for the markdown widget or something like the search field).

General:

• This is a progressive enhancement that will live in the System module. Simply check if app::hasDatabase() or something similar before registering event listeners
• Media Manager should have integrations with the Form widget to simply extending it
• Perhaps handle rainlab/translate-plugin#192 as a part of this

Schema:

Table Name: media_library_items
id // To simplify other people's relationships to Media Items
disk // To distinguish between multiple files stored on different disks
path // The path to the media item
metadata // JSON stored metadata.
timestamps?

Model:

Name: MediaItem
Interface:
MediaItem::fromPath($path, $disk = $defaultDisk) // Gets the Media metadata for the specified path
- Provide method to load metadata directly from the identifier passed that would override the stored metadata. I.e. Path could be either a string or an array containing overriding metadata.
- Perhaps have getAttribute() attempt to pull unknown attributes from the ->metadata->$attribute?
- Perhaps have setAttribute() do the same?
- Take inspiration from https://github.com/kodeine/laravel-meta. 

Interactions:

1. Media Metadata integration will listen to the media events and update the DB reference to the path on the appropriate events
2. Attempting to access a MediaItem that doesn't exist in the DB yet will create it in the DB (perhaps only if it exists in the disk?)
3. Perhaps integrate File Interface for using in the file model and Media Item model?
4. Twig interface should be {{ media(path, optionalDisk).mediaItemPropertyOrMethod }}

Perhaps take some extensibility inspirations from https://github.com/ctf0/Laravel-Media-Manager

Hello dear Team,
Could it be possible to install the same as way below and get an install-master folder ? Currently empty
wget https://codeload.github.com/wintercms/install/zip/master -O wintercms.zip

Wish you all the best to come

Best regards

Hi there,

I have Farm, Order and Component models.
One Farm can have many Components and many Orders; one Order can also have Components.

I have the following Order form:

farm:
    label: 'projectx.dashboard::lang.order.form.farm.label'
    placeholder: 'projectx.dashboard::lang.order.form.farm.placeholder'
    required: 1
    showSearch: true
    span: right
    type: dropdown
components:
    context: update
    dependsOn: farm
    deferredBinding: true
    label: 'projectx.dashboard::lang.order.form.components.title'
    type: partial

Property farm allows to set a Farm to which the Order belongs to.
Property components allows to add a Component to an Order.

The following config_relation.yaml

components:
    label: 'projectx.dashboard::lang.order.form.components.entity'
    view:
        list: $/projectx/dashboard/models/componentsorderspivot/columns.yaml
        recordsPerPage: 20
        showCheckboxes: true
        showSearch: true
        toolbarButtons: add|remove
    manage:
        list: $/projectx/dashboard/models/componentsorderspivot/columns.yaml
        recordsPerPage: 20
        scope: byFarm
        showCheckboxes: false
        showSearch: true
    pivot:
        form: $/projectx/dashboard/models/componentsorderspivot/fields.yaml

Please, note the scope: byFarm property in manage section. The scope byFarm is implemented correctly like this in Component model:

public function scopeByFarm($query, $other)
{
    // $other contains the parent model.
    $query->where('farm_id', $other->farm_id);
}

What I want to achieve is to be able to filter the list of Components that is shown in the relation popup by the Farm ID choosen in the farm dropdown without saving and refreshing the page. Currently, I have to select the farm I want, then save and refresh the page. It's like, despite the dependsOn property, the partial does not refresh automatically sending to the backend the old Farm ID instead of the new one selected. dependsOn works just fine between two dropdowns but not in this particular case. I think it's a frontend JS issue, not a backend PHP one.

We should support more ways to install plugins:

• Upload ZIP
• Specify git repo (only if Git binary supported on the system)
• Specify composer package name
• (only on plugin:install command) Specify local folder

These methods should exist in the plugin:install command with a --from= option and in the backend plugin manager.

Per #90,

The Spectrum color picker widget in use with Winter CMS supports exporting of various types of color formats (HSL, RGB, hex, etc.). We could potentially have an option with the widget to allow an alternate color format to be returned and used for certain fields - perhaps format - with it defaulting to hex.

I installed Winter 1.1.3
Then the winter.user installed the plugin:

composer require winter/wn-user-plugin

Now on the page /backend/system/updates there is a message that you need to remove the rainlab.user plugin.

I did not install the rainlab.user plugin.

Refs: octobercms/october#5453

• Winter CMS Build: 18adc4a
• PHP Version: 7.4
• Database Engine: sqlite
• Plugins Installed:
  • Winter.Demo

Description:

When registering named routes in a plugin's routes.php file you are unable to reference them using the route() helper function. However, they do show up in the route list when running php artisan route:list

Steps To Reproduce:

1. Create custom plugin
2. Create routes.php file with a named route:

Route::get('sitemap.xml', [\Radmin\Client\Classes\Http\Controllers\SitemapController::class, 'index'])
    ->middleware(['web'])
    ->name('sitemap');

3. Create a component which references that named route: route('sitemap')

<?php namespace Radmin\Client\Components;

use Cms\Classes\ComponentBase;

class Sitemap extends ComponentBase
{
    public string $url;

    public function componentDetails()
    {
        return [
            'name'        => 'Sitemap Component',
            'description' => 'No description provided yet...'
        ];
    }

    public function defineProperties()
    {
        return [];
    }

    public function onRender()
    {
        $this->url = route('sitemap');
    }
}

routes list:

+--------+----------+-------------+---------+----------------------------------------------------------------+------------+
| Domain | Method   | URI         | Name    | Action                                                         | Middleware |
+--------+----------+-------------+---------+----------------------------------------------------------------+------------+
|        | GET|HEAD | sitemap.xml | sitemap | Radmin\Client\Classes\Http\Controllers\SitemapController@index | web        |
+--------+----------+-------------+---------+----------------------------------------------------------------+------------+

System module, console/commands/WinterInstall.php function displayIntro is displaying October's logo. Not sure if you had an ASCII logo already, so didn't want to submit a PR to fix. DisplayOutro probably also needs changing.

• Winter CMS Build: ###
• PHP Version: 8.0.3
• Database Engine: MySql

Description:

I tried to install a plugin on winter through the OC marketplace but got an error.
So I downloaded the plugin (Magic Form) from the author's repository, I tried to install it php artisan plugin: enable Martin.Forms but it gave me error

In PluginEnable.php line 47:
                                                    
   Attempt to assign property "is_disabled" on null

Steps To Reproduce:

• Download the Magic Forms plugin from the repo https://github.com/skydiver/october-plugin-forms
• Unzip and copy the content in plugins/Martin/forms
• Backend gives me this error
  SQLSTATE[42S02]: Base table or view not found: 1146 Table 'soundmit.martin_forms_records' doesn't exist (SQL: select count(*) as aggregate from martin_forms_recordswhereunread= 1 andmartin_forms_records.deleted_at is null)
• tried php artisan plugin:enable Martin.Forms
• get the error

In PluginEnable.php line 47:
                                                    
   Attempt to assign property "is_disabled" on null

Refs octobercms/october#4561. @mjauvin did an initial implementation in octobercms/library#537

Refs: octobercms/october#5473. Credit to @filipac for the initial work!

I've successfully upgraded a fresh OctoberCMS to use Laravel ^8.0 ( 8.25.0 as of speaking) from Laravel 6 we currently use.
I am sure there is no desire from core team to upgrade to non-lts version for now, but I just want to document what changes should we make to have it working:

• require laravel components ^8.0
• upgrade symfony/yaml in october/rain to ^5.1
• classes in October\Rain\Database\Query\Grammars give an exception because the implementation is not as in parent class. Changed the compileUpsert functions to use Illuminate\Database\Query\Builder instead of October\Rain\Database\QueryBuilder and it worked.
• October\Rain\Events\Dispatcher needed an update especially in listen method cause the signature changed
• in Foundation/Bootstrap/LoadEnvironmentVariables we need to change the way Dotenv::create is called (first parameter now should be \Illuminate\Support\Env::getRepository(), the other 2 parameters remain the same.
• in Exception/Handler we should change \Exception to \Throwable.
  backend/models/brandsetting/fields.yaml needs an update in availableColors keys because the new
• Symfony Yaml parser sees colors as a comment and we get an exception of invalid Yaml. Did not check other yaml files if they include # but we should do that.
• Laravel 9 will require at least PHP 7.4

Otherwise, everything seems to work so far on Laravel 8.0. Not sure what the changes will be in 9.0 which is scheduled for September this year, this will be the next LTS. But from what I've seen on Github, nothing too breaking, just upgrading some components.

I think we should be prepared to upgrade anytime and maybe sometime in the future try to mirror the latest supported version of Laravel (not only LTS) since we will now have only one per year. If we keep piling up versions to upgrade, it becomes a nightmare job. Since October is evergreen and we now have some kind of versioning, I do not see a problem mirroring latest Laravel, especially since we have a wrapper around the framework and not much of our/plugin's code needs to be updated.

Is this repo the best place to have this checklist registered, or is https://github.com/octoberrain/meta more suited?

Just want to help and stay on track with the great Laravel releases, this would be a strong point for us (see Statamic which always supports latest versions of Laravel).

We've been discussing in #5271 about running a pre-processor for Yaml files to gain compatibility with the later versions of symfony/yaml, as all our docs and I would say the vast majority of plugin Yaml files will be using a syntax that is no longer compatible, especially when it comes to the version number keys. This would have to be implemented before we can consider upgrading the Yaml library.

Otherwise, everything looks relatively graceful.

Did you happen to run the unit tests and confirm that everything still passed?

@bennothommo i've run them now. Here's what I found so far

• some tests fail due to invalid yaml in fixtures
• we have to register in the container a new service "mail.manager" - \Illuminate\Mail\MailManager should be extended to suit October's needs
• the mail system is a bit changed, the config file from legacy version still works but the Mail facade now points to the MailManager class.
• Declaration of October\Rain\Database\Pivot::setKeysForSaveQuery(Illuminate\Database\Eloquent\Builder $query) should be compatible with Illuminate\Database\Eloquent\Model::setKeysForSaveQuery($query)
• 1. CmsExceptionTest::testCmsExceptionPhp Error: Class 'Symfony\Component\Debug\Exception\FatalErrorException' not found - the new alternative is \Symfony\Component\ErrorHandler\Error\FatalError
• \October\Rain\Exception\ExceptionBase methods setMask and applyMask should receive \Throwable
• same in \Cms\Classes\CmsException - replace exception with \Throwable
• AttachOneModelTest fails because the signature of UploadedFile changed and file_size is no longer required
• UploadedFile method getClientSize no longer exists, change to getSize in \October\Rain\Database\Attach\File
• MassAsignment no longer works because in laravel it was moved to Concerns\GuardsAttributes and we do not apply it on our model;

When using repeater with maxItems=1, repeater does not work correctly. It adds one record and still shows the button to add one more. When you remove all records and start adding them again, the repeater works as expected.

Test with the Test Plugin using the Countries > Related repeater and setting maxItems: 1

plugins\winter\test\models\country\fields.yaml

Initial report by @GinoPane in octobercms/october#5533

Need to integrate with https://github.com/darylldoyle/svg-sanitizer to automatically sanitize SVGs on upload and then re-add them to the list of allowed defaultExtensions, assetExtensions, and imageExtensions.

Original october#5261

Refs octobercms/october#3568

The ImageResizer will fail with

file_put_contents(/srv/users/website-oc-newcriterion/apps/website-oc-newcriterion/releases/1611303973/storage/app/resized/0a0/086/dae/florence-flood-november-4-1966-view-from-the-south-bank-of-the-arno-river-florence-italy-the-river-rages-just-beneath-the-stone-arches-of-the-ponte-santa-trinita-photo-by-balthazar-korab-7-0-2018-1084-1612117156_resized_0a0086dae485c1984a4b736baeea002370fc98eb.jpg): failed to open stream: File name too long

if it attempts to resize /storage/app/media/florence-flood-november-4-1966-view-from-the-south-bank-of-the-arno-river-florence-italy-the-river-rages-just-beneath-the-stone-arches-of-the-ponte-santa-trinita-photo-by-balthazar-korab.jpg.

Now, why anyone would have files with such long names is beyond me, but the fact of the matter is there isn't anything in the system right now to prevent people from doing silly stuff like that, so it's unhandled when it's encountered.

@bennothommo any thoughts on the best way to deal with this sort of situation? The max path length is generally 255 bytes on most filesystems, but we'd also have to take into account the other parts of the path (the containing folder and the suffix detailing the options and extension).

• OctoberCMS Build: Latest
• PHP Version: 7.2
• Database Engine: mysql
• Plugins Installed: RainLab.GoogleAnalytics 1.3.0

Description:

Clicking on fileupload form widget, displays modal with Attachment URL link for private files:

• https://github.com/rainlab/googleanalytics-plugin/blob/master/models/Settings.php#L23

Steps To Reproduce:

• Navigate Settings > Google Analytics
• Ensure Private Key already uploaded
• Click on fileuploader widget
• Click on Attachment URL

• Winter CMS Build: hiltonbanes/wintercms:build.v1.1.2
• PHP Version:
• Database Engine: mariadb:10.4
• Plugins Installed: none

Description:

The Quick Start says:

Login to the backend with the username admin and password admin.

After install it a random password is generated, which is a problem not only because it is not matching the docs but also when using tools like Portainer, where the generated password is not easy to retrieve.

Steps To Reproduce:

Install WinterCMS with the docker-compose file with database support.

Run:

$ docker-compose up -d
$ docker-compose exec web php artisan winter:up

...

Winter.Demo
 - v1.0.1:  First version of Demo
Seeded System 
Seeded Backend 

\Backend\Database\Seeds\DatabaseSeeder reported:
 - The following password has been automatically generated for the "admin" account: Tnq1g8Uj45itsKnYIkVC7p

Go to the backend page.

Try admin:admin as specified on the docs.

It doesn't work.

Spected Behaviour

Use admin:admin as specified on the docs to access the backend.

Refs: octobercms/october#3116

UPDATE: October CMS has moved to become a locked down paid platform and is no longer free or open source. Winter CMS will always be a free, open source, community driven content management framework.

Former October CMS maintainers Luke Towers, Ben Thomson and Marc Jauvin wish to announce the formation of the Winter CMS project, a community-driven fork of October CMS with a dedication to speed, security, stability and simplicity. Along with Jack Wilkinson, we aim to continue to deliver a professional and feature-rich platform that you can rely upon for your websites and applications; as well as engage the community and become a more community-driven project overall.

As indicated though, this is a fork of October CMS. Though it was a regretful decision, the team were forced to do this after a systemic breakdown in communications over a long period of time between the founders of October CMS and the maintenance team.

Winter CMS will continue down the path of continuous improvement while maintaining a solid base that you can rely on to power your business. We aim to maintain complete compatibility with all of your existing October CMS projects, and as much of the future of October CMS as possible within our goals of stability, speed, security, and simplicity. Winter CMS & October CMS are interchangeable as of v1.1.2 & v1.0.472; and we will continue to put in the work to make your life as a developer as simple as possible by minimizing any breaking changes.

So, what happened?

Between March 3rd-4th 2021, the maintenance team either resigned or were let go from the October CMS project, at the behest of the founders of October CMS.

Why?

This fork is a result of a distinct lack of communication between the founders and the maintenance team that has formed in the past 2 years, mainly from the founders' side, as well as a general lack of engagement by the founders.

Plans and updates that had apparently been in motion for months were thrust upon the maintenance team without warning at the same time the user-base learned about it. Given that said plans and updates could completely change the scope of maintenance for the project, the maintainer team sought some level of information as to what these plans and updates would entail so they could adequately prepare to maintain the project going forward. These requests were denied.

The vast majority of maintenance work, PR review and implementation, issue management and feature development in the last 2-3 years has been because of the maintenance team as well as the community. Unfortunately, during this time, one of the founders of the project barely communicated or contributed to the project. The other, whilst maintaining the marketplace and marketing, did not interact with the community (except for some marketing) nor the maintainer team at all.

When it was evident that the founders were unwilling to communicate or collaborate on the project with the maintainers, some of the maintainers decided to leave the October CMS project. Others were then forced out.

Hasn't this happened before?

Yes it did, in late 2019. Communications and activity from the founders, even at this point, were sorely lacking. Frustrated by this, and a perceived lack of appreciation for the work done by the maintainers from the founders, the maintainers announced their intention to fork. This was, after a day, resolved amicably with the promise of more transparency, hence the maintainer team stayed. See octobercms/october@3e83fba#commitcomment-47920921 for Sam's point of view on how that went down, and https://shopaholic.one/blog/alexey-bobkov-present-and-future-october-cms for Alexey's point of view on the overall situation.

At the time of that fork, the name October CMF was chosen to minimize the disruption and work required to switch between the projects, mostly in the hopes that reconciliation could occur and the project could continue under a single banner. However, this time around in recognition that there are irreconcilable differences between how the maintainer team and the founders view open source projects; we have chosen to completely rebrand under the name Winter CMS.

So, what now?

The founders have made it clear that their intention is to proceed with their plans and handle the maintenance of October CMS themselves. We wish them and their users all the best with this endeavour.

The maintainers have therefore decided that to ensure the stability of the project remains intact, we must fork and rebrand as Winter CMS, forming a new team with a clear vision to improve and iterate the platform in less-destructive ways and in a more transparent fashion.

What does this mean for me?

At this point in time, nothing. You may continue to develop your current projects as before. Plugins and themes developed for October CMS will continue to work in Winter CMS.

The code-bases will only likely diverge with the next release of each product. While the next release of Winter CMS is more iterative, releasing with PHP 8 and Composer 2 support, among several bug fixes and tweaks, it appears that October CMS is intending to release a substantial update which may have an effect on your workflows and plugins. There have already been breaking changes made to the October CMS core (octobercms/october@de897f9, octobercms/docs@8e4b38b, octobercms/docs@8ff67e5, octobercms/docs@971177d, octobercms/docs@42d7837#diff-9900aad8c18afff1066263f6a984dff4ff04be29c1d2791398f39862143e4232R11, octobercms/october#5512 (comment) & octobercms/docs@42d7837#diff-f1c8ca6944983353403f97e69ce7367dc371beb9532d67f84b05f4103f0edd5cR90) and moves toward a more “source-available” mentality than “free and open source” (octobercms/docs@06a3bb3).

Therefore, if you wish to consider your options before proceeding further, we strongly recommend you do not update October CMS past version 1.0.472 or version 1.1.2. You can disable core updates through changing the disableCoreUpdates option in config/cms.php to true, or may lock your Composer dependencies to either of these versions in your composer.json file. You may, however, update plugins as you wish.

You mentioned plugins. What about my plugins?

For Composer plugins, this will not have any effect right now.

For marketplace plugins, while you are still able to access the full marketplace catalogue as well as any paid plugins you may have access to; there is no guarantee that this will continue to work 100% as the October CMS marketplace is completely under the control of the founders. We are hard at work on a replacement marketplace however, and we encourage plugin developers to submit their plugins to this marketplace if they wish to support Winter CMS. We will have more news on this as development continues.

If you want your plugin to remain compatible with either system while considering your options, you may simply lock updates for that plugin through the Plugin & Updates screen, or you may lock your Composer dependencies to the version of the plugin you are currently using.

What about my themes?

Themes are in the same boat as plugins if you have purchased them from the marketplace.

When is Winter CMS releasing?

Winter CMS is available now! See the guide on our website for how to switch to using it.

How do I switch to Winter CMS?

See the guide on our website

How can I keep up to date with the project?

Feel free to join us on Discord, follow us on Twitter, and sign up for our mailing list on our website, https://wintercms.com. The founders have kicked the maintainers out of all community forums that they have admin access to; so we will be engaging with the community via GitHub, the Discord, Twitter, our mailing list, and our website.

Please also feel free to star our repositories on GitHub, that helps us out a lot!

Future plans

Our immediate goal is to finish forking the core RainLab plugins and implementing some quality of life improvements (fixing support for the winter:version command, automated splitting of the module repos for faster access to the latest code); as well as fixing some long standing bugs in the platform. We will then be turning our attention towards Laravel 9 LTS compatibility.

If there are any pending PRs / issues on the OctoberCMS repos that you would like dealt with, please resubmit them here. Moving forwards we will continue to work on new builds as per normal and we will also be working on the main website for the project with the goal of eventually replacing the October CMS marketplace and enhancing it beyond its current feature set. In the meantime, you will still be able to use the October CMS marketplace with Winter CMS.

Our big picture goal is to continue to grow and improve and eventually take over WordPress as the CMS of choice around the world. We would like to thank everyone for their patience and understanding as we move forwards and we look forward to all the excellent work that is to come!

Some of the items on the roadmap:

• Forking RainLab plugins
• Laravel 9 LTS support
• Tailwind support in the Asset Combiner (built in PHP asset compiler) - Replaced by Laravel Mix support in the core
• Backend skin based on Tailwind UI

• Winter CMS Build: Latest
• PHP Version: 7.2
• Database Engine: mysql
• Plugins Installed: N/A

Description

Setting a sensitive form field to readOnly doesn't stop the display of the password when clicking the view button.

Steps To Reproduce:

And the following to fields.yaml:

test_api_key:
    label: Test API key
    placeholder: Enter key
    type: sensitive
    readOnly: true

Refs: #59 (reported by @dhawton)

Currently, ConfigWriter will throw parse errors when manipulating config files with env() calls within while running the winter:install command, as it does not properly parse the entire env() call when doing its replacement. We should try to improve the handling of ConfigWriter to account for this, perhaps by having it just overwrite the default value and leaving the env() call intact.

In addition, it would be a nice-to-have feature to have winter:install change the .env file if it exists from a winter:env call made previously. This would allow people to run winter:env then use winter:install to guide them through the process of changing the configuration in this file.

See wintercms/wn-user-plugin#1 (comment)

namespace should transparently replace to the new namespace, and then the file loader should also support falling back to loading the alias path
i.e. if I ask for winter.blog::some_setting but in my files I have config/rainlab/blog/config.php then it should load from there if the winter.blog version doesn't already exist
and if I ask for rainlab.blog then it should replace to winter.blog like the translator does and continue down the path

See:

• octobercms/october#3952
• octobercms/october#4744

Description:
Tab linking doesn't work for pages, the same applies for CMS pages

Steps To Reproduce:
https://example.com/admin/rainlab/pages#primarytab-thepottingshedcontentblockslangcontent-blockstabscontent-blocks <-- Doesn't reference selected page

Refs: octobercms/october#5135

See:

• octobercms/october#5496
• octobercms/library#560
• octobercms/october#5514

Datatable widget generates wrong attribute data-field-name. In my case, I extend form with fields with keys (data[1][row], data[2][row]), and widget generates name "Report[data[1][row]]". It's because of logic on 155 string at DataTable.php file.

Temporary fix it with change string to
$config->fieldName = $this->getParentForm()->arrayName.'['.implode('][', HtmlHelper::nameToArray($this->fieldName)).']';

I took logic from FormField class.

Refs: octobercms/october#5195

A PR to fix asset minifications for CSS variables broke minification for LESS files.

See. wintercms/storm#22

We need to revisit this to find and fix the issue it created with LESS asset minification.

• Winter CMS Build: develop
• PHP Version: 7.4
• Database Engine: MySQL
• Plugins Installed: Winter.Pages

Description:

Sluggable fields appear to stop working as soon as a form is refreshed. This happens even if the form context is in create and the sluggable field itself has not been modified, so theoretically, the slug should still be tracking the trigger field value.

Steps To Reproduce:

• Install Winter.Pages
• Set up two or more layouts and make them available to the Pages plugin (through the StaticPage component)
• Create a new page in the Pages plugin
• Add a title (say "Home"), the URL field should automatically change to /home
• Switch the layout of the page - this triggers a form refresh.
• Modify the title (say "Welcome"), the URL field no longer automatically updates the slug - it should still remain as /home. At this point, we would expect the slug to be /welcome.

• Winter CMS Build: dev-develop
• PHP Version: 7.4
• Database Engine: MySQL
• Plugins Installed: N/A

Description:

If you run winter:env before winter:install, you'll encounter:

In ConfigWriter.php(45) : eval()'d code line 128:

syntax error, unexpected ',', expecting ';'

Full output:
`daniel@desktop:/mnt/d/VBRP/Brumalia/install$ docker exec -ti -u www-data winter_web bash -c "cd /var/www/html && php artisan winter:install"
.========================================================================.

db d8b db d888888b d8b db d888888b d88888b d8888b. ...
88 I8I 88 88' 888o 88 88' 88' 88 8D ... ..... ... 88 I8I 88 88 88V8o 88 88 88ooooo 88oobY' .. ... .. Y8 I8I 88 88 88 V8o88 88 88~~~~~ 888b .. ... ..
8b d8'8b d8' .88. 88 V888 88 88. 88 88. ... ..... ...
8b8' 8d8' Y888888P VP V8P YP Y88888P 88 YD ...

`============================= INSTALLATION =============================

Database type [SQLite]:
[0] MySQL
[1] Postgres
[2] SQLite
[3] SQL Server

0

MySQL Host [localhost]:

mysql.home.hawton.io

MySQL Port [3306]:

3306

Database Name [database]:

brumalia

MySQL Login [root]:

root

MySQL Password []:

--snip, even though it's a dev test env--

In ConfigWriter.php(45) : eval()'d code line 128:

syntax error, unexpected ',', expecting ';'`

Steps To Reproduce:

1. composer create-project wintercms/winter test dev-develop
2. php artisan winter:env
3. php artisan winter:install

Additional info:

It appears the preg_replace is catching the "redis" array's default item, and changing that as well. When I attempted to debug the eval'd contents, this is what was being passed to eval:

`<?php

return [

/*
|--------------------------------------------------------------------------
| PDO Fetch Style
|--------------------------------------------------------------------------
|
| By default, database results will be returned as instances of the PHP
| stdClass object; however, you may desire to retrieve records in an
| array format for simplicity. Here you can tweak the fetch style.
|
*/

'fetch' => PDO::FETCH_CLASS,

/*
|--------------------------------------------------------------------------
| Default Database Connection Name
|--------------------------------------------------------------------------
|
| Here you may specify which of the database connections below you wish
| to use as your default connection for all database work. Of course
| you may use many connections at once using the Database library.
|
*/

'default' => env('DB_CONNECTION', 'mysql'),

/*
|--------------------------------------------------------------------------
| Database Connections
|--------------------------------------------------------------------------
|
| Here are each of the database connections setup for your application.
| Of course, examples of configuring each database platform that is
| supported by Laravel is shown below to make development simple.
|
|
| All database work in Laravel is done through the PHP PDO facilities
| so make sure you have the driver for your particular database of
| choice installed on your machine before you begin development.
|
*/

'connections' => [

    'sqlite' => [
        'driver'   => 'sqlite',
        'database' => env('DB_DATABASE', 'storage/database.sqlite'),
        'prefix'   => '',
    ],

    'mysql' => [
        'driver'     => 'mysql',
        'engine'     => 'InnoDB',
        'host' => env('DB_HOST', 'localhost'),
        'port' => env('DB_PORT', 3306),
        'database' => env('DB_DATABASE', 'database'),
        'username' => env('DB_USERNAME', ''),
        'password' => env('DB_PASSWORD', ''),
        'charset'    => 'utf8mb4',
        'collation'  => 'utf8mb4_unicode_ci',
        'prefix'     => '',
        'varcharmax' => 191,
    ],

    'pgsql' => [
        'driver'   => 'pgsql',
        'host' => env('DB_HOST', 'localhost'),
        'port' => env('DB_PORT', 5432),
        'database' => env('DB_DATABASE', 'database'),
        'username' => env('DB_USERNAME', ''),
        'password' => env('DB_PASSWORD', ''),
        'charset'  => 'utf8',
        'prefix'   => '',
        'schema'   => 'public',
    ],

    'sqlsrv' => [
        'driver'   => 'sqlsrv',
        'host' => env('DB_HOST', 'localhost'),
        'port' => env('DB_PORT', 5432),
        'database' => env('DB_DATABASE', 'database'),
        'username' => env('DB_USERNAME', ''),
        'password' => env('DB_PASSWORD', ''),
        'prefix'   => '',
    ],

],

/*
|--------------------------------------------------------------------------
| Migration Repository Table
|--------------------------------------------------------------------------
|
| This table keeps track of all the migrations that have already run for
| your application. Using this information, we can determine which of
| the migrations on disk have not actually be run in the databases.
|
*/

'migrations' => 'migrations',

/*
|--------------------------------------------------------------------------
| Redis Databases
|--------------------------------------------------------------------------
|
| Redis is an open source, fast, and advanced key-value store that also
| provides a richer set of commands than a typical key-value systems
| such as APC or Memcached. Laravel makes it easy to dig right in.
|
*/

'redis' => [

    'client' => 'predis',
    'cluster' => false,

    'default' => 'mysql',
        'password' => env('REDIS_PASSWORD', null),
        'port' => env('REDIS_PORT', 6379),
        'database' => 0,
    ],

],

/*
|--------------------------------------------------------------------------
| Use DB configuration for testing
|--------------------------------------------------------------------------
|
| When running plugin tests Winter CMS by default uses SQLite in memory.
| You can override this behavior by setting `useConfigForTesting` to true.
|
| After that Winter CMS will take DB parameters from the config.
| If file `/config/testing/database.php` exists, config will be read from it,
| but remember that when not specified it will use parameters specified in
| `/config/database.php`.
|
*/

'useConfigForTesting' => env('DB_USE_CONFIG_FOR_TESTING', false),

];`

Notice redis.default is no longer an array, but a string of "mysql".

Need to review and merge octobercms/october#5298

• Winter CMS Build: v1.1.2
• PHP Version: 8.0.3 (issue probably related to PHP 8)
• Database Engine: SQLite [not related to DB engine]
• Plugins Installed: [not related to plugins]

Description:

CMS back-end Media manager throws

Symfony\Component\Debug\Exception\FatalThrowableError: imagecolorsforindex(): Argument #2 ($color) is out of range in /srv/bucketbear.club/vendor/winter/storm/src/Database/Attach/Resizer.php:127

error (and shows error popup - 1) when trying to generate thumbnail image of gif image. No thumbnail image is generated at the end - the loading indicator is executing infinitely (2) and the same behavior happens again if clicking on image later.

Preview of issue:

Steps To Reproduce:

1. Open CMS Media manager;
2. Upload gif image, for example, Example image 1 or Example image 2 - although probably many gif images are affected;
3. Click on uploaded image into Media manager to view file info and preview - error is thrown.

Additional Info And Possible Fixes:

Probably this issue is similar as described in ProcessWire imagecolorsforindex(): Argument #2 ($color) is out of range and StackOverflow: What could cause a “color index out of range” error for imagecolorsforindex()?

For experimenting purposes I was trying to modify 127 line in vendor/winter/storm/src/Database/Attach/Resizer.php file - changing it to

$alphaColor = imagecolorsforindex($this->image, $alphaIndex -1);

or

$alphaColor = imagecolorsforindex($this->image, $alphaIndex - 2);

solved problem for some gif images. Seems that there should be additional check for image pallet size as described in linked StackOverflow question.

Refs: octobercms/october#5516

Hello, I started a project 1,5 year ago and it's still not finished because what I designed with widgets, with Builder in the backend was not all available in the frontend (ie repeater).
Then I moved for the frontend to vue.js and started to use October as a headless CMS (missing GraphQL).
I would greatly love in Winter to have the same widgets (functionalities) both in backend and frontend, then not needing a Javascript frontend...
Long life to Winter !

See octobercms/october#3227

Review and implement octobercms/october#5470

Refs octobercms/october#3124

Refs: octobercms/library#534 & octobercms/docs#496

We should integrate the final results from octobercms/october#5519. @meesiris if you're willing to resubmit the PR here, that would be appreciated, otherwise this will be targeted for inclusion in v1.1.3.

Refs: octobercms/october#2726

Refs octobercms/october#2886 & octobercms/docs@42d7837