PiranhaCMS / piranha.core

Piranha CMS is the friendly editor-focused CMS for .NET that can be used both as an integrated CMS or as a headless API.
http://piranhacms.org
MIT License
1.93k stars 549 forks source link

Developer Productivity #1114

Open tidyui opened 4 years ago

tidyui commented 4 years ago

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

Infrastructure

Docs

nhaberl commented 4 years ago

Fully fledged developer docs :) In form of text but also maybe some webinars / videos.

goranhell commented 4 years ago

Your planned new IList with abstract or interface classes would be great for me

tidyui commented 4 years ago

@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!

j2ba commented 4 years ago

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.

mikaellindemann commented 4 years ago

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)

tidyui commented 4 years ago

Btw @j2ba As we release version 8.2 xml-comments will be included in the nuget-packages enabling inline docs when programming.

121GWJolt commented 4 years ago

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.

psandgren commented 4 years ago

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

nhaberl commented 4 years ago

@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.

tidyui commented 4 years ago

@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.

tidyui commented 4 years ago

@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

121GWJolt commented 4 years ago

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!

nhaberl commented 4 years ago

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.

tidyui commented 4 years ago

@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?

goranhell commented 4 years ago

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.

nhaberl commented 4 years ago

@goranhell I think some kind of batch editing in general would be of great benefit.

nhaberl commented 4 years ago

@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

No need for full IDE in manager but fine when changing a variable in scss and compile it and site is updated.

psandgren commented 4 years ago

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.

tidyui commented 4 years ago

@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.

tidyui commented 4 years ago

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
MehranDHN commented 4 years ago

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.

tidyui commented 4 years ago

@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

jbrozek commented 4 years ago

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.

tidyui commented 4 years ago

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:

  1. Have a block library where you can create blocks in advanced
  2. When you add a block to a page you get to choose between creating a new or picking an existing.
  3. 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.
biapar commented 4 years ago

OAuth2 support out the box,

jensbrak commented 3 years ago

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.

jensbrak commented 3 years ago

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.

CrossBound commented 3 years ago

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.

m5x commented 3 years ago

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.

andi0b commented 2 years ago

I hope this is the right spot to add some maybe new ideas: