piranha.core
piranha.core copied to clipboard
PiranhaCMS
Developer Productivity
We want to take some time and focus on features that will improve developer productivity during projects. We need input from all of you creating awesome solutions with Piranha with what would increase your productivity the most!
Features
- [ ] Add templated user types for handling different user groups
- [ ] Multiple block section (#1598)
- [x] Batch operations for Media in the manager (#1174)
v8.3 - [x] ~~Abstract classes in list regions (#1113)~~ (Not supported by current data model)
- [ ] Allow for
IdentityUserclass to be replaced (#822) - [x] Add support for reusable blocks (#290)
v8.4(Implemented with generic content) - [ ] Specify child types to a page (#231)
- [x] Add template options for faster project creation
v8.3
Infrastructure
- [x] Add SourceLink (#1153)
v8.3
Docs
- [ ] Improve overall documentation
- [ ] Add tutorial (custom data)
Fully fledged developer docs :) In form of text but also maybe some webinars / videos.
Your planned new IList with abstract or interface classes would be great for me
@nhaberl As we think everything is self-explanatory and that the code is obvious you have to be more specific for things to improve 🤪 Please add issues at the piranha.core.docs repo and we’ll do our best to make it available!
SourceLink for the Nuget packages. It would be nice to quickly start a project with the Nuget packages in a clean environment (VM for example) and still be able to debug, step into Piranha.Core when needed.
How about a guide/tutorial on how to make editors with custom data - e.g. having an Employee library (could be an archive with posts representing employee data such that it is itself editable from the manager) and selecting one such employee from a custom field in an unrelated page.
This might not be the intended way of accomplishing the case in Piranha, but then maybe there should be a page comparing Piranha against other CMS's content structure and how to rethink the problem to fit it to Piranha.
(Maybe this should have been created on the docs repo)
Btw @j2ba As we release version 8.2 xml-comments will be included in the nuget-packages enabling inline docs when programming.
Personally I think the one thing that would be cool is if we can add extra roles to the doc or add our own IdentityUser classes. That would greatly help with several things I'm doing and currently there aren't any particular things the default user class requires other than using GUIDs instead of strings (as best as I can tell at least). I think it'd be possible to do this.
If not, maybe do it in reverse. Add a way to add custom roles to the role list, and a way to inherit from Piranha's IdentityUser to reuse it in a separate context (I've done this myself in cases where necessary).
ISecurity is great but being able to make use of the user and role pages without having to fork the library could be really helpful.
One feature that would improve QoL for both developers and editors would be to be able to limit child pagetypes. This would help to minimize user errors and help clean up code to handle the extra cases. #231
@121GWJolt I totally agree, it would be great to handle backend and frontend users differntly. Umbraco has a similar concept, where backend users are just named USERS and frontend users named MEMBERS.
Would love to see that in Piranha. It would be also great if those would be different Identity contexts, so as a developer would benefit of managing frontendbusers by the full fetured asp.net identity stack rather than mixing it up with backend users.
@nhaberl @121GWJolt We've discussed this in the past, and if we want different types of users, the optimal solution would be to leverage the templated content system already available and allow for the creation of different User Types that could be imported just like Page Types and Post Types. Then you could use Fields and Regions to specify whatever data or collection data you'd want for a type of user.
@121GWJolt Roles can just be added through the manager interface, custom claims can be added easily in the application startup, see:
https://piranhacms.org/docs/architecture/authentication
Hmmmm, I think the templating system for users could work like that! So long as the template could inherit from IdentityUser I think it'd satisfy most use cases.
OOOO I didn't realize the roles feature was added. I'll have to start using that, thank you!
A great benefit would be if sass / scss files can be compiled within backend to let devs create different versions of pages in seconds. Same to TypeScript.
Related to this also the bundling of static ressources of course. https://github.com/Taritsyn/LibSassHost is helpful here I think although it's maybe better to abstract it to eventually integrate your own / online compiler.
@nhaberl Please elaborate, I’m not quite following you. Do you mean the ability to handle and update client resources (scss,js,etc) from the manager? Do mean on site level?
If you want to restructure your files in your media folders it can be tedious. Would be great if you can mark your files (checkboxes maybe) and then move/delete/... the whole batch.
@goranhell I think some kind of batch editing in general would be of great benefit.
@tidyui yes, organizing static ressources totally in manager. In my case I often have to change a little css ... now I have to move to my ide and build scss files manually or over build but would be great if I can change all in manager.
Summarized
- manage scss / css
- compile scss files
- manage ts / js files
- compile ts files
- managing js and css bundles
No need for full IDE in manager but fine when changing a variable in scss and compile it and site is updated.
That is an opinionated topic, but I strongly disagree. Updating resources, views and code is something that I would really like to not have in the manager. Partly because having it 100% code first is something I prefer, but also because the amount of complexity that comes with combining it, like with Umbraco. When deploying code through different environments like dev->test->prod, having extra styles saved in the db or locally on that machine screws up the deployment flow. I strongly think there should be a clear separation between code and content, like it is today.
- If you want to be a superninjacoder on the road, there are some cool online IDE's that solves your problem, as long as you have a CI/CD-pipeline running. Like Visual Studio Online
@psandgren We have not added these kinds of features in the past as Piranha is not an integrated CMS, however we're looking at these kinds of things for the future BUT how we could provide it as an extra layer on top of Piranha adding more integrated features.
I'm adding one feature here as well that we're working on which will eliminate a lot of question we get and that is "Adding options to the project templates". This means that can specify the setup you want when creating your project instead of having to modify it and change references the first thing you do. This would for example create a new project with SQLServer and Azure BlobStorage:
dotnet new piranha.empty -d SQLServer -s BlogStorage
I wonder does the hooks are for implementing the Publisher/Subscriber pattern in Piranha in the future? Notifying about the important events such as creating Sites and adding Pages to them are important for real-time monitoring of CMS-level events. BTW I'm truly excited about Specify child types to a page. Thanks.
@MehranDHN Well first off you can create different roles so editors can't publish changes, only create and edit pages. Then you could also use the OnAfterSave() hooks for Pages & Posts to do something custom, like notifying the person that should publish the content.
However, we're doing a lot of additions focused on productivity and workflow, so if we can come up with a solution that is not completely overkill we could include that out-of-the-box
Standalone Blocks, I don't see a way to do this yet, but it would be nice.
Within the manager, blocks are always contained within a page structure. It would be useful for an alternative area in the manager that would allow the user to create blocks (or sets of blocks) and then assign a "slug" to the container for easy retrieval via the API. I have this scenario where we have a contact form that is custom so I don't want to create a managed page, but an area of the that contact page could be a standalone block that I could then render and control via the manager.
Hi @jbrozek We have an issue that has been moved several times (#290) which I think would cover your use-case. The idea here is to:
- Have a block library where you can create blocks in advanced
- When you add a block to a page you get to choose between creating a new or picking an existing.
- When you create a new block on a page you can mark it as "reusable" which effectively makes it available in the shared block library.
I'd love a more comprehensive tutorial of extensions. For instance, adding a simple module is straight forward using existing documentation. But if it should expose some persisted settings in the Manager things get more complex fast. The tutorial does not need to cover all steps in detail but could point out all steps required or to consider.
Another approach would be to make a complete sample, extending the existing one. Perhaps as an advanced "part two". A simple persisted option in Manager to reflect the Module setting there, along with whatever demo function it provides for the framework. And possibly a sample project using the feature.
Hooks might be candidates for some more details too, what they do and don't do to set expectations right.
Yeah, OAuth2 would be nice. But a good start would be to have some documentation and/or code samples or even templates using some sort of basic authentication. Starter points for anyone wanting to add SSO anyways.
I vote for the re-usable blocks idea. There's been a issue around for a while #319 that basically is what I'm looking for. Specifically, If I have a client that we want to be able to create a blog page for, I want a specific "blog page" (or whatever) template that they can choose and just simply fill in the blanks.
If this thread is still open I'd like to vote for a built-in support for coders, i.e. people who write front-ends in HTML/JS/TS communicating through e.g. a REST API but do not work with .NET. This role should be able to upload and manage files in wwwroot or designated subdirectories and edit HTML/JS/TS files with built-in syntax highlighting editor.
I hope this is the right spot to add some maybe new ideas:
- Sections: I'm missing the concept of sections. Instead of having multiple pages a lot of sites only use one main page with a lot of sections. The menu just moves you around. There are now two options to handle it: 1. Create a Section as Content, which is not versioned, or 2. Create a subpage for every section and render it on the main page
- I'm missing a lot of features in blocks or block types:
- Icon Fonts
- A custom HTML block (i know there is one in the docs)
- More advanced grid layout (breakpoints, different sizes, etc.)
- A way to set CSS classes on blocks and an UI for users to chose from
- or the posibility to extend blocks with Field properties, so you can add behavior to existing blocks without creating/altering their vue component. For example add a CheckBoxField "IsSepia" to an ImageBlock
- Menus that are not only based on the sitemap, like wordpress has it. Currently i have my own type for that (Content with a List of Links/Texts)
- A LinkField type, that can either link a page, a post or an external URL and a title+target (like the link popup plugin in tinymce), currently I use simple StringField
