Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2011-07-29 21:19:03

progre55
Member
Registered: 2006-05-02
Posts: 668

Re: smd_user_manager: keep large user bases under control

Bloke

You continue to raise the bar — great plug in.

progre55

Offline

#12 2011-08-09 12:50:55

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: smd_user_manager: keep large user bases under control

Stef, this looks like an amazing plugin. Thanks for this! A candidate for core in TXP5 perhaps?

I have had buggy behaviour so far though, not sure if its my install or the plugin. On a 4.4.1 install when I open Privs and select “list” then check the option to add this privilege to a new user group and press save, the option is not saved. Well, sometimes it saves and sometimes not. (BTW, this is on that site we have worked on together).

For non-core aspects such as “smd” or “l10n”, I can’t save any other options apart from what is already checked (again I mean for the new user group).

Awesome work Stef!

Offline

#13 2011-08-16 09:30:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

Re: smd_user_manager: keep large user bases under control

jstubbs wrote:

A candidate for core in TXP5 perhaps?

Probably not, but I intend to take some of the hard work in the plugin and make it core so that the plugin can be a lot smaller! Once the privs and groups are moved to the database it makes plugins like this a lot easier to write.

press save, the option is not saved.

I’ll look into it, but I’ve not noticed it yet. Do you have any cacheing in place? Either on the server or installed by you?

For non-core aspects such as “smd” or “l10n”, I can’t save any other options apart from what is already checked (again I mean for the new user group).

This might also relate to the above, but please check that this plugin is load order ‘9’ so that all other plugins are loaded first. Then smd_user_manager takes over and alters the privs afterwards. Just a by-product of the way privs are done in Txp 4.x — and will go away when they’re eventually moved to the database. If it’s not that I’ll take a look on the site in question and try to debug it. Thanks for the report.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#14 2011-08-16 16:15:01

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: smd_user_manager: keep large user bases under control

The plugin is indeed set to order “9” so its not that. The server Joyent does use caching as I recall, but what I have seen does not indicate that this is a problem.

Offline

#15 2011-08-20 22:02:45

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

Re: smd_user_manager: keep large user bases under control

jstubbs wrote:

The plugin is indeed set to order “9” so its not that.

You’re right, that’s freaky behaviour. It appears I can make changes to all the core privs (forms, images, article, etc) except ‘list’ which refuses to add the privs to the new users. But if I uncheck Managing Editor I can then change the privs fine — well to a point; only one at a time, but they do ‘stick’. However, as soon as I recheck Managing Editor they get reset. And with the smd_ and l10n_ ones, again, you’re right: they just won’t commit no matter what.

This is very strange because it works fine on my dev site (although that’s not running MLP). I can see no reason why MLP should interfere with smd_user_manager but at the moment I’m out of ideas. I’ll try debugging it at some stage so if you see weird screen output floating around that page, it’s just my meddling paws.

The only possibility I can think of — and this is a very long shot — is that it’s because we’ve defined the two new user accounts in the admin_config.php file and for some reason it’s borking the plugin. In theory, once the accounts are created in smd_um, they should no longer be required in the core file. But I don’t suggest deleting them from the file until we’re sure the groups are registered in the plugin.

Can you check the smd_um_groups table and see if the two new groups are in there? If not, visit the plugin’s Groups subtab and Save the list, then check again. Once they’re definitely in that DB table you should (emphasis: backup database first!) be able to remove the two new user groups from admin_config.php. I’m not sure if that’ll make any difference, nor do I know if it’ll affect the custom code that relies on user ID ‘7’ (again: shouldn’t make any difference) but it might be worth a shot.

If it’s not that I guess it’s down to figuring out if there’s a bug in the plugin or an incompatibility with some other plugin or MLP. A puzzler for sure.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2011-08-21 08:52:31

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: smd_user_manager: keep large user bases under control

Stef, yes, the two new groups are in the smd_um_groups table. So, I backed up the admin_config.php, then overwrote the file with a clean one from 4.4.1. Then re-visited the User Manager.

I am able to save/change for the l10_ ones, but not TXP’s list or smd_. I changed the default theme back to Classic just to check, same behaviour. Its odd!

