well, this one was not in the wishlist (sorry rfay, I'm focused to fix this funcionality but in D6) but as long as I'm working with the user_delete module for D6, writting this one helps me to rewrite the other module.

Comments

Status: Needs review » Needs work

The last submitted patch, user_cancel_example.patch, failed testing.

ilo’s picture

Title: User cacel API example » User cancel API example
Status: Needs work » Needs review

testing..

ilo’s picture

user_cancel_example.patch queued for re-testing.

rfay’s picture

I saw that you were working on user_delete, and old friend (and enemy) of mine. I have to hook_form_alter() that puppy to make it simple enough for my users to delete themselves :-)

ilo’s picture

user_cancel_example.patch queued for re-testing.

ilo’s picture

retesting, just to make sure tests are working because of this: #939740: field_example_field_schema() should be in field_example.install

Status: Needs review » Needs work

The last submitted patch, user_cancel_example.patch, failed testing.

rfay’s picture

Status: Needs work » Needs review

Passes now.

rfay’s picture

Sorry to delay this suggestion until now, but it seems to me that user_cancel is too narrow.

Could we expand this into a user_example, or user_api_example? Demonstrate the various user apis?

ilo’s picture

Status: Needs review » Needs work

Totally agree, but in this case the module will grow, because user api is big enough to handle many different user processes. I'm not sure if user api and user cancel are the same topic, but I'll make a quick search and update with comments.

rfay’s picture

Title: User cancel API example » User API example including user cancel
ilo’s picture

Assigned: Unassigned » ilo
Category: task » feature

Seriously we do not have a user example yet? apologies, my fault. I'll work on this!!

ilo’s picture

After some thiking this is what I've have in mind:

1.- User basic API: _load, _insert, _update, _delete are basic hooks (both D6 and D7), close to node, comment, and other API hooks in Drupal. They all fit in one module as node API or any other object CRUD module.
2.- User cancellation: is a more complex API that also defines methods to cancel the account, but this API does not deal with users, only with the process of cancelling the account. Do this deserve its own sub module within the user scope, or do we put in the same CRUD module?
3.- User authentication: Allthough this does not deal with CRUD operations on users, it might create users when authentication is successful. Same question here, do I put it in the same CRUD module?

Come on, need suggestions!

rfay’s picture

If you feel like things will do better in separate modules then you can

1. Put them in submodules
or
2. Put them just in separate .inc files that make it clear where the different functionality is.

Either way makes sense for me. As always, the key is "what will people be able to understand".

jphil’s picture

Hi ilo,

Have you done any work on point 3. above?? Very curious if you have! D6 or D7.

If you looking for some help or implementation ideas give me a shout too...

Thanks,
Justin

deviantintegral’s picture

Version: » 6.x-1.x-dev
Assigned: ilo » deviantintegral

I'm working on a D6 basic user API example module that will demonstrate the basics of hook_user(). For now, it's just user_example.module, but we can easily refactor it as more examples are added later.

For some reason there isn't a version on this issue so I'm setting it to 6.x for now.

deviantintegral’s picture

Assigned: deviantintegral » Unassigned
Status: Needs work » Needs review
StatusFileSize
new6.86 KB

Here's an example of a basic form element for the user edit page, including saving it to a custom table and validating the value submitted.

rfay’s picture

rfay’s picture

Status: Needs review » Needs work

I'm good with #18 - It just needs a menu entry with a page to explain how it works. And it needs to be added to the main index. I'd like to see tests, but could live without in D6.

deviantintegral’s picture

Status: Needs work » Needs review
StatusFileSize
new8.59 KB

Here's a patch with a page callback added. I'm not sure what index you're referring to - just the one on the d.o module page?

I think adding tests might complicate the example further. If we really want them, I'd need to refactor the example a bit to be API centric (instead of just helper functions for hook_user()).

mile23’s picture

We'd want tests for QA purposes, not so much educational ones. Good tests can illustrate techniques as well, though. But like rfay says: It's for D6, which will soon see end-of-life.

The main index page went away, and we rely on api.drupal.org to show nice lists: http://api.drupal.org/api/examples/6

mile23’s picture

mile23’s picture

So a few problems with the patch in #20, but since 6 months has passed I just went ahead and fixed them.

1) Code like this, in user_example_user():

+function user_example_user($op, &$edit, &$account, $category = NULL) {
[..]
+        return _user_example_add_color_element(&$edit, &$account);

This is a reference to a reference, which PHP 5.2.17 finds acceptable but PHP 5.4.4 does not. Take out the ampersands and both are happy. I suppose the test bot uses an old version of PHP.

2) Some Doxy problems, such as not defining a @group.

3) Added some context as to how you'd do this in D7. (Just use a field.)

Ideally, the docblocks would have a better explanation of hook_user()'s workings, in addition to explaining $edit. We also might incorporate the user cancel stuff. But I'm eager to get D6 issues put to bed, so we're committed:

http://drupalcode.org/project/examples.git/commitdiff/9ac8c63f02c70c2f70...

Thanks, deviantintegral. :-)

mile23’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.