Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I just installed Better Formats. When I create a role like 'admin' or 'staff' - they do not show up under Input Filters > Defaults. Only anonymous and authenticated show.
Comment | File | Size | Author |
---|---|---|---|
#20 | better_formats_roles.patch | 3.42 KB | dragonwize |
#19 | better_formats_roles.patch | 2.83 KB | dragonwize |
#10 | 731810.patch | 1022 bytes | grendzy |
Comments
Comment #1
kevinquillen CreditAttribution: kevinquillen commentedSo this only works with brand new roles and not existing ones? I created my roles before BF was turned on.
Comment #2
kevinquillen CreditAttribution: kevinquillen commentedI had to manually insert the records into better_format_defaults to get this to work with existing roles. Is this normal?
Comment #3
dragonwize CreditAttribution: dragonwize commentedNope. I just tested on a blank site with roles created before hand and it works fine. By the fact that thousands of people have tested this without issue and the install hasn't changed in a long time that leads me to believe that something is up with your install. Maybe your install did not finish normally. I've seen that happen before if you have a slow server with little allotted RAM to PHP and you try to install several modules at once or have a huge module page with 100's of modules.
I would suggest for you to uninstall the module and reinstall. Adding the entries by hand may cause you issues unless you follow the exact logic in the install file all the way through.
Comment #4
kevinquillen CreditAttribution: kevinquillen commentedThe only difference I can think of is we have a install profile that automates our Drupal install and the modules we use.
Comment #5
kevinquillen CreditAttribution: kevinquillen commentedCould have been what you mentioned about PHP. I think there are about 60 modules in the profile. Seems to work okay, I tested a few roles.
Comment #6
grendzy CreditAttribution: grendzy commentedI can confirm this is a real bug. Steps to reproduce:
Install Drupal (6.16)
Enable Better Formats (1.2)
Disable Better Formats
Add a role
Re-enable Better Formats
The role will be missing from /admin/settings/filters/defaults. Completely uninstalling and re-installing the module will bring it back.
The problem seems to be that new roles only come into the system via hook_form_alter(), and hook_install(). So if a role is created via install profile, Features module, or database insert, it's not known to better_formats.
I think the solution is to LEFT JOIN instead of INNER JOIN in better_formats_get_role_default_fields().
Comment #7
kevinquillen CreditAttribution: kevinquillen commentedAlso, even if I explicitly set user permissions for anon and auth to not have Better Formats after its been installed in an install profile, its not respected. All permissions are on once I get inside the admin.
Comment #8
dragonwize CreditAttribution: dragonwize commented@grendzy
Thank you for clarifying the exact steps.
No the roles get into the system through actual user hooks not form_alters. However, that matters little. Hooks are not called on disabled modules hence BF is not able to keep up with your changes. This is a wild situation where you leave the module off for a long time that you are changing the site radically. There are many modules that would not work or at the very least be buggy or filled with old dirty data when faced with the same situation. On top of that, as you said, simple reinstall the module and every thing is fine.
The proper way to fix it would be to put code in hook_enable that verifies and updates BF with any changes to site. That too would probably be some hairy areas to ensure that security holes are not opened up in the system. On top of that, only adding 1 role to the site before re-enabling the module is a simple situation to that of having removed all the roles in your site, added new roles, removed all your formats and added new ones, removed your content types and added new ones, etc. which would the extreme case but if we are to support this feature you would have to support the whole thing.
With all that being said, is it worth it to even attempt that for such little gain? I don't know. I will think about this more and make a decision before 2.0 is released.
@stripped your speech
BF sets permissions to act exactly as core does when it is first installed. If you want to change the permissions for BF, do so after not before you install the module, which seems like it shouldn't have to be said. If you are talking about removing roles from being used or monitored by BF while BF is on, that is not supported and you are on your own on that one.
Comment #9
kevinquillen CreditAttribution: kevinquillen commentedI am using the install_profile_api, and it installs the modules with install_include(array of modules). After that, I tried doing a db_query UPDATE with no success to change the permissions before Drupal is done installing.
Comment #10
grendzy CreditAttribution: grendzy commentedThanks for your feedback. I agree that making changes with the module disabled is kind of extreme. That's not really the issue for me; it's just the easiest way to demonstrate it. The real problem is Drupal core lacks an API for role creation (e.g. there's no hook_role_save) so better_formats does rely on hook_form_alter to be aware of new roles:
The issue that I encountered was with install profiles. A simple workaround for this might be to explicitly call better_formats_new_role() every time a new role is added. However there are lots of other ways an admin might create a role without submitting the 'user_admin_new_role' form.
This patch isn't complete, but shows one possible approach (after applying the patch you'll see the missing roles on admin/settings/filters/defaults).
Comment #11
dragonwize CreditAttribution: dragonwize commentedThe patch will let you see the roles but they still are not under BF's control. The site will still not give a default to users of that role because while you can see them on the page BF has no record of them. The only way this starts to work is if you then go to the page and submit the form which was the problem to begin with.
As you said, since Drupal does not have specific API hooks for roles, this is more of a limitation with Drupal an not BF. However, I would support another method if possible. Right now I am working on a 2.x version that will require (hopefully) less use of the database but to fit all the features in we still need some kind of solution.
Comment #12
meecect CreditAttribution: meecect commentedI can confirm this is a bug. I have a simple install profile that adds 2 new roles during the install with install_add_role(), and unless I uninstall better_formats and reinstall, there is no way (that I can find) to get bf to recognize those roles.
Comment #13
DamienMcKennaThis issue also happens when you insert roles directly into the database (there are no real APIs for managing roles).
Comment #14
DamienMcKennaHere's some sample code I wrote to fix the problem on my site:
Comment #15
DamienMcKennaMore code for an update script to set some intelligent defaults. Must be ran after the above.
Comment #16
dragonwize CreditAttribution: dragonwize commentedAs mentioned before since there is no hooks for roles, a work around solution will have to be made. There are several routes to take to do it and I am debating them as they hinge on many other decisions and the 3.x branch is going to be a rewrite the final solution will probably live there.
Comment #17
pcambrasuscribe
Comment #18
alberto56 CreditAttribution: alberto56 commentedsubscribing, thanks.
Comment #19
dragonwize CreditAttribution: dragonwize commentedPlease review.
Since their is no perfect solution without a complete rewrite of BF and even then I am not sure all the features would make it and it will have to wait for 2.x or 3.x, I have written a possible workaround for 1.x branch.
I split out the code that creates the BF default entries from the form alter function. This allows developers of modules that are creating roles by manually inserting them into the database to be able to call a function to keep BF in sync.
If you know the rid of the role you want to sync with BF, simply call:
If you do not know the rid, for instance when you manually insert the role into the DB, or when some other code that you do not have access to is creating the role(s):
If you do not have access to the code, simply visit the format settings defaults page (/admin/settings/filters/defaults) and better_formats_check_roles() will be ran by just viewing that page.
Hopefully this will help for the short term. Please review the attached patch. When/if I get a few positive reviews I will commit this and publish a new release with it. Also if you have any other ideas on how to make this better in the short term let me know.
Comment #20
dragonwize CreditAttribution: dragonwize commentedAdded better_formats_check_roles() to hook_enable to help with roles being "created" when the module is disabled.
Comment #21
hswong3i CreditAttribution: hswong3i commentedsubscribing
Comment #22
DamienMcKennaMaybe it would help to add a hook_cron() function to monitor & fix this in the background?
Comment #23
dragonwize CreditAttribution: dragonwize commentedI thought of that but I don't think it is a good solution.
1. BF would still be broken anyway until cron ran, whenever it ran.
2. We would be adding yet another item that is mostly useless for most sites to the cron run.
I feel there have to be better solutions. The obvious issue is in the architecture of the module which is being rewritten but for now I was hoping the items in the patch#20 will help patch up the situation for the time being.
Comment #24
Danny EnglanderSubscribing
Comment #25
Dave KopecekThis is also an issue with the adminrole module. If admin role is installed after BF, the "administrator" role create by admin role is not visible to BF. See:
http://drupal.org/node/812278 Better Formats doesn't see the admin role created.
Can confirm that disabling and uninstalling better formats, then re-enabling fixes the issue with adminrole.
Comment #26
Rob_Feature CreditAttribution: Rob_Feature commented#20 worked for me when creating roles using features. (had to uninstall the unpatched module and reinstall with the patch).
Comment #27
shrop CreditAttribution: shrop commentedFor my installation profile, I still had to use db_query() to insert the roles I added during installation.
Comment #29
dragonwize CreditAttribution: dragonwize commented6.x is now unsupported.