Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

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,395
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: 11,250
Website GitHub

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,395
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,395
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: 619
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: 11,250
Website GitHub

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

#21 2011-08-30 09:59:20

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: smd_user_manager: keep large user bases under control

Ah, I just remembered that I don’t allow alteration of the smd_um.* privs in case it blows up the plugin. Although the values are saved to the database I specifically forbid them to be reimported into the page (lines 1229-1232 of the plugin).

If this is a problem, I can take one of two courses of action:

  1. Hide the smd_um strings from the privs pane so you can’t edit them
  2. Allow you to edit them: caveat utilitor!

What is preferred?


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

#22 2011-08-30 15:07:02

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

Re: smd_user_manager: keep large user bases under control

Hi Stef, and anyone else. Was checking on #18 above.


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

Offline

#23 2011-08-30 15:43:33

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: smd_user_manager: keep large user bases under control

laptophobo wrote:

to have “members” who will have no administrative privileges — only the ability to view password protected Sections of the website

You can add a new group called ‘members’ and just assign no privileges. That would lock such people out of the admin side completely and you can then roll your own front-side login mechanism using this new group. The Privs are only for admin-side access. Combined with rvm_privileged and some login-fu you could run some front-of-house password protection system that required login.

However, sometimes it’s actually more useful to open up a tab or two on the back end and do stuff there. I can recommend smd_tabber (hehe) so you can add a dashboard to the Home tab (a.k.a. tab.start behind the scenes). If you wanted to go this route then just create a new tab on the Home tab from smd_tabber, add that tab and tab.start privs (and perhaps tab.admin + admin + admin.edit if you wanted them to be able to edit their own profile) to your new group and set the Advanced Pref to make the dashboard tab the starting point after login.

Then you can offer a login prompt link from the front of house, it redirects to the standard Txp login box, your members login and the first thing they see is a dashboard. On there you can supply links to cool stuff like “recently viewed” articles or “stuff owned by you” or “membership things to look at now you’re logged in” and so forth, which redirect back to the actual public side articles or resources.

Using the admin side as a halfway public side has some great advantages because pages can be built much quicker than doing it manually on the public side.


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

#24 2011-09-01 13:25:22

Teemu
Member
From: Shanghai
Registered: 2010-04-27
Posts: 60

Re: smd_user_manager: keep large user bases under control

Stef,

Thanks for a great plugin. I have request for little help.

I have manually added some fields to the txp user info and the database table. I’ve added the strings and got additional text fields and text areas working alright, saving and everything, but have problem when trying to use select,radio-buttons and checkboxes.

I can’t really code, but get around by using common logic.

Duplicating the code, I get additional text field to show up in the user info table like this example:

.tr( fLabelCell('Phone', '', 'phone'). fInputCell('phone', $phone, '', 30) , ' class="phone"')

How could I display a select field with lets say two options?

I’ve tried to find some working examples from the source and apply them, with no luck.

Offline

Board footer

Powered by FluxBB