Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Learn how to create and add new material to the Umbraco Documentation, including updated material for upcoming releases.
There are 2 scenarios for when you are looking to add a new article to the Umbraco Documentation.
You are adding new material to the documentation site.
This includes not-before-documented topics and new tutorials.
You are updating an article for an Upcoming major version.
When you are adding a brand new article to the Umbraco Documentation, there are a few questions that we recommend asking yourself before getting started:
The steps to create, write, and add a brand new article to the Umbraco Documentation are outlined below:
Access the UmbracoDocs GitHub repository.
Fork the repository.
Clone your fork to your local machine.
Create a new branch using the following naming convention: productname/topic
Branch name example: cms/new-content-app-tutorial
Locate the section/folder in the existing structure, where your article fits.
Create a new .md file and name it identical to the title you will give the article.
The file name needs to be all small caps and use hyphens instead of spaces.
File name example: statistics-content-app-tutorial.md.
Write the article.
Ensure the article lives up to our Style Guide and follows the outlined Markdown Conventions.
Add a link to the new article in the file.
Once you have completed the article, submit the branch to your UmbracoDocs fork and submit a PR to the official UmbracoDocs repository.
The documentation is versioned using directories in the root of the repository. The major Umbraco CMS version number is used to name the directories, and you will find documentation for each versioned Umbraco product within them.
The documentation follows the Long Term Support (LTS) strategy for Umbraco CMS. This means that whenever a major version is End of Life (EOL), documentation for that version will be moved to GitHub.
Read the Versioning Strategy article to learn more about how to handle documentation for the different versions.
The following sections of the Umbraco Documentation are following the versioning strategy:
Umbraco CMS
Umbraco Forms
Umbraco Deploy
Umbraco Workflow
Umbraco Commerce
Umbraco UI Builder
The documentation site for an upcoming major version of any of our products will be publicly available with the Release Candidate (RC). At Umbraco HQ we will typically start working with the site 3-4 weeks before, setting up the structure on GitHub.
Once the RC is released, you can find the associated documentation using the version drop-down on the Documentation site.
Only updated and new material for the upcoming release will be available on the published RC documentation on GitBook. This will occur during the RC phase.
All articles will still be available through the UmbracoDocs GitHub repository.
When the final version is released, all the documentation will again be available for that version in the published documentation.
Access the UmbracoDocs GitHub repository.
Fork the repository.
Clone your fork to your local machine.
Create a new branch using the following naming convention: productnameXX/topic
Branch name example: cms15/configuration
Locate the article you need to make changes to.
Make the necessary changes to the article.
After making the changes to the article(s), it needs to be added to the SUMMARY.md file to be published on the documentation site.
Follow the steps below to add the article to the by looking upwards in the file structure.
Locate the article in the SUMMARY.md file for version 14.
Copy the line along with any ancestors.
Siblings to the current and any ancestors should be left out unless they have also been updated.
See the image below for an example of what to include.
Merge what you have copied with the existing structure in the SUMMARY.md file for version 15.
You might experience that the article is already there. In this case you do not need to do anything further.
With the article(s) added to the SUMMARY.md file, the final steps involve creating a Pull Request.
Add and commit the changes.
Submit the branch to your UmbracoDocs fork.
Learn how to provide feedback on the Umbraco Documentation.
There are a couple of different ways to submit feedback on the documentation, be it the entire platform or a single article. This article will give you an overview of the different feedback channels and how to use them.
At the right side of each article in our documentation, you have the option to provide feedback for the content.
You can rate the content from one to five stars.
Once you have selected the number of stars, you can write feedback for the page.
Clicking the small square in the feedback window, you can select an element on the page that you want to highlight with your feedback.
We highly recommend that you share feedback on the articles you come across. This will help us provide better material across the line.
The feedback is used when determining which articles need to be reviewed by the documentation team at Umbraco HQ.
The Issue Tracker is a way to keep track of ideas, issues with wrong or outdated documentation, and discussions with other contributors.
Here are a few examples of what the Issue Tracker can be used for:
You were looking for a specific piece of information, but could not find it.
You found a broken link in one of the articles.
You found an article with wrong or outdated information and you do not have the time or knowledge to rewrite it.
You want to discuss possible improvements or ways to deal with a specific thing in the documentation.
You can add issues directly from the Issue Tracker on GitHub.
We have set up a template that we recommend using when creating an Issue on the tracker. The template gives you a few questions to answer, to help you give the best explanation of what you are reporting or want to discuss.
While most changes are welcome, there are certain types of changes that are discouraged and might get your pull request refused. Of course this will depend heavily on the specific change, but please take the following examples in mind.
Breaking changes (code and/or behavioral) 💥 - sometimes it can be a bit hard to know if a change is breaking or not. Fortunately, if it relates to code, the build will fail and warn you.
Large refactors 🤯 - the larger the refactor, the larger the probability of introducing new bugs/issues.
Changes to obsolete code and/or property editors ✍️
Adding new config options 🦾 - while having more flexibility is (most of the times) better, having too many options can also become overwhelming/confusing, especially if there are other (good/simple) ways to achieve it.
Whitespace changes 🫥 - while some of our files might not follow the formatting/whitespace rules (mostly old ones), changing several of them in one go would cause major merge conflicts with open pull requests or other work in progress. Do feel free to fix these when you are working on another issue/feature and end up "touching" those files!
Adding new extension/helper methods ✋ - keep in mind that more code also means more to maintain, so if a helper is only meaningful for a few, it might not be worth adding it to the core.
While these are only a few examples, it is important to ask yourself these questions before making a pull request:
How many will benefit from this change?
Are there other ways to achieve this? And if so, how do they compare?
How maintainable is the change?
What would be the effort to test it properly?
Do the benefits outweigh the risks?
Help us keep the Umbraco documentation accessible and readable by following our style guide which is defined in this article.
To ensure that the documentation is readable and has a similar style throughout we have defined a set of guidelines to follow. Most of the guidelines outlined here are set up with an automatic style linter called Vale. Additionally, we have a GitHub bot that will check PRs for broken rules and advise you on what to change.
Below you will find a description of each rule the Umbraco Documentation is currently being checked against.
Try to not use any kind of punctuation in headings and headlines. These should act as titles, and no punctuation is necessary.
For consistency, this rule will give a warning if you end headings with either of these punctuation symbols:
?
:
.
The words in the list below will cause a warning when they are included in your contribution.
Try not to use any of the mentioned words, as they are often opinionated. What may be 'easy' for you, might not be easy for another user reading the article.
In most cases, these words can be removed entirely whereas a rephrasing might be necessary in other cases.
Simple
Simply
Just
Easily
Actually
To ensure consistency with grammar and sentences, this rule will give an error if you have a list that starts with uncapitalized words.
An exception to this rule would be when listing items or names that use camelcase.
This rule will give a warning if you have a sentence with more than 25 words.
The rule is added in order to improve the readability of the documentation.
In order to ensure readability and consistency, this rule will warn you if you have more than 1 space in a row in your text.
This rule will give you a warning when using a term that we prefer to avoid in the documentation.
Example: The term blacklist should be avoided and instead replaced with deny list.
For a full list of terms please check the style rule.
This rule is added in order to ensure that Umbraco-specific terms and names are spelled consistently throughout the documentation.
The list of Umbraco Terms includes, but is not limited to Umbraco, backoffice, Document Type, and Umbraco Forms.
All first-time uses of an acronym in the documentation need to be accompanied by a definition of that acronym. If an acronym is not defined on its first use in an article, the checker will give a warning.
Acronyms should be defined using either a parenthesis or a colon followed by the definition.
Examples of the use of acronyms:
In order to ensure that markup languages and other names are capitalized correctly a rule has been added to check for this.
The rule will ensure that instances of HTML and CSS are always written using only capital letters. It will also check whether JavaScript is written in full.
In some cases, throughout our documentation, we refer to other software providers or brands. We have added a rule to ensure that the most commonly used brand names are spelled and capitalized correctly.
The rule will, as an example, ensure that the names Microsoft and Slack are always capitalized.
There are two types of commonly used lists in the Umbraco documentation: ordered lists and unordered lists.
We recommend using ordered lists for sequential task steps and unordered lists for sets of options, notes, criteria, and the like.
In order to keep lists short and to the point, we recommend that you follow these guidelines:
Start each item on the list with the action word.
Add a maximum of two actions per item list.
Keep each list item short and to the point.
Add additional information in one or more sub-list items.
One of the big strengths of Vale is that it is possible for a contributor to run the tests locally before you create a PR. Below are a couple of options on how to test the documentation.
There is an extension for Visual Studio Code that allows you to use Vale as you are writing documentation. It can also be used to run checks on existing articles and find where potential changes are needed.
The extension is called vale-vscode and can be downloaded via the Visual Studio Code Marketplace in your editor.
To use it, you will still have to install a Vale Server on your computer. For more information, see the official Vale installation article.
Once the tools have been installed, a check of the complete repository of articles can be done using the terminal within Visual Studio Code.
Run the following command:
vale --glob='*.md' .
The Vale extension will also run automatically when you are viewing Markdown files. It will present warnings directly in the document as you write, based on the style rules set for the project. It will look similar to this:
The first step to running Vale locally is to install it following Vale's Installation documentation.
Next, you can open a command line tool in the documentation repository and run the following command:
vale --glob='*.md' .
This tells Vale to test all markdown files (.md) in the current directory (.). The output will look something like this:
It will show you what file has issues. In the case above the v8documentation.md the article broke the HeadingsPunctuation rule, and it did so in the following places:
Line 15, column 36
Line 59, column 15
Line 64, column 12
When the check has run you will get the total amount of errors, warnings, and suggestions including how many files have been checked.
Learn how to use Markdown to write articles for the Umbraco Documentation.
The Umbraco Documentation uses Markdown for all articles.
In this article you can learn how we Markdown for different elements on our documentation.
Images are linked using relative paths to .md pages.
The following sample adds an image, img.png, located in an images folder:
Make sure to add a descriptive image text that presents the user with the same information as the image provides.
In the following you will find a few examples of different links.
Include either the complete URL, or link using the following syntax:
When linking between pages in the documentation, link using relative paths. The following are examples of linking to an article.
Link to an article in the same directory as the current article:
Link to an article in a different directory than the current article:
Use the title of the article that is linked to, as the link text. This is done in order to tell the reader what the will find on the other end.
Do not use here or link as the link text, as this provides little to no information about the destination.
It is possible to add a page link that spans the entire width of the page. This is generally used for linking to a new subject related to the article at hand.
The following is a page link that links to the "Submit Feedback" article:
Code formatting comes in 2 variants: inline code and code blocks.
Use inline code when referencing file names and paths as well as actual code the does not extend over multiple lines.
Inline code should be wrapped in ` (backtick) characters.
We follow GitBooks conventions for adding code blocks to our articles.
Four types of hints can be added to our documentation: info, success, warning and danger.
Whether you've found a broken link or want to add a new article to the Umbraco documentation, this article will guide you on your way.
The Umbraco Documentation is presented here on GitBook, however, it is also a GitHub repository and is as open source as the Umbraco CMS.
You can contribute to the documentation if something is missing or outdated. You will need a GitHub account and a fork of the UmbracoDocs GitHub repository.
There are many ways in which you can contribute to the Umbraco Documentation. The approach you choose to take depends on what you want to achieve with your contribution.
Request a quick/minor change to an article by submitting a Pull Request
Submit a more extensive update/change by forking the Documentation repository
Raise a question, start a discussion, or report an issue on the Issue Tracker
Help improve the readability of the documentation by verifying articles against our Style Guide.
We have a few guidelines to follow when writing documentation and we have some tools you can use for it.
The Umbraco Documentation is written using the MarkDown markup language. We have put together an article where you can learn more about MarkDown.
Learn how we structure and name files in the Umbraco documentation.
We recommend using a text editor like Visual Studio Code for making changes to the documentation on your local machine. We do not recommend using an Integrated Development Environment (IDE) like Visual Studio, for making changes to the documentation on your local machine. This is because the IDE may create files in the project which are not needed for the document changes to be implemented.
Whenever a new version of an Umbraco product is released, the previous way of doing things may change. This means that there need to be multiple versions of our documentation.
We do this by keeping documentation for each version in separate folders.
In the screenshot above, two versions are available: 10 and 11. Within each of these folders is the documentation for all the versioned products: Umbraco Forms, Umbraco Deploy, Umbraco Workflow, and Umbraco CMS.
Umbraco Cloud and Umbraco Heartcore are not following the same versioning, which is why they are separate from this structure.
Learn more about how we handle the multiple version of our documentation in the documenting multiple versions and products article.
On both Issues and Pull Requests we use labels to categorize the requests and submissions.
Here's a quick explanation of the labels (colors) we use:
Category (e.g. category/missing-documentation, category/umbraco-cloud, category/pending-release)
Community (e.g. community/pr, help wanted)
State (e.g. state/hq-discussion)
Status (e.g. status/awaiting-feedback, status/idea)
Type (e.g. type/bug)
Labels will be added to your Pull Request or Issue once it has been reviewed.
If your Pull Request to any Umbraco repository gets merged, you will receive a Contributor badge on your profile on Our Umbraco:
When you a contributing to the Umbraco documentation it can be useful to know how we structure directories, files and images.
In this article you will get an overview of the file structure as well as a few best-practices for naming files.
The overall structure of the Umbraco documentation is divided by product. Each Umbraco product has its own directories with articles and images.
Diving one step deeper, each individual topic is contained in its own directory.
Each directory must have a README.md file which will act as a landing page for that directory. If images are used, these must be in an images directory next to the .md file referencing them using relative paths.
/topic (directory)
README.md
another-page.md
/images (directory)
images.png
/subtopic (directory)
README.md
topic.md
another-topic.md
/images (directory)
All file and directory names need to be small-caps in order to be synced properly with GitBook.
If an article is not a landing page, we recommend using the title of the article as the file name.
Images are stored and linked using relative paths to .md pages, and should by convention always be in an images directory. To add an image to /documentation/reference/partials/renderviewpage.md you link it like so:
And store the image as /documentation/reference/partials/images/img.png
Images can have a maximum width of 800px. Please always try to use the most efficient compression, gif or png. No bmp, tiff or swf (Flash).
When adding code snippets to the Umbraco documentation, refer to this article for tips on how to improve the samples.
The articles in the Umbraco Documentation can in most cases benefit from relevant code samples to support the written text.
In this article, you will find guidelines that outline how we recommend formatting and using code samples. We provide definitions and examples of the most used types of code samples in the Umbraco Documentation.
Image here
To ensure quality and consistent code samples, follow these best-practices when adding code snippets.
Define the context
Add a title (file name)
Use code comments
Use real-life samples
Add correct syntax highlighting
Add only complete compilable samples (incl. using statements)
Check for syntax errors
Each of these guidelines is explained in more detail below.
Code samples without context, explanations, and instructions can make the reader run into issues when using the snippet.
Make sure to always add a clear description of what the code sample showcases before or after adding the snippet to the article. It should be clear where and when the snippet can be used.
Inform the reader which file or file type a code snippet should be added to.
Aside from mentioning this in the description of the code snippet, it is also recommended to add the file name as a title.
Is the code snippet from a JSON file, add fileName.json as the caption.
Add the file name to the markup around the code block: <div data-gb-custom-block data-tag="code" data-title='fileName.json'></div>
When adding code samples that contain more than a single feature or method, it is recommended that you add inline comments.
By adding inline comments you avoid having too much text surrounding the code sample, and you also help readers understand the code snippet in detail.
The use of code comments does not eliminate the need for a description of the code sample in the surrounding text.
The documentation often aims to explain complex scenarios and concepts within Umbraco. This means that code samples can be useful to further the understanding. It is important that the code samples are real-life examples.
For example, using variables such as 'foo' and 'bar' can distract from the intent of the example. Aim to use an example that would make sense to add to a production environment.
Try to use placeholders for names, methods, and the like, in order to keep the code samples as neutral and general as possible.
With Umbraco, often there are often more than one way to achieve a result, depending on context and the skillset of the development team. Having multiple examples - for example, a Modelsbuilder version and a non-Modelsbuilder version - can help prevent readers from mixing techniques in their solution. It is fine to provide multiple examples.
When you add code blocks to an article, make sure that you add the correct syntax highlighting. This will "prettify" the code in the sample based on which language is used.
If you are adding a code sample using a language that isn't supported, it is recommended that you add a none label instead.
using statements)A reader of the Umbraco Documentation should be able to grab code samples in the articles and apply them to their own code solution. While there might be a need for some minor alterations, the code in the sample should compile.
Include any relevant Using statements for namespaces that provide 'extension' methods or key functionality.
When reading any piece of text, there is nothing more frustrating than running into spelling and syntax errors. This also applies to code samples.
Any code that is added to articles in the documentation should be double-checked for syntax errors and typos.
The use of file-scoped namespaces improves, among other things, the readability of the code samples. Therefore, use file scoped namespaces in the examples. See below how to use file-scoped namespaces:
Instead of:
Code samples are relevant for most types of articles. Potentially, any topic covered could benefit from a real-life code sample to support the contents of the article.
You might want to base an entire article on one code sample. Alternately, if you're describing a flow or feature, you might want to add smaller code snippets to highlight specific points.
As a basis, we are working with 3 types of code samples in the Umbraco Documentation.
Use inline code when you are referencing methods, using the names of the elements or highlighting a certain value.
Example:
The markdown above will output the following:
As part of longer articles or tutorials, we recommend using smaller code snippets to highlight the bits of code that need to be implemented.
These snippets can be added between sections anywhere in an article without breaking focus from the main topic. Keep in mind that adding too many snippets in quick succession can be confusing to the flow of the article.
Example:
The Razor snippet above will output the following:
As part of tutorials and longer articles explaining a specific workflow, it might make sense to add a full code sample of the topic covered.
We recommend creating separate articles for these large code samples and using them as references, instead of adding them as part of the actual article. Having long snippets in an article that already contains multiple sections and steps can make the article confusing.
It is highly recommended to use line numbers in large code samples. This will make it easier to reference certain parts of the sample in the surrounding text.
There are many ways to contribute to Umbraco. The Contribution Documentation will show you where and how.
Whether you're a seasoned developer, a creative designer, or a passionate user, there are countless ways to contribute to the Umbraco project. From coding and bug reporting to sharing your insights and creating tutorials, your input helps us shape a better experience for everyone.
There are plenty of great reasons to get involved in open-source projects, and when it comes to Umbraco, the benefits are even greater! Here’s why you should consider contributing:
Expand your skill set: Gain valuable experience and learn new technologies.
Boost your career: Enhance your public résumé.
Build your network: Connect with fellow Umbraco enthusiasts and team members.
Learn and unlearn: Discover new insights and challenge your existing knowledge.
Make an impact: Your contributions can help thousands of users. Imagine saying, "I helped fix that bug!" 😎
Impact the planet: We plant a tree for each accepted contribution 🌳
Support the community: Help the hundreds of thousands of Umbraco users benefit from your efforts.
Give back: Contribute to the software you love or tackle that feature you've always wished was different!
So, let’s get those contribution hats on!
Discover where you can make an impact and start contributing.
First off, there's a lot of documentation, and it's not always easy to keep it updated or know if we covered all the details you need to know to follow them. We would love your help to verify the documentation. That is, to follow the docs to the letter and see if you’re successful or missing anything.
Find detailed instructions on how to contribute to the docs directly on the documentation site. Here, we have outlined the steps involved with testing and checking the articles against our style guide. In the same article, you can also learn much more about the rules we’re checking the docs against.
Head on over to the contributing guide for Documentation for the full details.
There are plenty of up-for-grabs issues to look at - a great starting point if you’re not quite sure where to start.
We're also happy for you to work on translations or other problems you might know of that are not on the issue tracker yet.
Head on over to the contributing guide for Umbraco-CMS for the full details.
The UI library contains all the UI elements for the backoffice. These are self-contained components that can be used in any project that needs a UI.
Head on over to the contributing guide for Umbraco.UI for the full details.
Codenamed "Bellissima", this is the replacement for the AngularJS backoffice.
Head on over to the contributing guide for Umbraco.CMS.Backoffice for the full details.
Learn the two different ways to submit a PR to the Umbraco Documentation.
A Pull Request (PR) is a way of submitting changes to an open-source project like the Umbraco documentation.
Let us say you have found a typing or syntax error in one of the articles on the documentation, and you want to correct it. You can do that with a pull request.
There are two ways to create a pull request:
You can either edit a file directly on GitHub, or
You can create a fork of the GitHub repository.
In order to create a PR to the Umbraco Documentation it is required that you have a GitHub account.
GitHub has a functionality that allows you to submit a PR directly from our repository. There is also a button on the right side of every article title, which allows you to jump straight into GitHub to suggest your changes.
Select "Edit on GitHub" from the right-side of the article you want to suggest changes to.
Select the pen icon to start editing the article.
Make the changes.
Add a title and description explaining what changes you have made and why you made them.
Select Propose changes.
Select Create pull request to preview your PR.
Select Create pull request again to create the PR.
This is helpful to fix typing errors or add small things. If you are working on a larger update that includes pictures and editing files then it is not the best way to work. In that case, you will be better off creating a fork. See below for more thorough instructions on this approach.
There are a lot of great tutorials available online on how to fork a repository (GitHub), but we have also created a guide with instructions.
If you do not have Git installed on your machine, you should follow these instructions before you go any further.
Once you have set up Git you can create a fork of the Umbraco Documentation repository.
When you make a fork, you get a copy of the entire repository on your own GitHub profile.
You can create a fork by selecting the Fork option at the top of the screen:
Once the fork has been created you will have your own copy of the Umbraco documentation. If you clone your fork, you will have the files locally which means you can make changes and sync them back up to your fork.
Are you adding a new article to the documentation? Add it to the SUMMARY.md file as well to ensure it is added to the navigation.
When you are satisfied with the changes you have made, you can submit a pull request to sync your copy with the original repository:
When you have had your fork for some time, you need to sync with the original repository before making new changes. This is called a rebase.
Set the original repository (UmbracoDocs) as an upstream to sync from.
Fetch the updates.
Update your own fork.
This can also be done by using the Sync fork option, which will be present once your fork is behind the original repository.
Once you have made some changes and you are happy with the result, you can create a pull request.
Navigate to the Code section on your fork.
Select Contribute and then Open pull request to get started.
Add a title and description explaining what changes you have made and why you made them.
Select Create pull request to create the pull request on the original repository.
Your PR is now subject to review with the Umbraco HQ Documentation team.
We hope to review and resolve all incoming pull requests within a couple of weeks, depending on the extent of the changes.
👍🎉 First off, thanks for taking the time to contribute! 🎉👍
These contribution guidelines are mostly just that - guidelines, not rules. This is what we've found to work best over the years, but if you choose to ignore them, we still love you! 💖 Use your best judgement, and feel free to propose changes to this document in a pull request.
We have a guide on what to consider before you start and more detailed guides at the end of this article.
The following steps are a quick-start guide:
Fork
Create a fork of Umbraco-CMS on GitHub
Clone
When GitHub has created your fork, you can clone it in your favorite Git tool or on the command line with git clone https://github.com/[YourUsername]/Umbraco-CMS.
Switch to the correct branch
Switch to the contrib branch
Build
Build your fork of Umbraco locally as shown in the video below. You can build with any IDE that supports dotnet or the command line.
Branch
Create a new branch now and name it after the issue you're fixing, we usually follow the format: temp/12345. This means it's a temporary branch for the particular issue you're working on, in this case issue number 12345. Don't commit to contrib, create a new branch first.
Change
Make your changes, experiment, have fun, explore and learn, and don't be afraid. We welcome all contributions and will happily give feedback.
Commit and push
Done? Yay! 🎉
Remember to commit to your new temp branch, and don't commit to contrib. Then you can push the changes up to your fork on GitHub.
Create pull request
On GitHub, in your forked repository (https://github.com/[YourUsername]/Umbraco-CMS) you will see a banner saying that you pushed a new branch and a button to make a pull request. Tap the button and follow the instructions.
Want to read further? Creating a pull request and what happens next.
Umbraco HQ will regularly mark newly created issues on the issue tracker with the community/up-for-grabs tag. This means that the proposed changes are wanted in Umbraco but the HQ does not have the time to make them at this time. We encourage anyone to pick them up and help out.
If you do start working on something, make sure to leave a small comment on the issue saying something like: "I'm working on this". That way other people stumbling upon the issue know they don't need to pick it up, someone already has.
Great question! The short version goes like this:
Fork
Create a fork of Umbraco-CMS on GitHub
Clone
When GitHub has created your fork, you can clone it in your favorite Git tool
Switch to the correct branch
Switch to the contrib branch
Build
Build your fork of Umbraco locally as described in the build documentation: you can debug with Visual Studio Code or with Visual Studio.
Branch
Create a new branch now and name it after the issue you're fixing, we usually follow the format: temp-12345. This means it's a temporary branch for the particular issue you're working on, in this case issue number 12345. Don't commit to contrib, create a new branch first.
Change
Make your changes, experiment, have fun, explore and learn, and don't be afraid. We welcome all contributions and will happily give feedback.
Commit and push
Done? Yay! 🎉
Remember to commit to your new temp branch, and don't commit to contrib. Then you can push the changes up to your fork on GitHub.
Keeping your Umbraco fork in sync with the main repository
Once you've already got a fork and cloned your fork locally, you can skip steps 1 and 2 going forward. Just remember to keep your fork up to date before making further changes.
To sync your fork with this original one, you'll have to add the upstream url. You only have to do this once:
Then when you want to get the changes from the main repository:
In this command we're syncing with the contrib branch, but you can of course choose another one if needed.
More information on how this works can be found on the thoughtbot blog.
Style guide
To be honest, we don't like rules very much. We trust you have the best of intentions and we encourage you to create working code. If it doesn't look perfect then we'll happily help clean it up.
That said, the Umbraco development team likes to follow the hints that ReSharper gives us (no problem if you don't have this installed) and we've added a .editorconfig file so that Visual Studio knows what to do with whitespace, line endings, etc.
Questions?
You can get in touch with [the core contributors team][core collabs] in multiple ways; we love open conversations and we are a friendly bunch. No question you have is stupid. Any question you have usually helps out multiple people with the same question. Ask away:
If there's an existing issue on the issue tracker then that's a good place to leave questions and discuss how to start or move forward.
If you want to ask questions on some code you've already written you can create a draft pull request, detailed in a GitHub blog post.
Unsure where to start? Did something not work as expected? Try leaving a note in the "Contributing to Umbraco" forum. The team monitors that one closely, so one of us will be on hand and ready to point you in the right direction.
In order to use Umbraco as a CMS and build your website with it, you should not build it yourself. If you're reading this then you're trying to contribute to Umbraco or you're debugging a complex issue.
Are you about to ?
Are you trying to get to the bottom of a problem in your existing Umbraco installation?
If the answer is yes, please read on. Otherwise, make sure to head on over and start using Umbraco CMS as intended.
↖️ You can jump to any section by using the "table of contents" button ( ) above.
To run umbraco, we first need to initialize the client git submodule:
Execute git submodule update --init to get the files into \src\Umbraco.Web.UI.Client folder.
This can be executed in the root folder of your cloned repository.
If you are going to run Umbraco for testing, execute dotnet run inside the \src\Umbraco.Web.UI folder.
If you are going to work on the Backoffice, you can either go to the \src\Umbraco.Web.UI.Client folder and check out a new branch or set it up in your IDE, which will allow you to commit to each repository simultaneously:
Rider: Preferences -> Version Control -> Directory Mappings -> Click the '+' sign
If you get a white page, delete \src\Umbraco.Cms.StaticAssets\wwwroot\umbraco folder and run npm ci && npm run build:for:cms inside the src\Umbraco.Web.UI.Client folder to clear out any leftover files from older versions.
If you want to get the latest changes from the client repository, run git submodule update again which will pull the latest main branch.
In order to build the Umbraco source code locally with Visual Studio Code, first make sure you have the following installed.
npm v7+ (installed with Node.js)
Open the root folder of the repository in Visual Studio Code.
To build the front end you'll need to open the command pallet (Ctrl + Shift + P) and run >Tasks: Run Task followed by Client Watch and then run the Client Build task in the same way.
You can also run the tasks manually on the command line:
If you just want to build the UI Client to Umbraco.Web.UI then instead of running dev, you can do: npm run build.
The login screen is a different frontend build, for that one you can run it as follows:
If you just want to build the Login screen to Umbraco.Web.UI then instead of running dev, you can do: npm run build.
The initial Gulp build might take a long time - don't worry, this will be faster on subsequent runs.
To run the C# portion of the project, either hit F5 to begin debugging, or manually using the command line:
The initial C# build might take a _really_** long time (seriously, go and make a cup of coffee!) - but don't worry, this will be faster on subsequent runs.**
In order to build the Umbraco source code locally with Visual Studio, first make sure you have the following installed.
npm v7+ (installed with Node.js)
The easiest way to get started is to open umbraco.sln in Visual Studio.
To build the front end, you'll first need to run cd src\Umbraco.Web.UI.Client && npm install in the command line (or cd src\Umbraco.Web.UI.Client; npm install in PowerShell). Then find the Task Runner Explorer (View → Other Windows → Task Runner Explorer) and run the build task under Gulpfile.js. You may need to refresh the Task Runner Explorer before the tasks load.
If you're working on the backoffice, you may wish to run the dev command instead while you're working with it, so changes are copied over to the appropriate directories and you can refresh your browser to view the results of your changes.
The initial Gulp build might take a long time - don't worry, this will be faster on subsequent runs.
"The rest" is a C# based codebase, which is mostly ASP.NET Core MVC based. You can make changes, build them in Visual Studio, and hit F5 to see the result.
The initial C# build might take a _really_** long time (seriously, go and make a cup of coffee!) - but don't worry, this will be faster on subsequent runs.**
Do note that this is only required if you want to test out your custom changes in a separate site (not the one in the Umbraco.Web.UI), if you just want to test your changes you can run the included test site using: dotnet run from src/Umbraco.Web.UI/
You may want to build a set of NuGet packages with your changes, this can be done using the dotnet pack command.
First enter the root of the project in a command line environment, and then use the following command to build the NuGet packages:
dotnet pack -c Release -o Build.Out
This will restore and build the project using the release configuration, and put all the outputted files in a folder called Build.Out
You can then add these as a local NuGet feed using the following command:
dotnet nuget add source <Path to Build.Out folder> -n MyLocalFeed
This will add a local nuget feed with the name "MyLocalFeed" and you'll now be able to use your custom built NuGet packages.
Once the solution has been used to run a site, one may want to "reset" the solution in order to run a fresh new site again.
The easiest way to do this by deleting the following files and folders:
src/Umbraco.Web.UI/appsettings.json
src/Umbraco.Web.UI/umbraco/Data
You only have to remove the connection strings from the appsettings, but removing the data folder ensures that the sqlite database gets deleted too.
Next time you run a build the appsettings.json file will be re-created in its default state.
This will leave media files and views around, but in most cases, it will be enough.
To perform a more complete clear, you will want to also delete the content of the media, views, scripts... directories.
The following command will force remove all untracked files and directories, whether they are ignored by Git or not. Combined with git reset it can recreate a pristine working directory.
For git documentation see:
The produced artifacts are published in a container that can be downloaded from DevOps called "nupkg" which contains all the NuGet packages that got built.
You may need to run the following commands to set up gulp properly:
This document covers contributing to the codebase of the CMS but
If you don't feel you'd like to make code changes here, you can visit our and use your experience to contribute to making the docs we have, even better.
We also encourage community members to feel free to comment on others' pull requests and issues - the expertise we have is not limited to the Core Collaborators and HQ. So, if you see something on the issue tracker or pull requests you feel you can add to, please don't be shy.
This project and everyone participating in it, is governed by the [our Code of Conduct][code of conduct].
We categorise pull requests (PRs) into two categories:
We’re usually able to handle small PRs pretty quickly. A community volunteer will do the initial review and flag it for Umbraco HQ as “community tested”. If everything looks good, it will be merged pretty quickly [as per the described process][review process].
We would love to follow the same process for larger PRs but this is not always possible due to time limitations and priorities that need to be aligned. We don’t want to put up any barriers, but this document should set the correct expectations.
Not all changes are wanted, so on occasion we might close a PR without merging it but if we do, we will give you feedback why we can't accept your changes. So make sure to , so we can ensure that you don't put all your hard work into something we would not be able to merge.
Please make sure to describe your larger ideas in an or , it helps to put in mock up screenshots or videos. If the change makes sense for HQ to include in Umbraco CMS we will leave you some feedback on how we’d like to see it being implemented.
If a larger pull request is encouraged by Umbraco HQ, the process will be similar to what is described in the small PRs process above, we strive to feedback within 14 days. Finalizing and merging the PR might take longer though as it will likely need to be picked up by the development team to make sure everything is in order. We’ll keep you posted on the progress.
If you're unsure about whether your changes belong in the core Umbraco CMS or if you should turn your idea into a package instead, make sure to .
If it doesn’t fit in CMS right now, we will likely encourage you to make it into a package instead. A package is a great way to check out popularity of a feature, learn how people use it, validate good usability and fix bugs. Eventually, a package could "graduate" to be included in the CMS.
It is your responsibility to make sure that you're allowed to share the code you're providing us. For example, you should have permission from your employer or customer to share code.
Similarly, if your contribution is copied or adapted from somewhere else, make sure that the license allows you to reuse that for a contribution to Umbraco-CMS.
If you're not sure, leave a note on your contribution and we will be happy to guide you.
🛠️ - WIP in
📦 - released
without emoji - untouched idea
🛠️ Action bar (maybe just button-group, used in Cards, Lists etc. ust a round cornered box holding some buttons)
📦 Avatar
📦 Avatar Group
📦 Badge
📦 Button
📦 Button Group
Button Grid (use for Icon selector, Colors)
🛠️ Cards (One base and maybe more specific card types, concepts: Node, Media, Image, File, Folder, DocumentType, User, Member, Form, DataType, CloudProject...)
🛠️ Card Grid (Show any type of card)
Card Grid Create Button
🛠️ Caret symbol
📦 Checkbox
Color picker
🛠️ Date & Time picker
🛠️ Base Dropdown (Open towards, picked entry-display and unfold-display.)
🛠️ Dropdown Select List (A dropdown with select component baked in)
🛠️ FileInput Dropzone
🛠️ FileInput Input
🛠️ FileInput Preview (Form data, displays one of three symbols:...)
🛠️ File Symbol
🛠️ Folder Symbol
🛠️ Image-File Symbol (A frame on a thumbnail)
🛠️ Icon
🛠️ Inline create button (Vertical, Horizontal. the one from BL and MediaPicker v3)
📦 Input
📦 Loader
🛠️ Locked part (often used for locking the Alias)
🛠️ Menu item
🛠️ Menu item list
🛠️ More symbol ( three dots )
Node Display (Today called: Node-Preview, this is a base component that will be used for creating specific types for Content, Media, Image, File, Folder, DocumentType, User, Member, Form, DataType, etc.)
Node Display List
🛠️ Overflow container
🛠️ Password input
📦 Progress bar
📦 Progress circle
📦 Radio
Rich text Editor
📦 Single Slider
Range Slider
📦 Tag
📦 Table
📦 Toggle
TextAreaField
Search input
🛠️ Dialog
Notification
Notification List
Tooltip
Tooltip button (Little i, which can be clicked to get more info)
📦 Breadcrumbs
Overlay
Overlay Manager (ability to stack overlays, left, right, animate in and out)
Tree
📦 Tabs
Typeahead
🛠️ Pagination
In the high probability that you are porting something from angular JS then here are a few helpful tips for using Lit:
Here is the LIT documentation and playground:
Navigate to
Make sure you are on the contrib branch
Read the to learn how to get the project up and running
Find an issue marked as - note that some are also marked which indicates they are simple to get started on
Umbraco HQ owns the Management API on the backend, so features can be worked on in the frontend only when there is an API, or otherwise if no API is required
A contribution should be made in a fork of the repository
Once a contribution is ready, a pull request should be made to this repository and HQ will assign a reviewer
A pull request should always indicate what part of a feature it tries to solve, i.e. does it close the targeted issue (if any) or does the developer expect Umbraco HQ to take over
A lot of the UI has already been migrated to the new backoffice. Generally speaking, one would find a feature on the projects board, locate the UI in the old backoffice (v11 is fine), convert it to Lit components using the UI library, put the business logic into a store/service, write tests, and make a pull request.
We are also very keen to receive contributions towards documentation, unit testing, package development, accessibility, and just general testing of the UI.
The management API is the term used to describe the new backoffice API. It is built as a .NET Web API, has a Swagger endpoint (/umbraco/swagger), and outputs an OpenAPI v3 schema, that the frontend consumes.
The frontend has an API formatter that takes the OpenAPI schema file and converts it into a set of TypeScript classes and interfaces.
The backoffice can be ran and tested against a real Umbraco instance by cloning down the Umbraco-CMS contrib branch, but there are no guarantees about how well it works yet.
Current schema for API:
How to convert it:
Run npm run generate:api
Links for Lit examples and documentation:
HTML
The simplest approach is to copy over the HTML from the old backoffice into a new Lit element (check existing elements in the repository, e.g. if you are working with a dashboard, then check other dashboards, etc.). Once the HTML is inside the render method, it is often enough to simply replace <umb-***> elements with <uui-***> and replace a few of the attributes. In general, we try to build as much UI with Umbraco UI Library as possible.
Controller
The old AngularJS controllers will have to be converted into modern TypeScript and will have to use our new services and stores. We try to abstract as much away as possible, and mostly you will have to make API calls and let the rest of the system handle things like error handling and so on. In the case of this dashboard, we only have a few GET and POST requests. Looking at the new Management API, we find the PublishedCacheService, which is the new API controller to serve data to the dashboard.
To make the first button work, which simply just requests a new status from the server, we must make a call to PublishedCacheService.getPublishedCacheStatus(). An additional thing here is to wrap that in a friendly function called tryExecuteAndNotify, which is something we make available to developers to automatically handle the responses coming from the server and additionally use the Notifications to notify of any errors:
It is a good idea to make buttons indicate a loading state when awaiting an API call. All <uui-button> support the .state property, which you can set around API calls:
All items are declared in a manifests.ts file, which is located in each section directory.
To declare the Published Cache Status Dashboard as a new manifest, we need to add the section as a new json object that would look like this:
Let’s go through each of these properties…
Type: can be one of the following:
section - examples include: Content, Media
dashboard - a view within a section. Examples include: the welcome dashboard
propertyEditorUi
editorView
propertyAction
tree
editor
treeItemAction
Alias: is the unique key used to identify this item.
Name: is the human-readable name for this item.
ElementName: this is the customElementName declared on the element at the top of the file i.e
Js: references a function call to import the file that the element is declared within
Weight: allows us to specify the order in which the dashboard will be displayed within the tabs bar
Meta: allows us to reference additional data - in our case, we can specify the label that is shown in the tabs bar and the pathname that will be displayed in the URL
Conditions: allows us to specify the conditions that must be met for the dashboard to be displayed. In our case, we are specifying that the dashboard will only be displayed within the Settings section
Running the app with npm run dev, you will quickly notice the API requests turn into 404 errors. To hit the API, we need to add a mock handler to define the endpoints that our dashboard will call. In the case of the Published Cache Status section, we have several calls to work through. Let’s start by looking at the call to retrieve the current status of the cache:
From the existing functionality, we can see that this is a string message that is received as part of a GET request from the server.
So to define this, we must first add a handler for the Published Status called published-status.handlers.ts within the mocks/domains folder. In this file we will have code that looks like the following:
This is defining the GET path that we will call through the resource: /published-cache/status
It returns a 200 OK response and a string value with the current “status” of the published cache for us to use within the element
An example POST is similar. Let’s take the “Refresh status” button as an example:
From our existing functionality, we can see that this makes a POST call to the server to prompt a reload of the published cache. So we would add a new endpoint to the mock handler that would look like:
Which is defining a new POST endpoint that we can add to the core API fetcher using the path /published-cache/reload.
This call returns a simple OK status code and no other object.
We try to make good Storybook stories for new components, which is a nice way to work with a component in an isolated state. Imagine you are working with a dialog on page 3 and have to navigate back to that every time you make a change - this is now eliminated with Storybook as you can just make a story that displays that step. Storybook can only show one component at a time, so it also helps us to isolate view logic into more and smaller components, which in turn are more testable.
Locally: npm run storybook
There are two testing tools on the backoffice: unit testing and end-to-end testing.
We are using a tool called Web Test Runner which spins up a bunch of browsers using Playwright with the well-known jasmine/chai syntax. It is expected that any new component/element has a test file named “<component>.test.ts”. It will automatically be picked up and there are a set of standard tests we apply to all components, which checks that they are registered correctly and they pass accessibility testing through Axe.
Please review this document to help to streamline the process and save everyone's precious time.
This repo uses nodejs, so you should install nodejs as the package manager. See .
Not all changes are wanted, so on occasion we might close a PR without merging it. We will give you feedback why we can't accept your changes and we'll be nice about it, thanking you for spending your valuable time.
Remember, it is always worth working on an issue from the Up-for-grabs list or even asking for some feedback before you send us a PR. This way, your PR will not be closed as unwanted.
Feature requests or ideas should be submitted and may then later be converted into an issue.
It is your responsibility to make sure that you're allowed to share the code you're providing us. For example, you should have permission from your employer or customer to share code.
Similarly, if your contribution is copied or adapted from somewhere else, make sure that the license allows you to reuse that for a contribution to Umbraco.UI and Umbraco-CMS.
If you're not sure, leave a note on your contribution and we will be happy to guide you.
When your contribution has been accepted, it will be from that time onwards.
Unsure where to begin contributing to the Umbraco UI library? You can start by looking through
We welcome all contributions. There are many ways you can help us. This is few of those ways:
Before you submit a new PR, make sure you run npm run test. PR must pass all the tests before it can get merged.
As a PR submitter, you should reference the issue if there is one, include a short description of what you contributed and, if it is a code change, instructions for how to manually test out the change.
Please follow the pull request template you get provided when creating a pull request.
NOTE: Although the latest released version of Umbraco UI corresponds to the
mainbranch, then development happens in thedevbranch. If you submit a PR, branch offdevand target your PR todev.
Using Typescript is mandatory when contributing to this repository, although it is not necessary to use it when consuming the components.
Make sure you have the recommended version of node.js and npm installed
Currently we use node.js v16 and npm v8
Run npm install
Run npm run storybook to start the storybook server, which we also use for development
Package anatomy
Each component is a separate npm package and has a fixed file structure that looks as follows:
packages
new-component-name
lib
index.ts
new-component-name.element.ts
new-component-name.test.ts
new-component-name.story.ts
package.json
README.md
rollup.config.js
tsconfig.json
To scaffold these files run:
tsconfig.json file is generated automatically when the postinstall script runs.
Each property you create should be documented with a jsdoc snippet. You can see an example of a property below.
Properties should only use attr-reflection for styling - don’t map component-state to classes - use attr-reflection!
New dependencies can only be added by HQ-team and only after scrutinizing debate (to keep size down)
Components versions can only be bumped by HQ-team
Components can’t assume Umbraco context
Elements shouldn’t depend on TagNames - their own or children - instead use :host or this and use classes/id’s for selection
Elements always use a shadow-root (shadowDOM - for encapsulation)
Styles should have as simple rules as possible
UI-events should be unique types that extend from our UUIEvent (see uui-base package) (for typing reasons)
Element name must be prefixed with “UUI-”.
Element must have tests and pass them.
Element must pass basic Accessibility tests.
Element must have a storybook setup.
Source-code must follow the ES-lint rules.
A feature suggestion? Or maybe you think we could do something in other way? Start by filing an issue.
We for Umbraco-CMS, the backoffice project, the UI library and documentation.
Specificially for Hacktoberfest, we have a lot more things you can get involved in!
One of our main focus areas for 2024 is to deeply test out the major new features of Umbraco v15. The and we encourage you to test the main new features, namely:
The new rich text editor (RTE)
Migrating existing RTEs to the new RTE datatype
Working with the new RTE
Extending the new RTE
Lazy-loaded content, which is replacing the main caching mechanism
Upgrading existing sites and making sure everything still works on the frontend
If you have any custom routing or controllers in place, do they still work as expected
Try out the new ISeedKeyProvider, IDocumentServices and IDistributedCache
Block-level variants
Making sure all of your existing blocks work after an upgrade
If you have a very large block-based site, it is interesting to see if the upgrade doesn't take too long
Add variants to your existing or new blocks and start using them: edit, save, publish, etc
We really appreciate your help in testing this release. Please make sure to describe to us in a bit of detail what you've tried, let us know a bit about the scale of project you're testing on, etc.
If everything "just" worked (🤞) then describe that as well! Let us know exactly what you focused on that worked well.
An example of a participation entry is:
- 2024-10-04 - Paula Philips - Umbraco 15 Release Candidate testing - Details in the PR description
In the description of the pull request to get your name added, please put your test results as described above and link to any issues you've created if things didn't work as expected.
Packages are back on the menu - and yes, they also count as a contribution to Umbraco!
Here are some specific details on this:
Only contributions made to open-source Umbraco packages added to the Hacktoberfest Package repo list counts
Follow the contribution guidelines provided by the package creator
Look for the "help wanted" label on the issue tracker associated with the package you want to help out with
Packages for Umbraco 14 and up are eligible by default, even if the equivalent package already exists for older Umbraco versions.
Back, by popular demand, we will also be rewarding contributions that are either low-code and more importantly: no-code!
Verifying documentation
Copy editing
User experience testing
Talks or presentations
Blog posts
Podcasts
Case studies
Organizing Hacktoberfest events
In order to record your journey of verifying documentation (like related blog post(s) in October, events organized), please edit the README.md file and add your activity at the end in the recommended format and submit that as a pull request. We’ll take it from there!
To appreciate people who maintain open-source projects for the Umbraco ecosystem, an easy way to help contribute is to give them some money! We’d suggest you have a look at your favorite packages and see if their repo/maintainer is accepting sponsorship.
And the good news is: yes, you will be able to earn Umbraco swag, proportionate to your sponsorship amount.
Happy Hacktoberfest! 🎃
Do not do this: "Members will only have access to CDN endpoints."
Do this: "Members will only have access to Content Delivery Network (CDN) endpoints."
Do not do this: YSOD (.Net error page)
Do this: YSOD: Yellow Screen of Death, .NET error page
Do not do this: "The next thing to do, is to navigate to the Content section"
Do this: "Navigate to the Content section"
Did you read ?
If you want to run a build without debugging, see below. This runs the build in the same way it is run on our build servers.
You might run into .
The caching for the back office has been described as 'aggressive' so we often find it's best when making back office changes to to help you to see the changes you're making.
When the page eventually loads in your web browser, you can follow the installer to set up a database for debugging. You may also wish to install a to ease your debugging.
( for you to use to contribute to Open Source projects)
You might run into .
The caching for the back office has been described as 'aggressive' so we often find it's best when making back office changes to to help you to see the changes you're making.
When the page eventually loads in your web browser, you can follow the installer to set up a database for debugging. You may also wish to install a to ease your debugging.
Did you read ?
git
git
Umbraco uses Azure DevOps for continuous integration, nightly builds and release builds. The Umbraco CMS project on DevOps ..
Git might have issues dealing with long file paths during build. You may want/need to enable core.longpaths support (see for details).
When your contribution has been accepted, it will be from that time onwards.
In-depth:
Reference:
For Umbraco UI stories, please navigate to
Working with playwright:
When we are finished with the dashboard we will hopefully have something akin to this .
The UI Library components are built with and Typescript. Lit is a light-weight base class that makes development of web components easier and handles all the necessary things, attaching shadow root, reactivity, attribute reflection etc. We strongly encourage you to take a look at Lit documentation before starting development.
You can create a new component and that way contribute to the UI library. But before you do that, go to the and check if it's not already there. Components from that folder are very much WIP will be gradually moved to packages. You may also look for an inspiration in this , where you can check what component is in what stage.
are what creates the component's public api API. They all have corresponding attribute, through which the property can be initialized when the custom element gets instantiated and connected to the DOM. By default the property is not reflected to the attribute, meaning if property value changes the attribute in the markup will keep its initial value, but it will stay observed - changing its value wil change the property. , and used for styling purposes for example.
When applicable, elements should follow
Once you have done a round of thorough testing, please make sure to as usual.
You can do this by heading to the repository and adding your name to the list in the "Low code/no code" section.
This would be a great use of , so you can work on testing and keep updating the description with your test results until you're done and ready to submit your final PR.
Read much more about how this works, and guidelines on adding your own package repo to .
Please note: Package contributions eligibility for swag differ slightly from those used for all contributions. Read more on the to learn more about how a contribution is marked as "swag-eligible".
Publishing a brand new package to will also count towards both DigitalOcean's and Umbraco's Hacktoberfest contributions ⭐🤩
Eligible contributions according to include:
We for you to record your contributions that are not a pull request.
The teams at and are always looking for new articles. Finish your application October to make it count! We'll ask the Skrift/24 days teams to verify your application to write an article.
We suggest you scroll through the , and see if your favorite packages/authors are open to sponsorship. Look for the heart icon.
If you're in doubt if your chosen sponsorship would count, then feel free to first , or ask in the #contributing channel.
Umbraco HQ , at $100 per month. These are excellent projects that could always use more sponsorships, but make sure to also consider other repositories, there are many great ones out there!
We use to qualify, so any contributions that do not follow these standards will also not count towards Umbraco swag. These rules are to ensure we get quality contributions and that the right efforts get rewarded 🙌
If you’re contributing to one of the open-source Umbraco Packages, please check to learn more about how a contribution is marked as "swag-eligible".
In order to help you succeed we at HQ are trying to be available as much as possible during the month of October on Discord in the channel.
Whether you need some inspiration, guidance, help getting things to build, and so on - we’re there to support and guide you, together with the .
So come join us and the other 1500+ people already on the !
Documentation
Umbraco-CMS
UI Library
Backoffice Project
Small PRs
Bug fixes and small improvements - can be recognized by seeing a small number of changes and possibly a small number of new files.
Large PRs
New features and large refactorings - can be recognized by seeing a large number of changes, plenty of new files, updates to package manager files (NuGet’s packages.config, NPM’s packages.json, etc.).
