wintercms / winter Goto Github PK
View Code? Open in Web Editor NEWFree, open-source, self-hosted CMS platform based on the Laravel PHP Framework.
Home Page: https://wintercms.com
License: MIT License
Free, open-source, self-hosted CMS platform based on the Laravel PHP Framework.
Home Page: https://wintercms.com
License: MIT License
Refs: octobercms/october#2726
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
.
Refs: octobercms/october#3116
RainLab.GoogleAnalytics
1.3.0Clicking on fileupload
form widget, displays modal with Attachment URL link for private
files:
fileuploader
widgetRefs: #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.
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
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_recordswhere
unread= 1 and
martin_forms_records.
deleted_at is null)
In PluginEnable.php line 47:
Attempt to assign property "is_disabled" on null
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).
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.
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
Setting a sensitive
form field to readOnly
doesn't stop the display of the password when clicking the view button.
And the following to fields.yaml
:
test_api_key:
label: Test API key
placeholder: Enter key
type: sensitive
readOnly: true
develop
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.
StaticPage
component)/home
/home
. At this point, we would expect the slug to be /welcome
.Need to review and merge octobercms/october#5298
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.
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#4561. @mjauvin did an initial implementation in octobercms/library#537
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:
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:
General:
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:
{{ media(path, optionalDisk).mediaItemPropertyOrMethod }}
Perhaps take some extensibility inspirations from https://github.com/ctf0/Laravel-Media-Manager
We should support more ways to install plugins:
These methods should exist in the plugin:install command with a --from=
option and in the backend plugin manager.
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%
Refs: octobercms/october#5195
Review and implement octobercms/october#5470
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).
Refs: octobercms/october#5530
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
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
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
Route::get('sitemap.xml', [\Radmin\Client\Classes\Http\Controllers\SitemapController::class, 'index'])
->middleware(['web'])
->name('sitemap');
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 |
+--------+----------+-------------+---------+----------------------------------------------------------------+------------+
Refs: octobercms/october#5516
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.
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~~~~~ 88
8b .. ... ..
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 ';'`
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".
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 !
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
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:
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
The Quick Start says:
Login to the backend with the username
admin
and passwordadmin
.
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.
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.
Use admin:admin
as specified on the docs to access the backend.
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.
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.
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.
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.
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.
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.
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.
Themes are in the same boat as plugins if you have purchased them from the marketplace.
Winter CMS is available now! See the guide on our website for how to switch to using it.
See the guide on our website
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!
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:
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
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.
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.
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
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.
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.
Refs: octobercms/october#5453
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.