Add-on CMS and Portal

guiltar

Well-known member
It is not actually addon request but discussion of planned addon.
Want to ask how you imagine fully-functional CMS/Portal based on XenForo?

Result of my thoughts was following:
  • Customizable index page.
  • CMS will use static pages realised in core.
  • Customizable navigation menu. It should be something like Nodes As Tabs probably with GUI.
  • Allow comments in static pages. May be done be assigning threads to static pages.
  • Widget/Block system integrated with static pages. This will allow to display dynamic content on any page. In progress.
  • Blogs system. Article is regular thread with nested comments and specific view. Already done.
  • News system. Every thread may be news item. Already done.
  • Gallery/Albums. In progress.
What else needs XenForo to be universal replacement of any mainstream CMS like WordPress, Joomla, etc?
 
I think there are a lot of possibilities with a CMS.
Many XF users, perhaps a majority, would only need something simple which had:
Articles
Navigation
Separate OR total site search
Pages (one-up pages)

Once you deviate from the basics, there are infinite possibilities - which makes development difficult. It seems that Wordpress integration is what a really advanced user needs - so working on that would seem a better use of energy.

But if features for a "medium grade" CMS were to be looked at, you should check out CMSMS (CMS Made Simple). That is a great free CMS that has quite a number of features.

Looking forward a number of years, it would be great if three options existed:
1. Very simple CMS as described above built into core - this would probably work for 50% of more of users who need mostly forums, but a few articles and libraries.
2. A custom add-on CMS with reasonable features - like CMSMS. The problem is that such a package would have to be supported for MANY years as XF upgraded. I would not want to build upon a "here today, gone tomorrow" CMS.
3. WP integration - possibly backed by XF - even if they don't write it, they could guarantee to keep it going if the developers stopped working on it, etc.....

At least #1 and #3 would be ongoing.......
 
Nice nested comments .... what blog is that ?
It's the part of planned addon which I develop :)
Did you make your own style for that node ?
Not actually the style but extending of view, using template hooks and adding css styling made this effect.
There also used recursion in view to render nested comments.
Once you deviate from the basics, there are infinite possibilities - which makes development difficult. It seems that Wordpress integration is what a really advanced user needs - so working on that would seem a better use of energy.
XenForo has much higher code level than Wordpress and using them together is like attaching a trailer to Porsche Carrera :)
Also there is a problem with alerts, incoming messages, writing addons to this bridged site. Multistyle, multilanguage problems...
2. A custom add-on CMS with reasonable features - like CMSMS. The problem is that such a package would have to be supported for MANY years as XF upgraded. I would not want to build upon a "here today, gone tomorrow" CMS.
That is the only way to go. Otherwise we have to wait with hope.
Of course it's much better to see all of this in the core but I haven't heard something like that is planned.
 
CMS will use static pages realised in core.

Were you thinking the pages would support BBCode?
Please make the pages are editable from the front end, not just the Admin CP (like current Xenforo pages are).
What else needs XenForo to be universal replacement of any mainstream CMS like WordPress, Joomla, etc?
Wiki- like editing of posts ! :)
Actually that would make Xenforo superior to Joomla and probably Wordpress.
:)
 
Were you thinking the pages would support BBCode?
Please make the pages are editable from the front end, not just the Admin CP (like current Xenforo pages are).
Pages are editable from ACP in most of CMS. Why do you need BBCode if you can use HTML there?
BBCodes are used in the forum for security and for fast-edition. Pages are editable by admins and not very often.
So in this case you don't need security and html is much flexible.
Actually that would make Xenforo superior to Joomla and probably Wordpress.
It deserves this place :)
 
Why do you need BBCode if you can use HTML there?
BBCodes are used in the forum for security and for fast-edition. Pages are editable by admins and not very often.
So in this case you don't need security and html is much flexible.
:)
Guiltar : you have great skill.
I (and most others) do not.
I don't want to learn HTML.

As well, I want my entire community to be able to make content.

I could easily learn HTML, and then I would be the only one making content, because no one else in my community would learn HTML. The reason why Mediawiki wikis fail is it is hard to learn the syntax (sure the WYSIWYG editor is getting pretty good ... now). This creates enough of a barrier that people don't create content in the wiki. Well, in the same vein, HTML is a barrier. So would restricting content creating to just admins (from the AdminCP). In your approach where Blog posts are actually Threads everything is outside the AdminCP and that is a great thing. The best model for most sites is to get many people making content. Make creating a wiki entry or article or blog post or gallery item or whatever content as easy as posting to the forum. Many hands make light work. For something like a wiki ... you want the person who created the wiki item to be responsible for keeping it up to date ! So you also need to make it easy for them to update. Burying the wiki entry to just editing in the AdminCP gives all the work to the admins.

