Roadmap: Enhanced Admin GUI

[geekwright]

@bitcero, Eduardo Cortes, is currently working on an improved GUI layer for system administration.

[bitcero]

The new GUI for Xoops admin will be totally different from previous. This will include new elements available for designers/developers modules.

---

Theme

A new theme called Hydrogen that derives from the experience acquired with Common Utilities and based on Bootstrap 3. This theme will provide all graphical elements for admin section and its colors will be customizable.

This is the current progress of graphical elements, but there are a lot of work left.

New Elements

There are new elements in this GUI, availabel for modules:

• Main bar (at top of theme)
• Menu bar (sidebar) that can be positioned at top, below the main bar, or the left (currently). The menu bar will be a directly access to any page of modules trough the collapsable menu.
• Page header, where modules can show a title and icon (optionally) to inform user where are located. Also, the header can contain buttons or other elements.
• Toolbar, that can contain buttons with actions to access functions from modules.
• Widgets that will be small graphical elements to show information from modules. The widgets will be available trought the service manager.

---

All changes pretend to maintain compatibility with current code, but in some cases, to use the new elements, new code will required.

Very important: You can participate with ideas and working on changes. Please contact me.

---

What is needed?

• Definition of all graphical elements.
• Adapt existing module from 2.6 branch to use new GUI (templates)
• Define the Xoops dashboard.
• New usefull widgets that will be provided by default.
• ...

[txmodxoops]

I think that the first image is good for default in XOOPS 2.6, and the structure is good, I don't think you should add more for the moment :+1:

I think you should simply call cpanel without deleting the actual default.

[mambax7]

Eduardo,

I can only say one thing: AWESOME!!!! This is an EXCELLENT START and exactly the process that I have envisioned, i.e. to see:

a) what features should Admin Themes and our new "Presentation Layer" have, and b) what is needed from Core to make it happen

So I very much appreciate you showing us your vision, and then spelling out for us what needs to change in Core to enable it!

Once again, congratulations on this awesome start - the first steps are always the most difficult, but once we have the new Presentation Layer in place for our modules, XOOPS will shine again!!!

[alain01]

Hummm, i want it Nowwwww ;-)))) Great work !

[geekwright]

Continuing a conversation that started elsewhere, regarding SVG icons.

I fully agree. We need to focus on the best for tomorrow, not the best for a few years ago.

I am fine with that approach. :+1:

[geekwright]

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject
{
}

Then, in modules/system/menu.php, the event would be triggered something like this:

$systemMenuList = new SystemMenuList($adminmenu);
\Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList);
$adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus)
{
    $menuItemToAdd = array(
        'title'     => __('Title', 'domain'),
        'link'      => 'landingpage.php',
        'icon'      => 'xicon-icon'
    );
    $menus->append($menuItemToAdd);
}

The menus get passed around as an object, so there is no worry about passing by reference, and we will get an error if the type does not match, so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon)
{
    $this->append(array($title, $link, $icon));
}

With the class, there is a layer where implementation details can be adjusted if needed. And it makes the code more self documenting and robust.

[bitcero]

Very clear... and instructive as always.

I'm agree with you.

2015-05-19 16:12 GMT-05:00 Richard Griffith [email protected]:

Re: triggerReturnEvent() ...

Ok. Can you provide me some example to implement?

First we would define a class. In this case, an ArrayObject would do. We give it a name, so everyone knows what we are talking about.

class SystemMenuList extends \ArrayObject { }

Then, in modules/system/menu.php, the event would be triggered something like this:

$systemMenuList = new SystemMenuList($adminmenu); \Xoops::getInstance()->events()->triggerReturnEvent('system.admin.menu', $systemMenuList); $adminmenu = $systemMenuList->getArrayCopy();

Finally, a listener could look something like this:

public static function eventSystemAdminMenu(SystemMenuList $menus) { $menuItemToAdd = array( 'title' => __('Title', 'domain'), 'link' => 'landingpage.php', 'icon' => 'xicon-icon' ); $menus->append($menuItemToAdd); }

The menus get passed around as an object, so there is no worry about passing by reference, and we will get an error if the type does not match, so we shouldn't be trying to process garbage.

The class could be modified as needed. For example, adding a method like:

public function addItem($title, $link, $icon) { $this->append(array($title, $link, $icon)); }

With the class, there is a layer where implementation details can be adjusted if needed. And it makes the code more self documenting and robust.

— Reply to this email directly or view it on GitHub https://github.com/XOOPS/XoopsCore/issues/252#issuecomment-103668571.

[redheadedrod]

Looks very Nice.

I have been using Drupal to make some pages for a local team and it has been an experience. I would like to share how their modules stuff looks as a suggestion for something that we could consider to work towards.

Basically they show if it is enabled with a check box.. To enable one just checks the check boxes and hit submit and they are enabled as long as the required modules are also enabled. If any required modules are NOT enabled then it will enable them as well. I will attach a screen shot for an example.

At a minimum I think we should be changing up the Xoops modules for 2.6 and instead of the "Official" and "extension" tags we need to remove all that and just add a Categories tag.

This will allow us to group like modules together like they are on this drupal example. While their modules page is very plain I am sure we can do better but this is atleast a start.

They also show required and dependent modules as well as if there is a help screen and allow permissions and configurations right from this screen. But this would be a new modules module... We need to start somewhere though.. Not sure if you really want the modules to all be listed on the main admin screen since you can have literally hundreds of them eventually. Especially with the new service manager and other stuff up and coming.

