This documentation is intended for Confluence developers who want to ensure that their existing plugins and add-ons are compatible with Confluence 6.8.

We plan to release weekly milestones during the development of Confluence 6.8. Watch this page to find out when a new milestone is available and what’s changed. We will publish formal release notes once we release a beta.

Latest milestone

Issues with this milestone?

Hit the Feedback button on the Confluence EAP header or raise an issue to tell us about it.

Changes in Confluence 6.8

Beta 1 - 6 March

In this beta:

• Visual improvements to lozenges, such as status, date, and user mention
• Upgrade to Applinks 5.4.4

For a complete run down of all the features and changes in this beta, head to our Confluence 6.8.0-beta release notes. 

Milestone 47 - 26 February

In this milestone:

• Check out the shiny, redesigned emoticons in the editor! 
• More small visual changes in the editor, including status macro, date lozenge and mentions lozenge. 
• We've changed the way we handle access requests for restricted pages. We now send an email to up to 5 people, prioritising people who have contributed to the page.  

Milestone 38 - 19 February

• Upgrade to AUI 7.6.3
• Upgrade to Hazelcast 3.8.6 

There's still some work to be done on read-only mode. For this reason we’ve decided to keep this feature dark for Confluence 6.8 and instead make it available in a future Confluence version. This also means you have some more time to test your add-on and make any changes so you can be compatible.  

Milestone 30 - 13 February

No significant changes in this milestone. 

Milestone 26 - 5 February 

TinyMCE upgrade for the Confluence editor

We have been working on upgrading TinyMCE from version 3 to version 4, and are pleased to say that the upgrade is now in a state where you can start testing it with your add-ons. If you have an add-on that interacts with the editor in any way, we strongly recommend you begin testing your add-on with the upgraded editor as soon as possible. We don't have a set release date for the upgrade, but will target the earliest version where such an upgrade can take place. We hope that there will be minimal if any changes required to add-ons, but there might be some things we do not expect. In the worst case the upgrade will ship in Confluence 7.0 where add-on changes would be required, but it should be expected to ship sooner.

Until the version 4 upgrade is shipping in Confluence, we recommend to test your add-ons with version 3 and version 4 to make sure it is still working fine in the current versions of Confluence and in the upcoming release where version 4 will be turned on.

Manual testing

To test your add-on, spin up a normal 6.8-eap instance, and head to /admin/darkfeatures.action, and add the dark feature frontend.editor.v4. Then, head to the editor and check that your add-on is working as expected.

Automated tests

For any automated tests, you can spin up confluence with the V4 editor enabled by adding the following to the JVM args used to start Confluence:

-Datlassian.darkfeature.frontend.editor.v4=true

For example,

<configuration>
    ...
    <jvmArgs>-Datlassian.darkfeature.frontend.editor.v4=true</jvmArgs>
</configuration>

With automated tests, we recommend continuing to run without the dark feature enabled, and add a copy of the build with the feature enabled so that you can test both versions until v4 becomes the default.

Is your add-on loading the editor?

Does your add-on load the editor in its own views? If so, you will need to do the following once the v4 upgrade is rolled out.

Editor context

Load additional web-resource context: editor-v4 along with the existing editor. For example, if you're using requireResourcesForContext('editor'), you should use requireResourcesForContext('editor-v4,editor');

This only applies when frontend.editor.v4 is enabled. Technically, in v3 you should use requireResourcesForContext('editor-v3,editor');, but this will generally not be necessary. You can use the DarkFeaturesManager in java or the confluence/dark-features AMD module in JS to load either v3 or v4 based on the frontend.editor.v4 dark feature, to be ready for both. For example,

darkFeaturesManager.getDarkFeatures().isFeatureEnabled("frontend.editor.v4") // boolean

require('confluence/dark-features').isEnabled("frontend.editor.v4") // boolean

Editor tear down

If you also handle destroying the editor, make sure to use mceRemoveEditor command:

// TinyMCE 4 API
tinymce.execCommand('mceRemoveEditor', true, 'wysiwygTextarea');
// TinyMCE 3 API
tinymce.execCommand('mceRemoveControl', true, 'wysiwygTextarea');

Leverage TinyMCE 4.x API

Although 3.x API is available using a polyfill TinyMCE plugin, we encourage you to use the newer API once v4 becomes the default: https://www.tinymce.com/docs/

Reporting issues

