and other non node entities?

CommentFileSizeAuthor
#4 better_user_description.patch799 bytesLetharion
#1 flattr-1990630-1.patch1.1 KBdiscipolo
flattr-terms.patch561 bytesdiscipolo

Comments

discipolo’s picture

discipolo commented
StatusFileSize
new flattr-1990630-1.patch1.1 KB

what unwanted issues arise from these changes? what is the language thing about?

Letharion’s picture

Letharion commented

It's my wish that the field works on any entity, as any field should, though honestly I've only spent a rather limited time on testing it out.

Could you provide me with some context, what are you trying to do, and what doesn't work, and I'll see if I can help.

The hard coded 'user' entity isn't completely optimal, but I believe it's appropriate. It's meant to allow a user to keep their flattr username in a field on the user, and have this field re-usable across all types of flattr-able things on a site.

The language lets Flattr know in which language the flattred object is, you can read about how it's used in their documentation: http://developers.flattr.net/button/

I hope that helps. :)

discipolo’s picture

discipolo commented

ah, i didnt figure out to add the flattr_username_field to the user page. i added it to the entity instead. in my case i added the flattr field to taxonomy fields.
i had to change the code as seen in the patch above to get the button to show correctly (not orange with !) since i hadnt made the connection that you are using the $user entitiy because thats where the flattr_username field should go.
i will test with the username field on user entities, that explains what i saw in the code.

Letharion’s picture

Letharion commented
StatusFileSize
new better_user_description.patch799 bytes

Glad that helped.

Like I said, probably 'user' shouldn't be hard coded, but it should probably still be separate from the displayed entity, as the use-case where one owner will have multiple objects seems highly likely.

A potential option would be to use tokens completely for configuration, allowing one to pull the Flattr name from a wide variety of places.

Attached is a patch that aims to improve the configuration description. Please review it and let me know if you think the text is more helpful this way.

discipolo’s picture

discipolo commented

so here is whats going on when adding the flattr field to taxonomy terms and putting the flattr_username field on users.

since the user cannot be loaded from terms. (and term fields seem to handle language differently?) i get the following messages

  • Notice: Undefined property: stdClass::$uid in flattr_field_formatter_view() (line 205 of flattr/flattr.module).
  • Warning: array_flip(): Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load() (line 178 of includes/entity.inc).
  • Notice: Undefined property: stdClass::$language in flattr_field_formatter_view() (line 235 of flattr/flattr.module).
  • Notice: Undefined index: in _flattr_language() (line 370 of flattr/flattr.module).

so in the case of non-node entities the username field (as well as tags and categories) could just be on the same entity (or even cease to be seperate fields and be part of the field config) allowing to set them on entity creation. those could still default to the settings a user makes on their profile if available.

currently if no field is selected for flattr_username in the widgets display settings it tries to default to the drupal username (not a field on the user entity) which also doesnt work for non-node entities.

p.s. ++ on the description, should also go into readme maybe?

Letharion’s picture

Letharion commented

Clearly a bug. I believe the solution is to finally implement this old issue: http://drupal.org/node/1326636, as mentioned above, using tokens would give you the flexibility to handle this in most ways you'd want.

I haven't considered it enough yet though, there could be drawbacks I suppose.

If you have suggestions for how to fix the term specific problem that aren't too invasive, patches are welcome. Otherwise I believe it's time to start a 2.x branch with a new more flexible approach.

discipolo’s picture

discipolo commented

the only way i see would be to require the flattr_username field to be on the respective non-node entity itsself. i can write a patch that checks whether the field is being displayed on a non-node entity and have it look for the field on the entity itsself instead of search for the entity author. that would not influence the existing behaviour on nodes and should take only a few lines of code. is that an acceptible solution to the bug?

discipolo’s picture

discipolo commented

or would it be better to store the authors uid in the database? then the hardcoded 'user' could be replaced...

Letharion’s picture

Letharion commented

I've started a 7.x-2.x branch now, since some changes related to this issue will probably result in some API-breaks.

I'll try to address this problem in there. No progress on this in particular, but I just wanted to let you know something is happening.