[bitcero]

Report of progress

---

There are some changes made in Xoops GUI:

Header commands

Added support for «header commands»: elements that can be shown in page header.

Commands can be added trough \Xoops\Core\Helper\HeaderCommands.

Admin buttons

«admin buttons» is a special area where buttons can be added to provide actions in a module. Admin buttons as controled with \Xoops\Module\Admin() and added trought method addItemButton().

Modules manager (in progress)

The modules manager has been updated to make it more intuitive and better looking. Existing modules can be displayed as list or cards (as in previous GUI). Also the modules manager has been moved to modules/system/modules.php and still is in progress, but I have some progress and I can show.

Contextual options (item options)

Added support for a new contextual options (or item options) in order to make it more easy to use and implement.

Options are shown below to item (in table row) and activated/deactivated with a command button. (The above image show the item options for module item in modules manager).

New javascript interface

I'm starting the replacement for standard javascript functions contained in xoops.js file. Now all functions will replace for xoops javascript interface for better access. This interface will be an object that can be called in next way:

xoops.function();

This interface can be easily extended to increase its functionallity and make all available for other components.

New dialogs using bootstrap

Now the bootstrap modal component is available trough xoops javascript interface that uses bootbox to create dialogs easily. Dialogs can be created by using:

// Alert
xoops.modal.alert('Alert text');
// Confirm
xoops.modal.confirm('confirm');
// Custom dialog
xoops.modal.dialog({
    title: response.title,
    message: response.content,
    color: 'primary',
    buttons: {
        main: {
            label: response.close,
            className: 'btn-primary'
        }
    }
});

Note that bootbox has been modified (small modifications) to provide some new capabilities to dialogs.

Dialogs can be colorized by using the options 'color' when dialog is created:

xoops.modal.dialog({
    title: '...',
    message: '...',
    color: 'primary'
});

color can be: primary, info, success, warning, danger, azure, sky, palegreen, pink, indigo, midnight, orange, yellow, brown, alizarin, purple or magenta. Some exmaples:

---

Note: The above examples are based in dialog for «system module details» and is incomplete. I'm working on that.

---

Modules logo

I've changed the logo for system module, and I hope that all logos for current modules can be changes to provide a new consistent appearance.

I can provide templates to adapt current logo images.

---

Some additional changes has been made but I'll post in another report.

I wait your comments and feedback.

---

Important: this changes are not in the main repository but you can find in my XOOPS fork.

Todo list:

• [x] Complete modules manager
• [ ] Start blocks manager (lot of changes)
• [ ] Start users and groups manager
• [ ] Start module settings forms
• [ ] Update modules templates
• [ ] Update xoops_version files for modules
• [ ] ...

All help is appreciated and welcomed!

[mambax7]

Awesome work, Eduardo!!! :yum: :smile: :+1: :+1: :+1: :+1:

I'll need to install your fork and test it to give you a more meaningful feedback, but so far it looks AWESOME!!!! :yum:

[geekwright]

I agree with Michael, AWESOME!

Sorry to be so slow in responding. I'm still catching up after vacation. I'll get a full review as soon as I can, but everything looks and sounds fantastic.

[bitcero]

Updates

These are the last updates in X26 GUI:

System admin sections has been migrated to a separate URL. Now, instead of use system/admin.php?fct=users the system module use system/users.php. This change offers a more semantic URLs and encapsulated code to improve maintanance.

Report of changes

---

Preferences

New settings manager for modules. The new design is cleaner and responsive to maximize its functionality.

• Dynamic settings. System is capable to load options dynamically to improve the development flow and updates.
• Avoiding the old form tabs based on jQueryUI. Now bootstrap is fully integrated with tabs and, with this change, I'm prevent to embed HTML code in form PHP files.

Users management

Also the users management has been ported to new GUI.

Groups management

Groups management has been ported to new GUI.

---

Other changes

A lot of changes has been made in order to get this working, but more work is left. However, I think that the new GUI is pretty functional and modules templates can be adapted to new appearance.

[mambax7]

:+1: Awesome progress!!!

[alain01]

:+1: Very nice Work ! Just 1 question for the modules. if the web site use lot of modules, i "m afraid that it would be not usefull to see the modules in a vertical list, no ?

[txmodxoops]

When will it be available for testing?

[bitcero]

@alain01 The sidebar menu is scrollable to navigate trough modules list, however I'm planning to include a "quick search box" to find modules easily.

[bitcero]

@txmodxoops You can try my fork, but I not tested it on standalone installation... btw, you can help me with this and check if it is possible to install it...

[txmodxoops]

I think you need to update the Core Master, because it gives this error in installation

http://localhost/XoopsCoreBitcero-master/htdocs/install/page_siteinit.php

Fatal error: Unsupported operand types in D:\wamp\www\XoopsCoreBitcero-master\htdocs\xoops_lib\Xoops\Core\Kernel\Handlers\XoopsModule.php on line 94 Call Stack

Time Memory Function Location

1 0.0005 291336 {main}( ) ..\page_siteinit.php:0 2 0.2491 7032824 SystemModule->install( ) ..\page_siteinit.php:62 3 0.2571 7494936 Xoops\Core\Kernel\Handlers\XoopsModule->loadInfoAsVar( ) ..\module.php:208

[loriga]

Great work!

[kevinpetit]

Is there a new update? :)