XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk
  1. Board index / 
  2. Xoops Development / 
  3. Roadmap 
  4.  / XOOPS 2.1 Core development Roadmap
Register
31
Big_Bro
Re: XOOPS 2.1 Core development Roadmap

  • 2003/10/31 22:02

  • Big_Bro

  • Just popping in

  • Posts: 52

  • Since: 2003/2/26


I think the problem is that nothing much is happening on the modules side, and I can see Malexandria's point from a content providers side myself, to those of us who don't code, XOOPS is a black box and we don't see the distinctions between modules and the core, just the finished product. From our admittedly limited perspective, modules are things such as Friend Finder that add functionality beyond what we downloaded when we first installed xoops.

I had more to say but if this is just a pure core discussion I'll just quote what I wanted to say until a module discussion of these important points is begun.

Quote:
I have always seen the news module and other basic modules such as members as part of the core even if they are really just modules, because without them you have nothing to present to the world. That may be technically incorrect but overall a CMS without a method of displaying content is just a database.

Malexandria touches on some good points that bring up a very important directional question for the future of XOOPS in my opinion.

The internet is based on content, nobody visits a website because they admire the well designed administration interfaces, and end-users cannot see nor really appreciate a well designed caching system for instance. Those are great things to have for us as webmasters, no doubt about that and XOOPS is a very stable and well written system, but to me it's like having a Ferrari frame, suspension and engine (the XOOPS core) with a '73 AMC Gremlin chassis on top, (the UI's). You just won't get the chicks until you install a sleek red chassis, regardless of how much horsepower is under the hood.

I've painted my Gremlin chassis and pounded it out with a hammer to shape it more like a Ferrari, but I am not a programmer and it's still kinda obvious that my site looks more like a pounded out Gremlin than the Ferrari it really is under the hood, and that as a webmaster bums me out, it actually takes my desire to work on the site away because I know that I can't do many of the things I want to so I get discouraged and try to accept less, which is very hard for me.

I don't know what the developers goals are for xoops, but XOOPS usage would quadruple in short order with better and easier tools to display, highlight and organize the most important part of any website, the content. In my opinion that should be first and second priority after a stable core is built, and we do have a stable core.

Draven really, really gets the idea of presentation in his site and we as XOOPS users are fortunate he is part of the team now. As far as I'm concerned there is no better CMS-based website than his gaining-mass.com site, in terms of presentation, organization, and just plain wow factor, it leaves you with the idea that you need to come back again and see more or you will miss something. If even some of those presentation tools were available as a part of XOOPS it would put some serious distance between XOOPS and the rest of the CMS pack.

These are all my opinions as a news content provider so your experiences may vary, but I see presentation as the most critical need for XOOPS to surpass the rest of the CMS field.
32
hrac
Re: XOOPS 2.1 Core development Roadmap

  • 2003/10/31 22:06

  • hrac

  • Quite a regular

  • Posts: 305

  • Since: 2002/7/15


Hello,

Some of them noticed before but I want to repeat some of them:

1. LDAP integration: LDAP integration is a must for an intranet CMS solution. I made an LDAP integration for XOOPS version 1.3.4. I'm willing to joing to core team to add LDAP integration to core of version 2.1.

2. Center blocks (center center, center left-right) blocks should be ordered with weights.

3. Registered users' may change their homepage (they may change some of blocks location or may hide some blocks or unhide some of them). For example some users may be interested in recent link, some of them interested in recent downloads, or online users. They can enable to show certain blocks.

4. New user registeration forms should be modified, added new fields such as birth date, snail mail address, etc

5. And some modules (I know there will be another thread):
Some modules should be placed in core package: A built-in (and strong) statistics module, wfsection (it will be in core I know), newsletter and phpBB2

Best regards
Hirac
33
ackbarr
Re: XOOPS 2.1 Core development Roadmap

Quote:

svaha wrote:
3) A deeper look into security issues on one hand, making it easier for users (like autologin) on the other hand.
4) An extension of the groups right system, giving the admin more flexibility.


Svaha - can you explain further what you envision on these two points? What type of security issues have arisen that need to be addressed? What would an extension to the groups rights system allow for that the existing one doesn't?
34
ackbarr
Re: XOOPS 2.1 Core development Roadmap

Quote:

1. LDAP integration: LDAP integration is a must for an intranet CMS solution. I made an LDAP integration for XOOPS version 1.3.4. I'm willing to joing to core team to add LDAP integration to core of version 2.1.

This feature is a high one on my list as well. I for one would welcome your help on this feature.

Quote:

3. Registered users' may change their homepage (they may change some of blocks location or may hide some blocks or unhide some of them). For example some users may be interested in recent link, some of them interested in recent downloads, or online users. They can enable to show certain blocks.

A very interesting idea, and one I had not heard expressed before (or perhaps in this way).

Quote:

4. New user registeration forms should be modified, added new fields such as birth date, snail mail address, etc

