-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE: Added icon selection #6872
base: 2.6
Are you sure you want to change the base?
Conversation
How would currently the configuration of the content type? How and who is loading the To be with the naming consistent we should go with We should discuss how we make it possible to have multiple providers not only
How we handle if the |
Maybe we need some configuration in the sulu_admin for this new field type: sulu_admin:
icon_sets:
website:
provider: icomoon
options:
selection_json: '%kernel.project_dir%/assets/website/selection.json'
other:
provider: fontawesome <property type="single_icon_select">
<params>
<param name="icon_set" value="website"/>
</params>
</property> To get the information to the frontend we maybe need an additional controller. |
As discussed I think the best would be that we reuse existing components like the https://github.com/sulu/sulu/blob/2.5/src/Sulu/Bundle/AdminBundle/Resources/js/containers/SingleListOverlay/README.md to fetch the For this we mostly need to create our own Adapter for lists via the listRegistry. But lets check what maybe @niklasnatter has as input here. |
7b72926
to
9d758ee
Compare
@wachterjohannes @luca-rath @alexander-schranz I fixed the checks except for one node lint error that i don't know how to fix. Maybe you know how to fix it? also a code review needs to be made :) thank you |
src/Sulu/Bundle/AdminBundle/Resources/js/components/SingleIconSelect/SingleIcon.js
Outdated
Show resolved
Hide resolved
src/Sulu/Bundle/AdminBundle/Resources/js/containers/Form/fields/SingleIconSelect.js
Outdated
Show resolved
Hide resolved
type Props = FieldTypeProps<?string> | ||
|
||
@observer | ||
export default class SingleIconSelect extends React.Component<Props> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as this is implemented using a list overlay now, i guess it would be more consistent to call it SingleIconSelection
(same for the name of the field type and content type). but i am not sure if you already talked about this and if there are good reasons to keep select
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, we should add basic test cases for the component before merging it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-schranz @niklasnatter we talked about that but i think this was before the implementation with lists... should we use select or selection? Also i would appreciate some help with the test cases...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you dont need to worry about the tests too much. if everything else works, i can add the test cases 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexander-schranz what about the naming? select or selection?
onClick?: (id: string | number, selected: boolean) => void, | ||
}; | ||
|
||
export default class SingleIcon extends React.PureComponent<Props> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as far as i see, this component is not used by the SingleIconSelect
component directly (only indirectly via the IconAdapter
).
therefore i would prefer to make this consistent to the MediaCardAdapter
and call it IconCard
and store it in a separate folder (components/IconCard
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, we should add basic test cases for the component before merging it
src/Sulu/Bundle/AdminBundle/Resources/js/containers/Form/fields/SingleIconSelect.js
Outdated
Show resolved
Hide resolved
src/Sulu/Bundle/AdminBundle/Resources/js/containers/List/adapters/IconAdapter.js
Outdated
Show resolved
Hide resolved
src/Sulu/Bundle/AdminBundle/Resources/js/containers/List/adapters/IconAdapter.js
Outdated
Show resolved
Hide resolved
src/Sulu/Bundle/AdminBundle/Resources/js/containers/List/adapters/IconAdapter.js
Outdated
Show resolved
Hide resolved
import AbstractAdapter from './AbstractAdapter'; | ||
|
||
@observer | ||
class IconAdapter extends AbstractAdapter { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to add basic test cases for the component
$icons = []; | ||
$path = $iconSet['options']['path']; | ||
|
||
// TODO maybe do this in a compilerpass to avoid file system access in the runtime |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you think @alexander-schranz?
380d8b9
to
3b6a61f
Compare
3b6a61f
to
72629e7
Compare
@tommysonsylverstone I did today stumble over your created project: https://github.com/sevenGroupFrance/sulu-icon-picker-bundle. It would be great to get your feedback about this implementation here if it would also match your usecase. |
Hello Alex, I'll try using this wip feature asap. Our icon picker is still far from perfect (like, no fontawesome providers like yours, only icoMoon support etc). |
@alexander-schranz will this be merged soon? |
@popoplanter I hope to get some feedback first from @tommysonsylverstone and @Webstores /cc @kleinkoerkamp which have similar usecases for there projects. To make sure we are not forgetting something here. But definitly this is planned to be merged before releasing 2.6. |
Hello @alexander-schranz I tried installing the feature by pulling the |
@tommysonsylverstone It should be there but it is named currently |
@alexander-schranz will this be merged soon? |
@0xJas0n somebodyshould first rebase it and tackle the failing CI before it can be merged. |
331d996
to
50a2bb8
Compare
@alexander-schranz I did rebase this branch and fixed the pipeline so far. |
Things I think we should change before the merge of this. A. The current configuration we maybe should be more DSN driven to be more flexible:
B. Move the ControllerCurrently the config is inside C. Controller should never access the filesystemCurrently every call of the IconController access the filesystem instead we should prepare a the iconset configuration already in a compiler pass or some cache if we don't want to make the container to big. D. Naming of the content typeShould we name the content type / field type E. Add some basic testsCurrently there are not lot of tests for the new PHP or JS code. |
50a2bb8
to
d64e428
Compare
@alexander-schranz I personally would go with |
@alexander-schranz I would also go with the |
What's in this PR?
Adds the possibility to select icons with a new
single_icon_select
content type, the possibility of multiple icon set providers (icomoon, files),and a simple search to help find the right icon.Why?
A nice selection of icons and how they look is much more user friendly than previous solutions to manage icons such as having a
text_line
where the icon name is provided.Example Usage
Add icon sets:
Use the new content type:
To Do