Node type not saving
kclawes - December 18, 2008 - 19:10
| Project: | Share |
| Version: | 5.x-2.0-alpha10 |
| Component: | Documentation |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
I'm having difficulty getting share to show up at all.
- My popup is enabled.
- For ease of test, I only have Link Codes enabled.
- I have selected my node types.
- For Where I have selected "Link" which I assume means it should display in the links area of a node.
- View I have set to "Teasers and Full-Page"
When I check my node, there is no Share Link. Additionally, I am noticing that there is no call for the CSS in any pages Except the Share Admin pages. This leads me to believe the module isn't being called at all on any of my nodes.
In order to get this working at all, I have disabled Service Links. Though I did patch that and have the same results. Except of course, the service links are displayed on the node, not the pop-up.
Any advice would be much appreciated.
#1
Are there any errors given in your reports?
#2
There are not.
#3
If you edit your popup, are the settings for it the same as when you saved it? In other words is the form saving your popup correctly.
#4
OK, interesting findings...
I tried editing all of the fields in for my popup. They appeared to save correctly.
However, I created a new popup. And the "Link Name" field does not appear to save. The other fields do seem to save correctly though.
After creating and testing the second popup, I retested the original one, and that still appears to be saving properly.
#5
I had this error too, and it's related to this line in share.module:
$where_query[] = "(`node_types` = '%%%s%%' OR `node_types` = '%s')";
I was curious about this strange query, and when I looked at the database, I saw that the array of node types for that share widget is stored as a serialized array. The %%%s%% means to produce %blog% or %story% in the SQL. However, in MySQL, equality is exact. You can't use the truncation operator. So I replaced the line with this:
$where_query[] = "(`node_types` LIKE '%%%s%%' OR `node_types` = '%s')";
Using SQL to scan the values of a serialized array strikes me as the wrong way to do this. Wouldn't it be better to just normalize this table and put the node types into a joined table? This method might work with node types, but it will not with term IDs (because tid 123 will show up in results when we query for TIDs LIKE %12% and LIKE %23%).
Meanwhile, the values stored in the share_sharethis, share_share, share_linkcodes, etc. are well-suited to be stored as a serialized array, because these fields don't appear to be used in WHERE conditions in your SQL. You could get rid of the tables for the various share modules and add new tables for the conditions where share popups should appear.
I'm happy to contribute a patch to accomplish this. I really benefit from this module! But it would be a few hours work, so I wouldn't want to do it unless the maintainer thinks this is a good direction to take.
#6
@bangpound
Thanks for your input and I agree with what you have stated. I had not thought about moving the node types and category terms to their own tables. I like this idea and would very much accommodate the contribution of a patch. I'm wanting to port the Share code to Drupal 6 but I don't want to start that until Drupal 5's version is stable and feature complete. Thanks for your insight into this problem.
#7
OK, I was able to get it to work using the fix in #5
However, I did notice that the tab data didn't seem to be saving properly in the database. I edited the DB manually to get it to work. Mostly it seems the tabs didn't have an ID, so they obviously didn't know what popup to appear on.
I wish I had more know-how to help out, because it seems the module isn't properly writing to my DB. If you have any other questions, I'm happy to help.
#8
thank you for the fix.
attached is a patch for alpha 10
#9
Fixed in latest dev release.
#10
Regarding moving the node types and category terms to their own tables -- this is how both the flag and nodequeue modules handle storing things that apply to several node types.
#11
Yes, I plan on moving the node types and category terms to their own tables. Just got to find the time to do it.
#12
Alternatively, just spotted this in tagadelic.module:
$result = db_query_range('SELECT COUNT(*) AS count, d.tid, d.name, d.vid FROM {term_data} d INNER JOIN {term_node} n ON d.tid = n.tid WHERE d.vid IN ('. substr(str_repeat('%d,', count($vids)), 0, -1) .') GROUP BY d.tid, d.name, d.vid ORDER BY count DESC', $vids, 0, $size);I don't know which would be quicker to run. This method is certainly easier to implement that changing your data structure. I imagine it's a gain on LIKE but no idea how much.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.