If you encounter issues with your add-on in TinyMCE v4, please help us by doing some investigation into what is causing your add-on to break, then raise an EAP Feedback ticket (you'll need to be logged in to jira.atlassian.com for this link to work). 

Read-only mode is on its way

We're currently working on a great new feature for Data Center customers to help admins perform routine maintenance, recover from unexpected problems, or prepare to migrate content to a new site. Admins will be able to temporarily put their site in "read-only mode" to limit the actions that end users can do.  Users will be able to view pages and their history, but not create, edit, comment, copy or move content.  Administration actions such as changing site configuration are not restricted.

Here's how it works:

• Read-only mode is primarily enforced at the Permission Manager layer. 
• Features that do not observe permissions, such as liking or watching a page can check a Java API in order to determine if the mode is enabled.
• Admins will be able to turn read-only mode on and off via a Maintenance page in the admin console.
• We'll perform an add-on compatibility check, and display the results on the Maintenance page, to indicate to admins which user-installed add-ons are compatible with read-only mode, before they turn it on. This is based on a new parameter to be included in the plugin descriptor file. 
• When read-only mode is enabled, a banner will display above the header to notify end users that the site is read-only. The banner message will be customisable. 

Because read-only mode is enforced at the Permission Manager layer, Confluence should automatically block any write access if your plugin is using the correct Java API service for permission checking, or making any REST calls.

We have added a new experimental Java API, AccessModeService.  

/**
 * @since 6.8.0
 */
@ExperimentalApi
@ParametersAreNonnullByDefault
@ReturnValuesAreNonnullByDefault
public interface AccessModeService {
    /**
     *
     * @return the maintenance info
     * @since 6.8.0
     */
    AccessMode getAccessMode();

    /**
     * Update the access mode if the current user is a sysadmin
     * @param accessMode update the access mode for Confluence
     * @throws ServiceException the exception is thrown if the dark feature is not enabled or the access mode cannot be updated
     * @since 6.8.0
     */
    void updateAccessMode(AccessMode accessMode) throws ServiceException;

    /**
     * @return true if the dark feature "read.only.mode" is enabled and current access mode is READ_ONLY
     * @since 6.8.0
     */
    boolean isReadOnlyAccessModeEnabled();
}

To check that your plugin is compatible, and ensure it does not write content to the database when read-only mode is enabled, you should enable read-only mode and test what actions are possible with your add-on. Don't forget to consider users who may already be editing a page or in the midst of an operation at the point read-only mode is enabled. 

If your add-on writes data to the database that it shouldn't:

1. On the client side, you can hide the web item representing the UI control using the PagePermissionCondition/CommentPermissionCondition as follows:

   1. For edit operation:

      <web-item key="edit-something" name="Edit Something" section="system.content.action/modify" weight="20">
          <condition class="com.atlassian.confluence.plugin.descriptor.web.conditions.PagePermissionCondition">
      		<param name="permission">edit</param>
      	</condition>
      </web-item>

   2. For delete operation:

      <web-item key="remove-something" name="Remove Something" section="system.content.action/modify" weight="20">
      	<condition class="com.atlassian.confluence.plugin.descriptor.web.conditions.PagePermissionCondition">
      		<param name="permission">remove</param>
      	</condition>
      </web-item>

2. On the server side, you can use the Java API to prevent the operation as follows:

   public void writeOperationNotAllowedInReadOnlyMode() {
   	if (accessModeService.isReadOnlyAccessModeEnabled()) {
   		throw new ReadOnlyException();
   	}
   }

Once you've confirmed your plugin does not write content to the database, mark it as compatible by setting the "read-only-access-mode-compatible" parameter to true in the plugin-info tag, as shown in the example below:

<plugin-info>
    <param name="atlassian-data-center-compatible">true</param>
    <param name="read-only-access-mode-compatible">true</param>
    <description>${project.description}</description>
    <version>${project.version}</version>
    <vendor name="${project.organization.name}" url="${project.organization.url}" />
</plugin-info>

As this feature is still very much in development, the changes are still dark in this milestone, but you can go to <confluence-url>/admin/darkfeatures.action and add the read.only.mode dark feature flag to try it out in your test instance. For testing purposes you can enable this dark feature and try it out on a Server instance, but the finished feature will only be available for Data Center installations. 

Milestone 22 - 29 January

This is our first public milestone for Confluence 6.8.  There's no significant changes in this milestone.