This documentation relates to Opera's now deprecated .oex Extension API framework for Opera versions <= 12.15 and also provided by our OEX2NEX shim library.
For the latest Opera Extensions API documentation for Opera versions > 12.15 please consult the latest Opera Extensions API documentation online.
Publishing your first Opera extension is a multi-step process that begins when you submit your extension for review. Extension developers are encouraged to publish and host their Opera extensions in the Opera extensions catalog. You should take a look at the Opera extensions publishing guidelines to get the most out of hosting your Opera extensions with us.
In case you decide to also distribute Opera extensions through your own site, you will need to set the MIME type of your server. This is important because as Opera extensions carry the possibly unknown .oex file type, web servers might end up "guessing" the MIME type as being text/plain or application/octet-stream. According to the HTTP specifications, Opera will then have to process the document based on the reported MIME type instead of the correct MIME type.
For Apache web servers, you will add a .htaccess file in the same folder as the .oex file. It will affect the current directory and its sub-directories. You can append to an existing .htaccess file or create one with the content below.
# OEX
AddType application/x-opera-extension .oex
For Microsoft IIS server, see see Microsoft's documentation on editing MIME types.
Once you work on an extension and release it, that's not usually the end of the story. Over time you will want to add updates, bug fixes, and more features to your extensions. It is also important that once you do release a new version of your extension, users need to be updated to the new version without any hassle. Understanding the auto-update process is important in this regard.
The auto-update process has two steps from a network perspective. First, when the browser triggers the extensions update, it checks if there is an update string stored in config.xml. The update string looks like this:
<update-description href="http://test.opera.com/api/w3c-wd1/update/opera-configurator-1.0-1/"/>
The receiving server will respond with:
<update-info xmlns="http://www.w3.org/ns/widgets" src="http://test.opera.com/media/extensions/23/235873f76d9245be97481c262e05b8d1.oex" version="1.1">
</update-info>
As implied, src is where the updated extension is located. It will be downloaded and installed by the browser. In the case where there is no update available, the server will not send anything back.
An extension is identified by an id stored in config.xml, for example id="extensions:opera-configurator". There is also version where nothing will be updated if it is already up-to-date. An extension might be updated in the range of 1 to 30 days. You can change the auto-update check interval by going to opera:config#AutoUpdate|UpdateCheckInterval - the default value is 3 days or 259200 seconds.
The whole update mechanism for Opera extensions can be turned off together with the browser auto-update under opera:config#UserPrefs|LevelOfUpdateAutomation. If the update server is different than the default Opera URL, an untrusted repository warning will be displayed as shown below:
NOTE: It is essential that the ID attribute is included in the <widget> element. Without this attribute the update process will not work. Some users have reported crashes when auto-update is performed without an ID attribute.
Full specification of Widget Updates (Note: Update Description, which can be sent via server response in the form of update info, is not supported in Opera 11.)