skripteria / wn-snowflake-plugin Goto Github PK

There could be a new Snowflake type media, or even maybe two new types - mediaimage and mediafile. At the core level they would use this: https://wintercms.com/docs/backend/forms#widget-mediafinder

^ I think some users would like to use existing images, files via Media manager rather than uploading new image, file. Or maybe users simply like the Media manager interface...

First of all, this is not an issue but more like my ideas and comments about _alt and _name attributes in the long term.

Before I go into details - I wanted to thank you about the plugin idea and it's current functionality - although it's in it's early stages (Beta version) and maybe lot of similar things can be done with Static Pages and snippets but I personally see that it has a lot of potential, especially if some more complex field types or site building/editing options will be introduced. I also see some areas where the current code base can be improved, for example, code clean-up (and using PSR-2 standart for code style), enumerated field types, new field types etc. So wait for some PR requests from me. :)

Now back to the topic - in my opinion, _alt, _name and overall syntax of primary field + _ + alternative name may cause some issues in the future:

1. For example, some users may call one SF field my_image and another my_image_alt (e.g., as alternative image for something) - as a two separate, different fields. Same thing can happen also with file type field and _name. In other words, if SF is widely used in site then this kind of variable name collision can happen without users noticing it.
2. If new similar attributes will be introduced then they always will need to be documented. For example, if link type would have new field for specifying target attribute then it probably be _target or similar - but it would be hard for developers to guess this value and it would also increase a chance for creating name collisions (as specified in 1. point) especially for already existing installations and changes so backward compatibility would be hard to maintain.

I am not against the current system but I can see these both problems in future... As a possible solution I can propose to use different syntax for specifying these attributes - either be it - or ., for example, -alt, -name or .alt, .name. I personally probably like dot notation more, I see that something like this was used before but you simplified that in 191137f commit. IMHO, .alt, .name would also be more logical for developers as they would be similar to array or property notation used in programming languages... Also there could be some kind of validator/validation later which would not allow or at least inform devs if they are using - or . symbols in SF Key names so these symbols and the second part of the primary field name would always be reserved for the future functionality and there would be lower risk for backward compatibility breaking changes.

Anyway, this is only my idea and comments. It would be nice if you could give some feedback about this but it's not mandatory.

https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository

^ When you have free time for this. I think MIT license is a way to go. When license is added/configured for the repository then probably reference to it can also be added to https://github.com/skripteria/wn-snowflake-plugin/blob/main/composer.json file as "license": "MIT", property.

You can actually avoid using icons.css file if you replace icon-snowflake with icon-snowflake-o in code so Font Awesome icon from Winter CMS core will be used - https://fontawesome.com/v4.7/icon/snowflake-o

• wn-snowflake-plugin/Plugin.php

  Line 81 in 01d770e

  'icon' => 'icon-snowflake',

• wn-snowflake-plugin/Plugin.php

  Line 107 in 01d770e

  'icon' => 'icon-snowflake'

• wn-snowflake-plugin/components/SfPage.php

  Line 19 in 59518fc

  'icon' => 'icon-snowflake'

Currently I left this on hold because probably #8 should be merged or rejected first.

Discussed in #14

So far this is what I have in mind:

v1.0.2.

• improve content preview to include tyle color. image and file

This may be a little tricky to realize, but I am confident that I have found a makable implementation path to do it. With a partial content field you have access to a $record array that should be good enough to manipulate the output dynamically. At least we should be able to get a decent color preview.

For images I need to experiment with the built in resizer to know more. In theory the resizer should give us way to create a thumbnail in a decent size for the preview.

I tried this plugin but it seems like only the fields on pages are being picked up.
It doesn't show the snowflake fields inside the partials. Did I set it up incorrectly or is this a current limitation?

Last small feature I want to add before I believe V1.0 is ready for final tests and release:

In the list view of the content elements I like to add a short preview of the current content (say first 50 characters). This will not work for images and files but still may help site editors help to keep the orientation.

Any more suggestions?

As I already briefly mentioned in #16 then current Snowflake parser has some interesting behavior in some edge cases, maybe nothing too critical and the most users would not face them but, anyways, at some point in time the current parsing method should be improved.

Current issues:

• Double quotes are not escaped correctly at line

  wn-snowflake-plugin/classes/SnowflakeParser.php

  Line 27 in 525601f

  $param_string = str_replace(['\'', '\"'], '', $param_string);

  it should be str_replace(['\'', '"'], '', $param_string); - because now it tries to replace escaping of double quotes;
• The overall str_replace approach is not very good because it also replaces every other single and double quote which may be in the sf() filter, some examples:

    {{ test_key|sf('text', "tests", 'Test "quote" description...') }}
    {{ test_key2|sf('text', "'tests'", "'Test 'quote' description'...") }}

• As I mentioned in #16 then there is problem with brackets () - probably problem with existing initial regex, some example:

    {{ test_color|sf('color', 'tests', 'Test description (new)') }}
    {{ test_image|sf('image', 'image', 'Test description (new)...') }}
    {{ test_file|sf('file', 'file', 'File description (new)...') }}

^ Everything after the (new is removed;

• wn-snowflake-plugin/classes/SnowflakeParser.php

  Line 29 in 525601f

  $params = explode(',', $param_string);

  - because of the way how commas are processed, there may be issues if commas (,) is used in description or default value parameter.

Hello,

This project seems very interesting, Could it be possible to see some screenshot in the project readme cause It's hard to understand all the concepts under that project.

Thank you

Alex

Can someone fix this error?

Class "Winter\Storm\Support\Facades\Str" not found

In the update of WinterCMS v1.0.2 Winter\Storm\Support\Facades\Str facade has been removed and you can use Winter\Storm\Support\Str directly instead.

https://wintercms.com/releases/v1.2.0

Maybe I am wrong but I didn't find that skripteria_snowflake_types table's column name has any value constrain/validation related to uniqueness. As name column is primary used to identify different types and assign them to SF key elements then, in my opinion, there should be some kind of validation at least in Type model.

In ideal case there should be unique constrain in DB table and in Laravel model. This would avoid situations when, for example, just by accident someone wants to declare new type with already existing name etc.