Offline

#17 2011-08-21 08:59:13

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: smd_user_manager: keep large user bases under control

From this site in question, jcr_dashboard is active (not sure it needs to be?) and has a reference in it to privs groups 7 and 8.

Of the other plugins, l10n also refers to group 7 as does your custom priv_down plugin. FYI. I have Plugin Diff installed for quick checking.

Offline

#18 2011-08-25 21:03:36

laptophobo
Member
Registered: 2010-03-01
Posts: 216
Website

Re: smd_user_manager: keep large user bases under control

Stef (and beta testing team), great job! I’m in the process of building a new website for a client that needs to have more control over the Users. Right now, the need is to have “members” who will have no administrative privileges — only the ability to view password protected Sections of the website (and make comments too). That said, if I were to “create a new group title” (i.e.: member) which Privilege would I assign if I don’t want them to have any privileges other than to view the password protected pages? I see that I can create a “new Privilege area” but it leaves me with per-established privilege options.

Thanks again for this great plugin. (I’ll affirm this via your Donate button now.)


Living the Location-Independent Life: www.NuNomad.com

Offline

#19 2011-08-30 09:23:01

THE BLUE DRAGON
Member
From: Israel
Registered: 2007-11-16
Posts: 558
Website

Re: smd_user_manager: keep large user bases under control

Hi thanks for this plugin, using it together with smd_faux_role makes it really cool :)

I do have one problem that I can’t check the “smd_um.usr.create” or any others smd_um privs to other users.
(I did checked it, but it doesn’t save the changes)
I want to give “Managing Editor” the ability to create new users, is that possible please?
I was using the bot_privs plugin until just before, so I turned it off, should I remove it or is it fine ?

Offline

#20 2011-08-30 09:45:06

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,495
Website

Re: smd_user_manager: keep large user bases under control

THE BLUE DRAGON wrote:

I can’t check the “smd_um.usr.create” or any others smd_um privs to other users. (I did checked it, but it doesn’t save the changes)

I’m chasing down a similar problem on another site whereby some settings are not saved. I think I’ve tracked down the issue to the fact the form on the Privs page is massive and some PHP installations have small post_max_size values and the data is being truncated (or, as I have just found, some servers use suhosin which has its own independent size limiting settings).

So the first port of call would be to check the output of phinfo() (or look in php.ini) to verify that the values are big enough. If you find suhosin installed, of primary importance are:

max_array_depth,
max_array_index_length,
max_value_length
max_vars

for both suhosin.post and suhosin.request.

You can also see if all the values are getting to the plugin by adding this line to the plugin on line 856 just after the if (ps('smd_um_priv_save')) line:

dmp($_POST['smd_um_areas']);

When you now hit a Save button on the Privs panel you’ll see some debug output. If that array contains all the ‘areas’ that you see on the page then your settings are probably ok (although the max_array_* values mentioned above might still get in the way so make sure they are large enough). If some of the areas are missing then you need to make changes to the values until they all come through ok.

One other thing to verify while you have that debug line in place is if all the Save buttons work. I’ve found that, sometimes, if you click a save button towards the bottom of the page you get no debug output but if you click, say, the one next to ‘admin’ at the top you see it. This is because the part of the form request sent back to the server is being truncated before it reaches the value assigned to the Save button you just clicked, so the plugin thinks you haven’t clicked it!

If any of the above symptoms are present, you need to alter your php.ini or suhosin.ini file accordingly. I’ll see if I can find a better way to package up the data to try and reduce the amount of data sent, but I’m not sure how best to do that without impacting the functionality (e.g. each Save button could be altered so it only saves the segment right next to the one it represents, but that might get confusing).

EDIT: oh wait, maybe you can’t edit the plugin’s settings from the plugin itself. I’ll have to check that out, sorry.

I want to give “Managing Editor” the ability to create new users

If you get no joy from the above, try hacking the plugin :-) Change line 45 to:

add_privs($smd_um_event.'.usr.create', '1, 2');

should I remove [bot_privs] or is it fine ?

If you’re happy with smd_um, then you can remove bot_privs as they offer similar functionality.

Last edited by Bloke (2011-08-30 09:49:59)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB