I am using Node Blocks on a site with 4 languages (English default). I am able to install Node Blocks, set a content type to enable as a block, and create content, and then I see that content on the block page, as expected. There are two problems, one of which I believe is present in the Drupal 6 version, also:
1) When the block is placed, it will not show up on the actual English front-end page unless it is translated into at least one of the other languages (this happens on one of my Drupal 6 sites, but it normally isn't a problem). Enabling translation fallback seems to have no effect.
2) When I add the other language, it shows up fine on the front end, but disappears from the block configuration page entirely. I have tried disabling, un-installing, reinstalling, toggling the "enable block" on the content, etc to get it to show up again, but the only thing that works is deleting the content and re-creating it (in English). If I add a Portuguese translation again, it disappears from the block listing page again. I took a look at the database table (block), and it shows 4 rows (I have 3 themes enabled, a custom theme, bartik, and seven). The English nodeblock is in all 3 themes, and the portuguese one shows up only in the admin theme (seven).
Let me know if you need any more information from me! I really appreciate your work on this module.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | nodebock.module.patch | 692 bytes | wouters_f |
Comments
Comment #1
momentuminc commentedI should mention that it is still possible to configure the individual block settings, by using the widget on the front-end. However, it is not possible to change the order of the block within a region, using the block configuration page itself.
Comment #2
wouters_f commentedOn problem 1
I also had this problem.
This can be fixed with the following code:
In function nodeblock_block add the following elseif ($node->language == $language->language)
then the code should not return and just continue.
Comment #3
wouters_f commentedThe patch attached is only for the drupal 6. version.
Sorry, not using the drupal 7 version yet.
I also added a hook which I needed and removed a notice.
Comment #4
momentuminc commentedThanks! I'll take a look and see if I can modify that to work with the Drupal 7 version when I have some spare time!
Comment #5
michaellander commented@momentuminc, can you test our the new version on dev to see if it solves your problems?
Comment #6
momentuminc commentedI have installed and tested this module some. From what I can tell, this solves the first problem perfectly. Now nodeblocks that exist in only one language will still display on the front end of the website.
Problem 2 is still happening. Any time I create a translation for a nodeblock, it disappears from the block configuration page.
Comment #7
michaellander commented@momentuminc, alright thank you. I'll look into it a bit further.
Comment #8
momentuminc commentedI think I can see what the problem is by looking at the database and nodeblock.module, but I'm still coming up to speed on the API calls.
Basically, on line 159, the second condition works (condition('tnid', 0)), which is why the untranslated blocks show up on the block page. I think the first condition (condition('nid', 'tnid')) is *intended* to mean where the nid field's value is the same as the tnid field's value, but I think it's actually running "where nid field's value is the string 'tnid'). Does that make sense? I'll try to see what else I can figure out, or if I can confirm this suspicion.
Thanks again for your help!
Comment #9
momentuminc commentedI didn't see an obvious way to continue using the query builder and check equality between two field values, so I just rewrote that query. It seems to work fine now.
Basically, replacing the query from lines 155-159 with:
$result = db_query('SELECT n.nid, n.title FROM {node} n WHERE n.type = :type AND n.status = 1 AND (n.nid = n.tnid OR n.tnid = 0)', array(':type' => $type->type));
Then removing $result = $request->execute(); solves the problem for me.
Comment #10
michaellander commentedalright, thanks momentuminc. There was actually a SQL statement in there before which I switched to the PDO, but apparently that is acting up. I'll switch it back to this for now until I'm able to look further into the PDO.
Comment #11
michaellander commentedPlease test the latest version committed today.