Currently, when we all login to XOOPS and then hit the Admin button (which I am all sure any good XOOPS Webmaster does everyday) what do we see once we get into Admin? I will tell you! A blank page with a whole lot of buttons down the left hand side.

Now, maybe I am the only one, then again maybe I am not. But isn't all that space just wasted? Let me explain why!

Weeks in and weeks out I hear the same old question, what is your site stats, what version of PHP etc etc. Well we could use this space to give details on this and make it easier for debugging purposes.

We could use this space for site stats etc, how many users, how many user been online line blah blah blah.

This could also extend the waiting contents block as a direct link to approvals etc etc.

And I am sure many others out there would like to see other stats etc when getting into admin.

As I said, what a waste of space, maybe we should do something about it?

Please excuse English, We do, I'm Scottish!

That sounds like a great feature. Stats on hits, users, posts in the last day / week / month would be nice.

...Or at least a default to the System main menu functions.

Your forgiven on grounds of being Scottish, pmsl.

But on a more serious note, I have to agree with you, I run tons of different sections on some of my sites (One over 20+) and find it not only a waste of space, but also a pain in the back side having to scroll down to find the module I want, also this must pull more on server resources having to load the module icons every time. can;t these icons just be in that section for the admin, rather than down the side.

We're in the admin, I would personaly like to see a more of a text link approuch, and as for stats, this would be a excellent addition to all XOOPS sites, maybe include some of the following and possibly even graphical too.

+ Total hits per Day, week, month and year.
+ Total Unique hits per Day, week, month and year.
+ Most active users but groups (Access to find out how active all members are by search).
+ Most active times of the Day, week, Month and year.
+ Reffering links.
+ Leaving Links.
+ Most active sections/Modules again by day, week, month and year.

And I'm sure we could go on.

I'm with you on this Catz.

Tim

I too like the idea of a "dashboard", as it's generally called. Here's some idea's:

- Small stats window showing usage
- Waiting contents
- new & total user counts
- PM stats
- Most active pages
- moderator log (Last 5 actions)
- admin log
- server stas (PHP version, MySQL version etc)

Perhaps we could eventually have it like a small block system and have modules create "Dashboard" blocks for veiwing stats relevant to their module in the admin area. For instance, forums could include totals for posts, views, replies, new topics, most viewed etc, all in one dashboard block.

If you get a chance try out the mambo demo. (now wait a minute I like XOOPS better, much better...) there is something to be said of their admin menu however limited it may be...its effective, simple and quick. I can't remeber what site i saw it on ..but uh it was pretty slick.

Basically its just a horizontal set (if memory serves) with dropdowns, I agree we dont need the cute module buttons on our admin page!

The admin interface is under analasys at the moment, we're looking into ways to improve it

One of the things is the point CAtz mentioned, and what you said as well DobePhat. Anything else we need to change in the admin?

Herko

How about all WAITING content in 1 place? (obviously only stuff you have admin rights for)

AND a redirect to waiting content if there is any after aproving each item, otherwise a redirect to the main admin index.

In fact, pretty much ALL the admin redirects could be reworked to eliminate a click and page load.

Regarding the Mambo drop-down menu, it uses the JSCook javascript routines for admin and the code was recently moved to allow its use in both the frontend and backend. A lot of new templates are appearing on the scene with the JSCook drop-down menus. It's also possible to create tab-like menus using the same library.

For this menu to work in XOOPS, a navigation concept similar to that used in Mambo needs to exist where the menu is dynamically created based on the categories and subcategories defined for the menu items. Rather than treating menus as blocks, the concept of a navigation system needs to be integrated into the core, allowing the menu to be generated in the same fashion as a site map. The easy way out of this is blend the concept of a navigation system into something like wfsection.

The major problem with this menu, especially in admin, is the growth of the menu as more and more items are added dynamically. It eventually reaches the point where the bottom of the menu slides below the bottom of the screen on low resolution monitors. There upcoming solution for this is to modify the Javascript to behave in a manner similar to the EI6 Favorites menu where an arrow appears at the bottom of the menu when it approaches the bottom of the screen. To handle this, they have to pull the users monitor resolution from the HTTP data to compute menu size limits for different monitor resolutions. Some mind boggling show/hide layer routines need to be developed to pull this off.

Mayby not a great addition to the tread but I must say I totaly agree with catzwolf.

Mayby it would be nice if those stats could be costumized in a menu for the first admin page. Or be able to put a file in there yourself (like you do with freecontent or others like that) so you would even have more options.

edit:hmmm, it seems draven said something like I just said,(blocks etc.)quess I should read a little better ;)

Quote:
I miss a feature to update the module tables. If you install a new version of a modul by replacing the files and click update button, then changes in the table structure don't apply.
One solution should be having update infos in the xoops_version like for the regular sql-file, e.g.

This file can contain new tables, alter tables...
Now, we need to apply this file on module update like the regular sql file on module install. Thereafter we need to rename/delete the update file(or somthing like this) to prevent reapplying on the next time we click update.

Should be nice having something like this...