0 results found

Contribute to TinyMCE

Contribute to the open source project. Help build the core, plugins or even write the documentation.

Contribute to this page

TinyMCE is an open source software project and we encourage developers to contribute patches and code for us to include in the main package of TinyMCE. However there are a few rules and limitations when doing so and this page list them.

Basic Rules

These basic rules make it possible for us to properly manage the TinyMCE project and to ensure that the code remains open source and under the LGPL license.

How to Contribute

The TinyMCE source code is hosted on Github. Through Github you can submit pull requests and log new bugs and feature requests.

Contribute to TinyMCE's Documentation

How can you help?

We welcome people with technical writing experience to help make TinyMCE's docs as useful to our community as possible. You don't need to be an expert developer to contribute, but a basic understanding of software development is helpful.

What is more important is your ability to articulate complex ideas simply. Our goal is to help developers understand TinyMCE functionality as quickly as possible so that they can get back to building great stuff.

If that sounds like something you are into, branch the docs GitHub repository and submit a PR, or reach out to the TinyMCE docs team if you have a specific question.

TinyMCE docs tech stack

The documentation is built with Jekyll. Text files are written in Markdown and published on GitHub. You'll find the repo here.

Markdown & code syntax

As we mentioned above, we write using GitHub Flavored Markdown. If you're not familiar with Markdown read this.


We highlight code language syntax and associated elements within an open and closing backtick. For example, this object is actually enclosed with backticks like this: `object`.

We cannot cover every use case here and contributors need to use their best judgment. As as rule, words relating specifically to executable parts of software languages, keys and their values when related to objects and methods (particularly the case with TinyMCE) should be backticked.

Code snippets

Code snippets should always be complete, executable code blocks starting with the tinymce object. We write code snippets by enclosing the example code within three opening and closing back ticks. The first set of backticks is immediately followed by the code's language, which helps correct syntax highlighting: typically, html, css, js, php.

Include any key values pairs and method options that are required to enable a user to test the snippet in a local HTML file. You do not need to include the html surrounding the tinymce object that would be required to make the snippet work. For example, this is good:

  selector: "textarea",  // change this value according to your HTML
  plugins: "codesample",
  toolbar: "codesample"

This is not:

  plugins: "codesample",
  toolbar: "codesample"
URLs and links

Resources to be linked take the form of placing the linked text between brackets and the URL between parenthesis. Linking an external resource looks like this:

hello, [text to link](http://www.example.com) to the URL example.com.

We will provide the internal linking structure shortly. Otherwise clone and branch the repo and explore for yourself (it's a test of skill).

Adding meta to a pages

Every page should have a meta section starting at line 1 containing information that is both informative and system critical. If you are creating a page, or editing one that currently has inadequate meta information, please read the comments next to the default meta fields below.

---                // Three dashes at start and end of the meta section, must be included.
layout: default    // In most cases leave this as 'default'.
title:             // The nav.yml references this so it must be included and it should be short.
title_nav:         // Descriptive title for the navigation bar, if omitted nav defaults to title field.
description_short: // Short description for the grid layouts.
description:       // Detailed description at page level for the header section under the title.
keywords:          // Space separated list of key words in the content.

Style Guide

TinyMCE v. tinymce

Use the capitalized version of TinyMCE when referring to the open source project or the editor as an all encompassing whole. Use lowercase when referring to the tinymce JavaScript object.

Title capitalization

For H1 titles use "Title Case Capitalization". For H2-H6 titles use "Sentence case capitalization". Sentence case capitalization is typically easier to read in technical documentation like ours.


Use United States English. For example, behavior rather than behaviour, referring rather than refering.

Proper names

When referring to the name of a development language we use the proper name or the industry convention. For example, HTML, CSS, JavaScript, jQuery, React, AngularJS (not html, css, Jquery or React-js.)

The exception to this rule is when we are talking about the code itself (see the note above about TinyMCE v. tinymce). For example, we would say, "HTML is great" when talking about the HTML language, but we would say, "escape your html" when talking about an action with/within a codebase. We realize this can be a little confusing, so do what you think makes sense and we will review it with your PR.

Contributor Code of Conduct

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.

Examples of unacceptable behavior by participants include:

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.

This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.

This Code of Conduct is adapted from the Contributor Covenant, version 1.2.0, available from http://contributor-covenant.org/version/1/2/0/

Except as otherwise noted, the content of this page is licensed under the Creative Commons BY-NC-SA 3.0 License, and code samples are licensed under the Apache 2.0 License.