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.
Each user should be able to specify the default sharing settings for new content. That way, they can decide once to share or not share content in a given social network.
I'll be posting an initial patch supporting this for 7.x. I'm also going to be adding an AJAX link to the node form to quickly set defaults from there as well. Once the patch has stabilized, I'll backport it to the 6.x branch.
Comments
Comment #1
deviantintegral CreditAttribution: deviantintegral commentedHere's a patch that adds settings to the user edit form and pulls them into node forms.
Comment #2
deviantintegral CreditAttribution: deviantintegral commentedHere's a patch adding the 'make default' button.
Comment #3
deviantintegral CreditAttribution: deviantintegral commentedHere's a patch that fixes a bad return value. Also, a backport to 6.x-1.x.
Comment #5
deviantintegral CreditAttribution: deviantintegral commentedOh testbot.
Comment #6
deviantintegral CreditAttribution: deviantintegral commentedThere was an issue in the 6.x patch that caused duplicate wrapper IDs when setting the default settings from a node. It's not an issue in the 7.x patch.
Comment #8
deviantintegral CreditAttribution: deviantintegral commentedComment #9
BerdirThe attached patch fixes a notice I got. If you see a better way, please improve it.
I like this patch and I think it it improves the module a lot and gets a step further. It would be lovely to have some tests for this module, but I'm going to commit this soon..
Sorry for letting this and your other patches wait for so long...
Comment #10
deviantintegral CreditAttribution: deviantintegral commentedYour change seems reasonable to me. I'm not sure if a cleaner way to do it given how tied the form is to hook_node operations.
Comment #11
deviantintegral CreditAttribution: deviantintegral commentedThe original parameter of $type was causing a scoping issue so that node settings were always becoming the defaults. This patch changes the parameter to be $object_type instead.
Comment #12
deviantintegral CreditAttribution: deviantintegral commentedAn update to the 6.x-1.x patch that fixes a warning from a bad runtime call-by-reference copy/paste.
Comment #14
BerdirThanks, let's get this moving, commited. Thanks for your patience!
Moving to 6.x, leaving it for mrf to decide if he wants to add new features at this point.
Comment #15
Berdir#12: 1273550.12-default_node_access_settings-6.x.patch queued for re-testing.
Comment #17
BerdirLooks like the tests try to run the Views tests:
[17:10:05] Command [/usr/bin/php ./scripts/run-tests.sh --concurrency 8 --php /usr/bin/php --url 'http://drupaltestbot699-mysql/checkout' --file sites/default/modules/user_relationships/user_relationships_api/tests/user_relationships_api.api.test,sites/default/modules/user_relationships/user_relationships_api/tests/user_relationships_api.socnet.test 2>&1] failed
Duration 0 seconds
Directory [/var/lib/drupaltestbot/sites/default/files/checkout]
Status [255]
Output: [PHP Fatal error: Class 'ViewsSqlTest' not found in /var/lib/drupaltestbot/sites/default/files/checkout/sites/default/modules/views/tests/views_exposed_form.test on line 7].
[17:10:05] Encountered error on [review], details:
array (
'@reason' => 'failed during invocation of run-tests.sh',
)
[17:10:05] Review complete. test_id=183604 result code=8 details=Array
(
[@reason] => failed during invocation of run-tests.sh
)
I think that's a known issue, so for now, ignore test fails...
Comment #18
deviantintegral CreditAttribution: deviantintegral commentedLooks like I placed your earlier PHP warning fix in the wrong place when I backported it to D6. This patch fixes that.
Comment #19
mrf CreditAttribution: mrf commentedI am up for including this feature in 6.x since it is pretty much a straight backport from 7. My main concern with new features for 6.x was focusing my energy away from the long list of known bugs, but this looks like it is already ready to go.
Give me some time to run through this myself and I'll add it in to 6.x.
Comment #20
deviantintegral CreditAttribution: deviantintegral commentedThanks mrf for looking at this.
There was an issue with the previous patches if nodes were created without going through the form system. As the nodeapi prepare hook wasn't implemented, default settings weren't applied to raw nodes saved with node_save(). I ran into this specifically with the plupload module. The attached patch adds that, as well as fixes the indentation of the switch block.
As the 7.x code has been committed, I'll open up a separate issue for that.
Comment #21
mrf CreditAttribution: mrf commentedClosed #690558: post to social network to have default value as a duplicate of this issue.
Comment #22
mrf CreditAttribution: mrf commentedI did some manual testing of the patch, all the ur node access settings still save and function properly, but when I click the save defaults button those defaults aren't displayed when I create a new node of that same type.
When I click the 'save defaults' button the throbber seems to go away too quickly, so maybe the ajax just isn't saving properly?
Comment #23
deviantintegral CreditAttribution: deviantintegral commentedHere's a patch that fixes setting the wrong defaults for new nodes due to setting an invalid array for $node->user_relationship_node_access.