line 265 of share.module loads up the $node object with:

$content['share_'. $share->share_id .'_'. $node->nid]

Two problems here:

- a bug: $share->share_id is empty.
- a design flaw: adding the node ID to the node property means that a node template will need to muck about adding the ID when it prints the share. This is messy, and I don't see what purpose having the ID in the property name serves.

Comments

joachim’s picture

joachim commented

The bug is down to the SQL query in the $share->load() function.

This line:

    $data = db_fetch_object(db_query("SELECT * FROM {share} AS s LEFT JOIN {share_share} AS s_share ON s.share_id = s_share.share_id WHERE s.share_id = %d", $share_id));

My share_share table has only this row:
0 Share 1

In other words, nothing that corresponds to the share id I am loading (which in my case is 5). So the left join results in a NULL share_id from the share_share table, and this clobbers the actual share_id from the share table.

I don't know what the share_share table is meant to represent, so I can't offer a proper fix for this.

An ugly workaround for anyone trying to get this to work is:

    // just put the id back in
    $data->share_id = $share_id;
greenskin’s picture

greenskin commented
Version: 5.x-1.6 » 5.x-2.x-dev
Status: Active » Fixed

The issue with new share popups not storing their share_id has been fixed.

In the content of the $node object all share popups have been moved inside of ['share'] and are now keyed as ['share_'. $share->share_id] so resembles the following:

<?php
$node->content['share']['share_'. $share->share_id];
?>

Status: Fixed » Closed (fixed)

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