Today we're proud to release MediaCore CE 0.10. This release is the first major release of MediaCore CE since SimpleStation Inc. (now MediaCore Inc.) handed over project control to the community. The release contains a lot of bug fixes, improvements and additions over previous versions of MediaCore.
The main feature for this release is a new authorization infrastructure so you can restrict media access to certain groups (e.g. logged in users). The API is quite generic so plugins can create their own access restrictions (e.g. based on URL access tokens, restrict access to individual media). Furthermore the YouTube integration was improved significantly so that it can also deliver HTML5 videos to your users. And last but not least Facebook comments were updated so it matches the current Facebook recommendations.
Updated YouTube embedding:
MediaCore now uses YouTube's "iframe" embedding method so users can always use
the latest YouTube player. Embedded YouTube videos may also be played using
HTML5. Also YouTube's 'embed' url scheme (http://youtube.com/embed/
Improved Video Embed Code compatibility:
Some third-party software like WordPress was confused by the self-closing
<iframe />
tags in the video embed code. Even though technically this tag is
perfectly fine by the HTML spec, we changed the embed code so it uses more
"traditional" <iframe ...></iframe>
tags.
Flowplayer/JW Player updates:
Flowplayer was updated to 3.2.12, JW Player is now at 5.10.2295.
Search also searches Media Description:
The naive MediaCore search (not using MySQL's fulltext search capabilities) now
also searches the media description. This provides slightly better search
results for users.
Updated Login Form:
The login form was redesigned and will now display error messages after a failed
login. A side effect is that MediaCore plugin developers can also change the
appearance more easily.
Locale-aware Number Formatting:
The number of views and likes are now formatted according to MediaCore's locale
(e.g. 1000 will be '1.000' for a German MediaCore, '1,000' for an English one).
Access Restriction for Media:
MediaCore administrators can now restrict media visibility to certain user
groups. For example an administrator can configure that only logged in users
can see any media by removing the "view" permission from the "anonymous" group
in the group admin interface and assigning the permission to the "authenticated"
group instead. Also the public upload is limited to groups having the "upload"
permission.
All anonymous users (users who are not logged in) are automatically "members" of the "anonymous" group, the same is true for logged-in users and the "authenticated" group. The admin interface now allows also to put a user into multiple groups.
In a default install all permissions are "global" so they apply to all media
(a user can either see all media or none at all). However the access
restrictions are powered by an extensible infrastructure (developers
should check the source code in mediacore.lib.auth
) so plugins can contribute
other "policies" which might implement fine-grained limitations (e.g. view
permission for a specific video).
You can configure in your config file which permission policies should be enabled and their ordering (which may be important because some policies may strictly deny access to some media).
[app:main] permission_policies = GroupBasedPermissionsPolicy, FooPolicy
If the option is not present at all in the config file MediaCore will default to the built-in "GroupBasedPermissionsPolicy" as the only active policy.
Please note that the access restrictions are not yet applied for API access, podcasts, and admin UI.
Public Login:
An administrator can enable a login link on all public pages (above the main
navigation bar) so it is easier for users to log in.
Updated Facebook Comments:
The Facebook comment integration code was updated to Facebook's latest policy
changes. With the old code ("xid-based") every user will see a Facebook
deprecation warning if there are no comments for a specific media yet.
MediaCore 0.10 uses the new URL-based comment code. The only downside of that you'll experience unpleasant surprises if your MediaCore installation is accessible under different domains (e.g. foo.example and bar.example). A workaround for that problem will require some Python coding in MediaCore.
Please note: If you used Facebook comments before you need to run a special migration script to preserve your existing comments. Please read the upgrade notes for more information.
Better Configurability for the YouTube Player:
There are many new configuration options available for the YouTube embedding:
Most of the options were implemented by Robert Buchholz.
Ability to enable/disable Plugins:
MediaCore now loads only enabled plugins. Plugins can be enabled in your config
file:
[app:main] plugins = editviews, panda, seo # to enable all plugins: # plugins = * # disable all plugins: # plugins =
To preserve backwards compatibility a missing 'plugins' option in your config
file will be treated as plugins = *
. This helps running multiple MediaCore
instances with a single source tree/virtualenv.
Custom Head Tags:
You can now add arbitrary tags to the HTML <head>
section (e.g. to better
integrate with third-party JavaScript like ad networks). Custom tags can be
added in the Settings admin / Appearance.
Python 2.4 Support restored:
MediaCore CE now supports Python 2.4 again. Support for 2.4 was accidentally
broken in early 2011. Please note that you will see some SyntaxError
s during
the installation (issue 121)
during the installation but these can be ignored safely.
Removed Necessity for a Local Mail Server (SMTP):
Previously MediaCore sent all notification emails (i.e. video upload/comments)
to a SMTP server on "localhost". This is still the default however you can
change by setting smtp_server
and possibly smtp_username
/smtp_password
in your deployment.ini
.
UI to set an Expiration Date for Media:
MediaCore Editors can now set an expiration date for media (similar to the
publication date) after which the media will not be displayed in any list.
Pessimistic DB Disconnect Handling:
MediaCore (actually SQLAlchemy) reuses database connections across requests
(connection pool). Whenever a connection broke (e.g. due to network errors) one
user saw an internal error ("Whoopsadaisy"). A MediaCore operator can force a
very simple database operation before each request to validate that the reused
connection still works.
[app:main] # 'False' by default db.enable_pessimistic_disconnect_handling = True
Pillow for simpler Installation:
The Python library responsible for manipulating images (thumbnails) was updated
to use "pillow", a forked version of the original PIL. The new library should
detect available (jpeg/zlib) development headers better so hopefully we'll see
less install trouble in the future.
Number of Items in RSS Feeds:
A MediaCore administrator can now configure the number of items in RSS feeds
(via Admin settings - Sitemaps). The setting defaults 30.
Improved Thumbnail Quality:
MediaCore now generates higer-quality jpg thumbnails (as suggested by Ian Nalepa).
This will increase storage requirements for thumbnails but ultimately it should
be worth the quality.
Added Thumbnails for Default Media:
When you create a new MediaCore instance, you will get real thumbnails for
the default media.
Logging in mod_fcgid:
The deployment script for mod_fcgid was updated so you can now uses MediaCore's
logging capabilities.
JavaScript License Change to MIT:
The license for the front-end (public) JavaScript code is now licensed under
the MIT license. Previously
MediaCore administrators were potentially unable to comply with the GPL
(depending on your legal interpretation) if they used third-party JavaScript
under a license which is not GPL-compliant (e.g. Google Analytics, Sublime
Video player).
To remove that uncertainty, all public JavaScript code created for the MediaCore project was relicensed. Please note that all the rest of MediaCore CE (e.g. Python code, JavaScript in the admin ui, markup) is still licensed under the GPLv3+. For more precise licensing information, please read the 'LICENSE.txt' file.
API to add additional JS/CSS:
There is a new API (see mediacore.lib.js_delivery
, mediacore.lib.css_delivery
)
to add JS/CSS files to a page. This is especially helpful for
plugins which can use this API to customize MediaCore's built-in pages. In
previous versions of MediaCore you had to use a custom template using Genshi's
py:match.
The new API has also two more advantages: You have less template logic in case you want to use uncompressed/unminified JavaScript when the '?debug' url parameter is present and the custom CSS configured in the admin section can still override any static CSS from a plugin.
Please note that this API may change in future (major) versions of MediaCore CE. I plan to utilize an external library instead of the current home-grown code to provide additional features (automatic minimization, bundling JS, dependencies). I'll try to keep backwards compatibility as much as possible though.
Infrastructure for Unit Tests:
Finally MediaCore has a good infrastructure to write automated tests not only
for trivial algorithmic code but also testing code accessing the database
(using a in-memory sqlite db) and controller methods who need access to Pylons'
request object.
Currently MediaCore has 113 "unit" tests which are executed on each commit but I'll create more as we go. I'd encourage you to create unit tests for your plugins as well, it's a great way to develop rock-solid code.
Additional Observation Points/Events:
Plugins can tell @observes
decorator to run the plugin code before the
observed method:
@observes(<event>, run_before=True)
This is helpful e.g. to enforce additional requirements with a plugin or to do something if the controller method redirects (which is technically a Python exception in Pylons). Also more controller methods can be observed with that release. Plugins are also run before the beaker cache for sitemaps/feeds kicks in so you can easily implement your own caching strategy.
Add Settings Keys without Database Migration:
You can now just add a new field to a form and the SettingsController
will
create the setting in the database automatically (previously the setting was
ignored). That means you don't have to create a database migration for each
new setting (provided that your code does the right thing if the setting does
not exist at all).
Ability to debug JavaScript in Admin Area:
If you need to debug the JavaScript in the admin area you can just append '?debug=True'
to the URL and MediaCore will load uncompressed JavaScript files.
Support for non-compiled Players:
Each player in MediaCore has a corresponding Python class but also a
JavaScript part which handles the user interaction with the player (i.e.
switch between wide-screen/narrow-screen player). In previous versions the
JavaScript code had to be part of mcore-compiled.js, a "compiled" JavaScript
file (generated with the Google Closure Compiler). This made it impossible to
ship a plugin with a player which required a specialized JavaScript manager
because the original method names were replaced with basically random strings.
In this version MediaCore falls back to the original names if a JavaScript player does not have the "compiled" methods. Please note that this mechanism is not a "stable API" - the Google Closure code may be replaced in later versions (likely with a simpler jQuery-based approach).
Ability to detect leaked DB Connections:
If you use SQLAlchemy expressions in a class-level scope (e.g. declaring a
field in ToscaWidgets) it is very easy to unknowingly create a SQLAlchemy
session and later on (in production) you'll see strange exceptions. In MediaCore
0.10 there is a new config option which will print warnings on the console if
it detects this situation.
[app:main] db.check_for_leaked_connections = True
I hope this option helps someone else as well – I spent many hours before I was able to find my bug…
For the general upgrade process you should read the "Upgrading MediaCore CE" section in the documentation. In preparation of the 0.10 release we rewrote the complete install/upgrading docs - hopefully they are easier to read now.
MediaCore CE 0.10 is a major release and it requires some database changes. Our automated database migration scripts will handle that. Besides all the new features we also started to clean up old cruft:
However we still ship incomplete translations and it is easy to enable a disabled translation again:
pybabel compile --locale=<locale> --domain=mediacore --directory=mediacore/i18n
(just replace <locale>
with the locale you want to enable)You should now see a new ".mo" file and after web server restart the language should be visible in the admin.
One of the biggest strengths of MediaCore CE is the plugin system. This section features changes of the "official" plugins.
MediaCore CE 0.10 is incompatible with versions of the encoding plugin prior to 0.10. Please update your plugion to version 0.10.
This is a new plugin developed by MediaCore Inc., Felix Schwarz and Robert Buchholz. It allows to import complete YouTube channels instead of individual YouTube videos one-by-one. You can also re-run the import to update the video description (the plugin will not create duplicates).
Currently you need to specify the channel name (e.g. "LinuxMagazine") and not the YouTube channel URL (e.g. http://www.youtube.com/user/LinuxMagazine). Videos which are not available in your country can not be imported.
Please note that importing YouTube videos can take quite a long time (many minutes, depending on the channel size) and you might see timeouts if you use the web interface for that and MediaCore CE is deployed using FastCGI or nginx/uwsgi.
There is also a command-line client which can even import huge channels which can not be imported at once because of YouTube's request quota.
Software is never done so we already develop features for the next release. My hope is that it won't take us a year again for the next major release. Ideally we'll see one release every 3-6 months but that of course depends on the available developer/testing resources.
For the next release all users will be able to prioritize the possible features and I will take that into consideration when starting main development for 0.11. I'll list possible features on this site 1-2 weeks after the MediaCore 0.10 release.
MediaCore CE 0.10 will be last release which supports Python 2.4 and 2.5. The next version will require Python 2.6 at least because there are too many libraries which don't work anymore with Python 2.4. So if you're using such an old host, better plan for an upgrade (RHEL/CentOS 5 will still be supported via Fedora EPEL).
But let's not forgot the previous release: MediaCore CE 0.9 will be supported at least until 0.11 is released. That time might be extended depending on customer demand and/or interested volunteers.
This release was not done by a single person but by many different contributors. If your name is missing, please let me know. Also I'd like to thank MediaCore Inc. for providing hosting, the brand name and all their work which went into MediaCore in the past.
Also I'd like to thank the various helpful people in the forum who provided help and guidance.
If you didn't do that already, please subscribe to our announce mailing list (very low traffic) so you don't miss new releases or information about security vulnerabilities. The primary place for support and talk about MediaCore CE is our web forum (RSS feed). If you have a question or you found a bug, just post there – and if you're a true MediaCore expert you can give something back by helping other users. There is also a mailing list for developers and users who prefer email.