Portal/CMS

  • Thread starter Thread starter ragtek
  • Start date Start date
The widget framework that is currently out, is awesome as a portal substitute. I have used that in the past and would still use it now if it weren't for the fact that there are actually more modules available for xenporta than the widget framework. So whatever you create should have some useful images, most important of which being a slider and a recent posts and threads block.
the main target is to use the bd widget framework ( http://xenforo.com/community/threads/enhanced-pages-paid.30259/page-3#post-385488 )
 
I would be VERY interested in a Portal/CMS whether it be free or paid. As far as I'm concerned there's no viable ones out at the moment.

Agree with 8thos and would add the one feature of XenPorta was t he ability to promote threads.

Happy to help with testing if necessary as well.
 
yea, it doesn't make any sense to reinvent the wheel again
there are already several different block/widget manager, which aren't compatible..
if you use one, you're probably not able to use the other, that's why i had to give up my sidebar block manager :( RIP
blockoptions-png.14315


i just wish something like this would become a core feature, so the addon coders would get a interface and code all the same type of blocks...:(
till this happens, it makes IMO sense to support the "best" public available 3rd party addon and that's definitly bd widget framework:)
 
Yeah I settled on Widget Framework as it was *basically* what I was going to code so might as well use what is available and contribute back widgets.
 
Has anyone made a portal page that only uses the Widget Framework widgets? I'll probably do it later this week if no one has.
 
It'll be a second placement option. Right now it only targets the sidebar, I'll be adding a way to target the main content.
 
So I've got a very crude version of the portal working.
Pluses it uses the framework and the same style admin page.
Minuses the portal page main content area is configured on one page and the sidebar for the portal page is still configured within the main Widget Framework (WF) admin screen. That's the cleanest way to do it without modifying WF.
 
Still a couple days of work to be done.
That's Alpha and the first release.

Changed url to 'home' in order to not conflict directly with EWRporta. This allows the admin to disable porta but not completely uninstall it.
 
Version 1 of the portal will have a fair amount of duplicated code from WF. Version 2 will ship with a forked version of bd that will reduce the amount of code duplication. Hopefully, I can commit the forked version back to the current version of bd assuming xfrocks is okay with that.
 
Version 1 of the portal will have a fair amount of duplicated code from WF ([bd] Widget Framework). Version 2 will ship with a forked version of bd that will reduce the amount of code duplication. Hopefully, I can commit the forked version back to the current version of bd assuming xfrocks is okay with that.


What's the goal in minimizing [bd] Widget Framework code ? I've only heard good things about it.
 
Not minimizing, enabling reuse of bd code. The framework is great (hence why I'm using it as the basis for the portal), but there's a fair amount of code which I had to duplicate and only change a few items (db table names, template names, etc). I'm going to change the setup of the code slightly in order to allow my add-on to not duplicate WF code.
 
But why ?
xfrocks won't mind, or will it cause an error ?
No errors immediately, what could cause issues is when someone is running a different version of WF then what was used to develop WidgetPortal.

For instance, I'm developing with the current version of WF. Say xfrocks releases a new version, most likely I'll need to upgrade WP to incorporate the new version of WF. Instead of this, if the code is setup differently to allow more code reuse it won't matter what version WF people are on. With the current version of WF this is impossible, but with a few changes it will be.
 
Top Bottom