Pretend you don't know HTML.
I bet you want BBCode editing of wiki, portal, article, blog entries now.
:)

Certainly the needs of a "wiki" are different than a article and a blog post.
For that reason, I'll keep this wiki talk elsewhere :)
 
If we say about public-generated content - yes, no doubt, it has to be easy, user-friendly and safe. That's why all public content is based on threads: wiki, blogs, albums, events, etc....

But CMS-pages is admin-generated content. It is static content. It may be your company info like the home page http://xenforo.com
Here is example of page: http://xenforo.com/community/pages/example-page/ and some info about it.
This is not for regular users, this is for staff. WYSIWYG is good idea and it can be used also for HTML.

Moreover, XenForo-Page is a node and there is a core limitation of node's number (<500). So XenForo-Pages can't be user-creatable. If they are, you will reach this limit very fast. And this will slow down rendering node-tree.
 
It depends on what we name wiki :) Probably it was to loud naming it as wiki.
I imagine wiki page = blog entry + auto-linkinig + table of content + public editable + edit history + navigation + clear urls.
Also comments may be loaded by json to not mess with content.
 
Is there a wiki demo ? private ?
I dont see anything on http://do4a.com/ :)

I imagine wiki page = blog entry + auto-linkinig + table of content + public editable + edit history + navigation + clear urls.
Is the wiki page actually a Xenforo Post (Thread) ?
and thus would have all of this ...
BBCode ?
Watch ?
Like ?
Reply = Comment ?
Report
New Wiki entries end up in What's New ?
Alerts for new comments, Wiki post changes, for Watchers.

It depends on what we name wiki :) Probably it was to loud naming it as wiki.
It sounds like a wiki to me !
 
I've sent you an early demo.

Yes, of course it's a thread and of course it has BBCodes/Watch/Like/Reply=Comment/Report and they end up in What's New, etc...
This way leads to compact code. But sometimes I have to step aside and extend low-level parts of XenForo. Than again continue development.
Such a way TMS, Extra Code Events and Widget System appeared. Widget System is not yet released since it requires some knowledges to tweek it.

Now I'm doing post-edits approvement by moderators.
 
We need a rating system...

create a /reviews/ section that allows for 1-5 rating with the ability to lay it out really nice like...would be awesome.
 
Some new permissions of course will appear.
I thought about tags and found that it can be a part of universal decision: directed content relations, realized by table
Code:
content_id, content_type, target_content_id, target_content_type
For example, if one wiki thread is a child of another thread, relation will be:
Code:
thread1->thread2
If thread and media include tag, relations will be:
Code:
thread->tag
media->tag
Resourse Manager could be done by using relations:
Code:
category->category
resourse->category
thread->resourse
 
Some new permissions of course will appear.
Nice !!
I'd like a chance to throw in 2 cents here about what permissions might help keep the wiki open, but minimize the opportunity for vandalism, trolling, etc.

I thought about tags and found that it can be a part of universal decision: directed content relations, realized by table
Code:
content_id, content_type, target_content_id, target_content_type
For example, if one wiki thread is a child of another thread, relation will be:
Code:
thread1->thread2
If thread and media include tag, relations will be:
Code:
thread->tag
media->tag
Resource Manager could be done by using relations:
Code:
category->category
resource->category
thread->resourse
I don't follow you here. Can you illustrate an example ?
 
Example:
thread 12 is a child of thread 33, then db-row will be:
Code:
12, thread, 33, thread
thread 12 includes tag 55, then db-row will be:
Code:
12, thread, 55, tag
 
Interesting! Why not choose the route name though instead of using thread all the time? Use route 'blog' instead of threads. LN blogs uses 'blogs' so your safe there. Use 'entry' instead of 'entries' for the blog. But use 'wiki' for the wiki and 'entry' for the wiki entry.
 
Interesting! Why not choose the route name though instead of using thread all the time? Use route 'blog' instead of threads. LN blogs uses 'blogs' so your safe there. Use 'entry' instead of 'entries' for the blog. But use 'wiki' for the wiki and 'entry' for the wiki entry.
Right, that is easy to configure and will be done as soon as we will release the addon
 
Top Bottom