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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

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.

fabsor’s picture

Status: Needs work » Needs review
FileSize
5.74 KB

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.

plach’s picture

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

spotzero’s picture

Status: Needs work » Needs review
FileSize
5.33 KB

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.

plach’s picture

@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?

spotzero’s picture

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.

plach’s picture

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

spotzero’s picture

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

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

plach’s picture

Sounds reasonable :)

Committed and pushed, thanks.

plach’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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

  • Commit a93c4a1 on 7.x-1.x, revisions authored by fabsor, committed by plach:
    Issue #1516202 by fabsor, spotzero: Added a CTools access plugin for...

  • Commit a93c4a1 on 7.x-1.x, revisions, workbench authored by fabsor, committed by plach:
    Issue #1516202 by fabsor, spotzero: Added a CTools access plugin for...