This feature is part of the dynamic user profile (see Herko's post or my first post in this thread). Instead of forcing fields into the registration / user profile screens, an admin will have the ability to create new fields.


35
ronhab
Re: XOOPS 2.1 Core development Roadmap

  • 2003/10/31 22:58

  • ronhab

  • Friend of XOOPS

  • Posts: 160

  • Since: 2003/4/27


This is my wish list, some of which may be "core" and some are "modules".

1. Correcting the cache system and how it handles permissions. Also extending it so that stories can be cached and not have to hit the database/be generated on each read (similar to the mod_rewrite feature people were requestiong earlier).
2. Moderation system for comments, users and/or stories
3. Customization of the home page by registered users (MyYahoo type of functionality)
4. Cleaner/more functional admin area
5. Mark all read function for NewBB
6. Friend/foes system ala Slashdot
7. Improved avatar management (mass upload avatars in zip/gz)
8. Privacy feature for who's online block
9. More granular user permissions
10. LDAP integration




36
WizarDave
multiple instances

  • 2003/11/1 6:38

  • WizarDave

  • Just popping in

  • Posts: 5

  • Since: 2002/2/6 2


Maybe the core could allow for multiple instances of things.
Such as:


* multiple instances of XOOPS for subdomains using the same core files...
Kind of like about.com does
*** If you do that one:
search from main domain can also search subdomain content.
search from subdomain only searches that subdomain's content.

* multiple instances of modules...
So you could have multiple BBs or links, with or without subdomains.

that's my jabi (Just Another Bright Idea)

37
basby
Re: XOOPS 2.1 Core development Roadmap

  • 2003/11/1 7:33

  • basby

  • Not too shy to talk

  • Posts: 109

  • Since: 2003/1/28


1. I would find it usefull to have one code base for several websites. This means per website
- a theme
- block management
- content

2. Also usefull would be if the admin can create his own forms like in eZpublish. In eZpublish the admin can create his own classes and instances of it. An example of a class is "vacancy" with the fields
- Company
- Vacancy name
- Start data
- Salary
- Contact person
etc.

People can then submit vacancies according to this class definition.

By the way, XOOPS is fantastic!

Basby
38
markoh
Re: XOOPS 2.1 Core development Roadmap

  • 2003/11/1 9:05

  • markoh

  • Just popping in

  • Posts: 13

  • Since: 2002/5/14


I think one of the main core functions that has to be expanded/altered is the permissions system, it's now group based.

I think a permissions system on a user base with something like:

Read
Read-Write
Admin

Would give you much more flexibility.

39
foniks
Re: XOOPS 2.1 Core development Roadmap

  • 2003/11/1 11:58

  • foniks

  • Just popping in

  • Posts: 7

  • Since: 2003/10/10


Big Core request:

Permissions.

I'd like to see everything treated as an object with permissions in a child parent tree. Each forum post, download, article, news item... not just categories or sections. Permissions should also be inheritable so that child objects get the parents permissions but can be modified to include more or less permission for groups or users. Child objects can be moved to new parents and inherit their permissions as well.

Each object includes a way to link to it's settings, ie: it is referrable via url from a page or from admin section. For instance, when you list all articles there is a link next to each that will give you a permissions edit page. Also on each article page there is a link for same (viewable only by admin). Each type of object should have a list capability in admin. This would be for editing as well as admin functions. A toggle for showing group(/user) access rights as well so you can audit the objects without having to click each one. Alternatively, admining a group should show a list of objects they have access to.

Users/Groups:

All Users are virtual Groups. Treat them both the same except that Users have a flag set that they only have one member. Groups can have limited number of members. Groups can include Groups, which is necessary for Users to be treated as Groups. Groups have child parent relationships with other Groups, ie: Anonymous is parent to all, Registered is child of Anonymous and Admin is Child of Registered... all other Groups are children of Registered. Group permissions are inherited, So when I create a new Group under Registered I don't have to assign anything old, just new stuff.

Anonymous - Login, Read General News, Read Articles A, B, D, Read Forums A, C
.....|
.....Registered - Same as above plus: Submit General News, Read/Comment Articles C, E, F, Read/Post Forums A, B, C, D
..........|
..........New Section View Group - Same as above plus: View/Submit Section News, Read Articles G, H, I, Read Forums E, F
...............|
...............New Section Editor - Same as above plus: Edit Section News, Edit Articles G, H, I, Edit Forums E, F
....................|
....................New Section Admin - Same as above plus: Admin Section News, Admin Articles G, H, I, Admin Forums E, F
..........|
..........Another Section View Group - etc.

..........|
..........Admin - Admin all and Users, Groups


Of course modules should be able to use these new hooks, encouraged to use them....
40
chapi
Re: XOOPS 2.1 Core development Roadmap

  • 2003/11/1 12:02

  • chapi

  • Theme Designer

  • Posts: 611

  • Since: 2002/1/22


Here is my wishlist ...

- wysiwyg editor as a standard of the core, so it can be used in the modules, maybe additionaly to the normal xoops-editor, which should also be enhanced like draven mentioned

- enhanced image manager, ability for subcategories, ability for uploading other formats as zip, pdf and so on for being a real media manager, ability to sort the images by name/date/size

- enhanced pm system with inbox AND outbox, maybe this should be converted into a modul

- smarty templates for the userinfo sites!

- I can detect the module which is currently viewed in my theme.php (as draven and shava showed in their post), I also hacked this for my site a little bit, but with this method I can't detect the userinfo sites or the startsite if there is no startmodule. Maybe something to detect whether it is the startpage of a module or a subsite of a module would also be good.

- ability to set blocks for EVERY page of a module, not only for the modules globally

- better mainmenu handling, I would like to add links to the mainmenu like in imenu, ability to add more mainmenus as only one

- ability to use grouprights in the admin area, maybe based on categories (don't know if this already works)



... at the moment I'm out of ideas, but this are the important things for me at the moment!
« 1 2 3 (4) 5 6 7 ... 10 »

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

387 user(s) are online (259 user(s) are browsing Support Forums)

Members: 0

Guests: 387

more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Nov 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits