- Preface/Motivation
- The items listed aren't necessarily ordered by importance but rather numbered so they can more easily be referred to.
- CMS can be quite big projects and Maniaplanet as a platform doesn't support Player Manialinks (unlike UI Manialinks for Gamemodes etc.) enough in terms of publicity so that maintenance of ML projects isn't rewarding. As of that we currently don't have a maintained CMS for players to get going, but probably no players that want to start a project either.
- I might be biased in some points from recent experiences with CM systems
- Components/Tasks for such a CMS
- User- and role-management, package management, internationalization [generic framework stuff]
- File-management (upload, download, Maniacodes), possibilities to include GBX-data-extraction etc. in the process, Maniacode payments [more manialinky stuff]
- Probably a bit of templating? Support for including/merging ManiaScript files [manialink specific stuff]
- Web frontend for most data management tasks as these are more comfortable with a browser (file path restrictions, forms etc.)
- Admin panel in game for interactive wysiwyg layouting etc.
- SEO supporting markup generation (see below)
- Structure
- I came to appreciate a structure with functionallity split into vendor packages e.g.
- Framework/Core
- Framework/Media
- Framework/Users
- Plugins/<Vendor>/Maps
- Plugins/<Vendor>/ManiaExchange
- Plugins/<Vendor>/Skins
- Packages/<Vendor>/MyOwnManialink
- A "Maps" plugin would provide models, hooks into the file upload process to extract GBX data, methods to access uploaded maps etc.
- The "MyOwnManialink" package would provide needed logic and components up for customization.
- I understand "components" as settings + markup + script, provided by packages
- Pages can be created with or without content specifications and are filled with components rather than being a certain page type like MapsPage, GuestbookPage etc. as we saw in some previous systems.
- Components should be dominantly be defined by configuration files and markup so that they can be configured with automatically created forms for both an in-game- and a web-interface. They would range from simple elements (Quads, Labels) over building blocks like Checkboxes (maybe containing multiple markup elements and requiring ManiaScript) to complete logical units like a guestbook consisting of all of the above.
- The framework should provide an API based on a class structure automatically handling data representation for usage with ManiaScript HTTP requests in the components, e.g.
- \Vendor\Package\Datasources\ManiaFlashMessagesDataSource returns an array of ManiaFlash messages - somehow gathered in the plugin
- datasources/maniaflashmessages?channel=...&format=xml returns a formatted representation of the data
- Some ManiaScript wraps methods like Framework_Datasource("maniaflashmessages", ["channel"=>"..."]); and allows custom event handling
- I came to appreciate a structure with functionallity split into vendor packages e.g.
- SEO
- Manialinks cannot really be found, ManiaPub is "WIP" for a long time and without any prominence
- Unless we are presented with an official solution we can scrape known manialinks, follow links on the page and retrieve information
- A standard is to be proposed - either with official support of meta tags or by some convention of element IDs on hidden elements. Possible information might contain
- author, title, link, description
- sitemap, links to explicitly follow
- images like icon, preview, banners in different resolutions that can be used by ManiaPub or search results
- content data, compare to google's smart card standards
- Manialink specific frontend considerations
- Absolutely positioned elements => components are probably movable and removable. (I consider the Boxes CMS a few years ago as a candidate with a useful implementation of that concept)
- Adding elements/components requires reloading the complete admin area other than we know from the Interface Editor.
- Running the backend as some kind of plugin which can use UI Layers and fetch content on the go and lastly save some template file?
- Usage of framemodels as platform pattern vs data in framemodels via backend templating/rendering
- Decentral vs central ManiaScript and dependency management (multiple plugins might require a third party library without adding it to every package (central), but will probably split their own logic into multiple files per package (decentral))
- ML browser features like modifying the displayed address to make up for ManiaScript-based pagination etc.
- Manialink/Player ML specific problems
- (Publicity of Manialinks)
- Need for Manialinks? Content can be distributed via MX, Carpark etc., Packs with built-in pricing...
Personally I currently don't see any audience for a project like this (also due to some points mentioned above). The manialink specific parts of a system like this might easily be so big that an adaption of existing (web-oriented) systems wouldn't be a small task either.
I'd like to read other's opinions and maybe see some discussion on this topic.