Being able to control access on panel page, variant and panel pane level is very useful, you could for instance display a custom-tailored message or not show anything at all if a translation isn't available. This patch is a CTools access plugin that let's you check if a translation is available for any translatable entity.

Files: 
CommentFileSizeAuthor
#4 translation-access-plugin-1516202-4.patch5.33 KBspotzero
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es).
[ View ]
#2 translation-access-plugin-1516202-2.patch5.74 KBfabsor
PASSED: [[SimpleTest]]: [MySQL] 60 pass(es).
[ View ]
translation-exists-access-plugin.patch6.08 KBfabsor
PASSED: [[SimpleTest]]: [MySQL] 60 pass(es).
[ View ]

Comments

Status:Needs review» Needs work

I like this patch, but would you explain the need to support both content and interface languages? Which use cases do you have in mind?

Quick code review:

+++ b/plugins/access/translation_exists.inc
@@ -0,0 +1,149 @@
+ * Plugins are described by creating a $plugin array which will be used
+ * by the system that includes this file.

The comment does not wrap at column 80.

Status:Needs work» Needs review
StatusFileSize
new5.74 KB
PASSED: [[SimpleTest]]: [MySQL] 60 pass(es).
[ View ]

I actually didn't put that much thought into it, I just added the possible variable language settings I could think of. The attached patch removes the interface language option and only exposes the content language as an option, since I can't come up with a good use case for interface language.

Component:Code» Base system
Status:Needs review» Needs work

I'm terribly sorry, I completely lost track of this one. Overall this looks good to me, although I didn't test it. I'll be glad to commit it if someone (icluding you :) confirms it still works. You'll earn the CTools integration component maintainership if this get in, though ;)

+++ b/plugins/access/translation_exists.inc
@@ -0,0 +1,142 @@
+     $plugins[$parent . ':' . $entity_type] = $plugin;

Wrong indentation.

+++ b/plugins/access/translation_exists.inc
@@ -0,0 +1,142 @@
+    'current' => t('Current content language'),
+    'default' => t('Default site language'),
...
+    'current' => t('Current site content language'),
+    'default' => t('Default site language'),
+    'und' => t('Language neutral'),

We have a couple of constants defined for these now. See ENTITY_TRANSLATION_LANGUAGE_DEFAULT, ENTITY_TRANSLATION_LANGUAGE_CURRENT, ENTITY_TRANSLATION_LANGUAGE_AUTHOR. We could add the latter for consistency with settings page.

+++ b/plugins/access/translation_exists.inc
@@ -0,0 +1,142 @@
+    'und' => t('Language neutral'),

'und' should be LANGUAGE_NONE

Status:Needs work» Needs review
StatusFileSize
new5.33 KB
PASSED: [[SimpleTest]]: [MySQL] 721 pass(es).
[ View ]

plach, looks like you scared him away when you dropped the "M" word ;)

I've applied the changes mentioned in comment #3, re-rolled that patch against the latest dev, and re-tested the patch.

Everything looks like its working correctly.

@spotzero:

plach, looks like you scared him away when you dropped the "M" word ;)

:)

Everything looks like its working correctly.

Looks good to me now, would you be confident about RTBCing this?

Status:Needs review» Reviewed & tested by the community

Definitely.

It worked correctly in my tests. Even if there were edge cases where this code didn't work as intend, as it add functionality without touching any existing processes or code, it can safely be merged in without needing to worry about breaking anything else.

And who is going to deal with any follow-up? ;)

If anyone reports any bugs with it, send the issues my way.

Anyone needing support should make their way to Montreal this weekend ;)

Sounds reasonable :)

Committed and pushed, thanks.

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

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