Community

Forums » SEPHP Feature Requests

Adjusting the Admin area - Total Row Counter (RC)

    • 15 posts
    October 7, 2017 11:22 AM EDT

    Feature Request: Adjusting the Admin area - Total Row Counter (RC).

    Feature request sequence:  B

     

    Description: It will benefit every admin of the SE software; The admin area is more user friendly after changing the width to the full width 100% of the page so there is more room for new options.

    After this change it would be beneficial to have a variable row counter within the admin area only. There is no consistency with the number of rows shown in any module SE or third party, it is what the developer thinks is right. This needs changing. This will need to be a new feature. This also has be used by third party developers.

    This is a requirement, not an option for third party and SE developers.

    Take for example SE User Manager, only shows 10 users(rows) per page out of the box, even if you use the search it is still not enough.

    If you are working with a large database of users it will be beneficial to have a hover over function on the rows of data, which can be edited from the CSS if you like a different colour. Say we go for a light yellow to start with #fff5cd ( can be edited from CSS)

     

    This request is: for a new Row Counter(RC) variable setting within the Global Settings.

    An admin can set the total rows show per page from 0 - 999 see example image

    The RC should reflect on any page how many rows of data are shown. (Still using the previous/next pages at the bottom if it is more or less than the set setting)

    A hover over function on the rows starting with a light yellow background color #fff5cd, which is edible in the CSS to adjust to the admin needs. 

    This RC is not an option for a third party or SE developer, it is a requirement to use this new setting.

    If SE is accepting this new feature, and rolls out the new update, it should add this to the Global Records settings with a standard value of 100, which can be adjust later the update.

     


    This post was edited by Maurits at October 7, 2017 11:28 AM EDT
    • 681 posts
    October 9, 2017 9:15 AM EDT

    Yikes wow. It's a good idea but then I think of the new clients who have never had a site. They would put it too high and crash their sites. Pulling a large amount of data on anything other than a cloud, or multi-server (maybe even high availability) environment could be disastrous. That's the issue on another script. It pulls the entire user table even though it only shows from 25-100 by drop down choice but it crashes big sites when going to either user browse front end or user manage back end. Crashing a database is a bad thing as it can create corrupt tables, missing data and an unstable database. This needs more thought on how to implement it in the best way for all involved. You seem to know what you are doing and so users like you would know how high they could safely set it. What it needs is some sort of safeguards for those that don't and may be on shared or VPS server environments. I do like the idea though.


    This post was edited by Donna at October 9, 2017 9:17 AM EDT
    • 15 posts
    October 9, 2017 11:17 AM EDT

    The other alternative could be an option button list before the [list of rows: 0-999] which will limit the rows you can pull from the database. This will not interfere with the database usage then.

    Choose server type:

    O - Standard server

    O - Cloud server

    O - VPS

     

    If an option is ticked say:

    Standard server: 0 - 50 rows

    Cloud: 0 - 500 rows

    VPS: 0 - 999 rows

    then the admin can only select the amounts between these values, with a warning: do not increase the setting if you don't know what you are doing, it might corrupt your database.

    Default: "Standard server" ticked with setting "List rows per page: 10"

  • gs
    • 264 posts
    October 9, 2017 11:18 AM EDT
    - I prefer it optional to 3PDs, not required.
    - IMHO, default should be low to prevent issues
    - I personally would never set this high because loading for some pages wouldn't be instant.
    - I prefer 'more' loading vertically like an activity feed so ADMIN may scroll the data. Imagine an activity feed that used prev/next pages.
    • 15 posts
    October 9, 2017 11:48 AM EDT

    @GS I am working on a cloud server, there is nothing more annoying than flicking through pages and pages of 10 users. Even If I use filters, I can not see in an instant where a user is.

    On a same cloud server on another website, not SE. I pull over 5000 categories 5 tier deep, I set the setting to 10,000 rows per page, so it is easy to scroll, edit and add new categories. No hassle of corrupting the database. It takes about 5-10 seconds to load, and you can work freely on any subcategory, make adjustments, put new html in per sub category, etc.

    I don't know how the indexing is done on the user table, instead of pulling ALL data in, it would be better to pull in the userID number instead, and when you pull up the page it only will pull in the data corresponding to the users. In this way you do not pull in ALL the data at once and don't slow down the database for corruption. When you click next-page the next data will be pulled in from the User database-tables

  • gs
    • 264 posts
    October 9, 2017 11:54 AM EDT
    RE Selecting Server Type
    - IMHO using these categories isn't helpful because they're not absolutes and there's many more factors to consider besides just the type of server config one is using.
  • gs
    • 264 posts
    October 9, 2017 12:01 PM EDT
    Then maybe a compromise to allow a setting on each page to override the global setting.

    This way each ADMIN may make their own determination. For example I may set the global low (say 20 or whatever) so pages load instantly, then on pages where I want to scroll lots of data and don't mind non-instantaneous response I could make the setting much higher. Besides, reading data should never corrupt the database, nor should it crash a site (unless the software doesn't have safeguards to 'sense' and prevent the crash).
    This post was edited by gs at October 9, 2017 12:03 PM EDT
    • 15 posts
    October 9, 2017 12:20 PM EDT

    @gs the compromise can be set in the 'Total rows per page', so no need to set it per page. If you think it loads too slow, adjust your RC to a lower setting so it loads the page to your liking. If you want it set to 10 you do so, so your page loads in an instant. I prefer mine to have at about 500+ rows per page as I am using faster equipment to produce pages which doesn't slow down the database.

    • 15 posts
    October 10, 2017 9:09 AM EDT

     @ Donna:

    Did you read the 3rd post from the top?

    That could be an option.

     

    or

     

    Create a new hidden setting in the database in the:

    table: engine4_core_settings

    field: core.list.rows.per.page (new field) default value 10

     

    This option is not changeable from the admin panel. Only admins who require more rows per page can change it to whatever RowCount.

    The software should detect a limit of a max from 999, so If the admin adds a number of 10000000000 in the database then the software protection will kick in:

     

    IF core.list.rows.per.page >'999' THEN core.list.rows.per.page = '999'

     

    If the admin doesn't change this setting the standard value will be 10 as it is now in the admin panel. This will protect the 'new' customers using the software for the first time on a shared hosting plan.

     

    Also 3rd party developers should read this value to sort 'List rows per page' in their software modules.

     

    Maybe this last option is better?


    This post was edited by Maurits at October 10, 2017 9:12 AM EDT
    • 681 posts
    October 10, 2017 9:13 AM EDT

    Yes the suggestions in here are good if this is accepted when we look at features again. We are working through 4.10 first and once it's released in beta or RC, we will then start looking at features again. The flash being removed is a major removal and so right now we need our core developers on that item as well as the other things we will have in 4.10. :)

    • 15 posts
    October 10, 2017 9:18 AM EDT

    @Donna, do you know which file I can change to increase the User Rows as a temporary measure?

    • 681 posts
    October 10, 2017 10:21 AM EDT
    Maurits said:

    @Donna, do you know which file I can change to increase the User Rows as a temporary measure?

    THE FOLLOWING IS FOR EXPERIENCED USERS ONLY. IT IS A CORE EDIT AND COULD CAUSE ISSUES FOR THOSE WHO ARE NOT FAMILIAR WITH MANAGING SERVER RESOURCES, FOR THOSE ON SHARED HOSTING OR FOR THOSE ON VPS HOSTING. YOU ASSUME ALL RISKS IF YOU DO THESE EDITS! SOCIALENGINE WILL NOT FIX ANY ISSUES CAUSED TO YOUR SITE OR ASSUME ANY LIABILITIES FOR SUCH.

    Ok the following is for the member manager. You'll want to check each module to change or add this. I had to add it for the member manager as the limit wasn't in it. Backup the site before changing anything and save a copy of the original. I found the below from the Albums controller (same file name). I assume each module has its own paginator settings or has no settings such as the User one and that defaults to some main setting someplace if it has nothing specified. Change the "25" to the value you want to show. Experiment on a development site and good luck. I can't guarantee no issues from this or what would happen with large queries.

    in application/modules/User/controllers/AdminManageController.php I added the following at line 79:

    $this->view->paginator->setItemCountPerPage(25);

    so it looks like this:

    // Make paginator $this->view->paginator = $paginator = Zend_Paginator::factory($select); $this->view->paginator->setItemCountPerPage(25); $this->view->paginator = $paginator->setCurrentPageNumber( $page ); $this->view->formValues = $valuesCopy;