I would like show_menu template tag to only output menu items that belong to pages that have a translation in the current language.
However I have been unable to set djangocms CMS_LANGUAGES in settings.py of my Aldryn project accordingly, using the hide_untranslated property. Aldryn seems to ignore that setting.
Also, I read from the djangocms documentation that hide_untranslated is True by default: https://github.com/divio/django-cms/blob/master/docs/reference/configuration.rst#hide_untranslated
Is it possible that Aldryn overwrites CMS_LANGUAGES? I am also asking because one can set the CMS languages in the Aldryn control panel which is possibly incompatible with settting CMS_LANGUAGES in settings.py.
The following setting works in Aldryn to hide untranslated pages in all configured languages.
CMS_LANGUAGES['default'] = {
'fallbacks': ['en'],
'redirect_on_fallback': False,
'public': True,
'hide_untranslated': True,
}
Related
I was asked to disable the "Code Editor" and the "Edit as HTML" function in the WordPress Gutenberg editor.
Unfortunately I am not able to find any solution on Google (thanks, Classic Editor posts...) or in the wp.org Developer Reference.
My first attempt was to filter the Code Editor menu entry with wp_default_editor, but the possible arguments does not seem to fit for WP version 5.*
Any ideas for one of both cases?
To disable the "Edit as HTML" option for all blocks on a site, you'll need to set up Webpack and all that fun sort of thing. You can use Create Guten Block to get the project going if you don't want to set it all up yourself.
Then, in your block.js file (or whatever custom JS file you're setting up for the editor), you'll just need a few lines of code. Use the registerBlockType filter to change all the blocks right as they're registered, and that will allow you to disable "Edit as HTML" as well as other features (such as custom class name) as desired.
// Use WP Hooks
const { addFilter } = wp.hooks;
// Create the filter
addFilter(
"blocks.registerBlockType", // Using the registerBlockType hook
"cgb/change-core-blocks", // Custom namespace, slash, name for your filter
changeCoreBlocks // The name of your custom function
);
function changeCoreBlocks( settings, name ) {
// This will fire for all blocks - from Core, plugins, and themes
settings.supports = Object.assign({}, settings.supports, {
// Setting "html" to false disables the "Edit as HTML" functionality
html: false
});
}
There is probably a way to do this in older JavaScript that wouldn't require you to set up Webpack or use Create Guten Block, which seem rather complicated to run this simple filter.
How can I set the priority of a plugin by default, programatically, so that after installation and activation, it is shown at the bottom of the plugin list automatically.
I know that we can set the priority in the administration section but how can we set that in code, so that when this plugin is installed on another site, by default it is at the bottom of plugin list.
I have tried:
elgg_register_event_handler('init', 'system', 'myplugin_init', 999999);
but it doesn't seem to work, and I can't find anymore documentation on it.
I'm using elgg 1.8.16
Add a priority dependency to your plugin's manifest to keep it in proper order to overridden one.
There's no such feature like "always on bottom" since it would be problematic to handle multiple plugins that want to be on bottom of plugins list.
I have used this to set the priority last, but only setting the priority does not work until you clear the cache.
$plugin = elgg_get_plugin_from_id('myplugin');
$plugin->setPriority('last');
I have used the following function for setting the priority as it runs once per installation.
run_function_once($functionname, $timelastupdatedcheck = 0)
and have flushed the cache after that using elgg_reset_system_cache()
I need to open view with particular path as front page. Everything would be nice except the view must be open in another language than default (english).
Tryinig to prefix language in Site information settings or adding path alias with that prefix fails as Drupal says "tha path xxx is invalid" 'cause Drupal prefixes language automatically.
I've come up to thought to hack the core function or override front page method with custom code.
Is there any solution by means of configuration?
Precision: I need INTERFACE language (menus etc.) to be changed, not only the view content.
Can't you add a filter to the view specifing the language you want it to use? (View -> Filters -> Node Language -> Is one of ...)
If you just want to change the language, you can do that by changing the global $language in a preprocess function for that view.
You can use language_list() to get an array of active languages and overwrite the global $language with one from the list. You need to do this in a preprocess function, look at the theme information in your view to get more info about it.
A site I'm creating for a customer in D6 has various images overlaying parts of the main content area. It looks very pretty and they have to be there for the general effect.
The problem is, if you use this theme in the administration pages, the images get in the way of everything.
My solution was to create a custom admin theme, based on the default one, which has these image areas disabled in the output template files - page.tpl.php
The problem is that when you try and edit the blocks page, it uses the default theme and half the blocks admin settings are unclickable behind the images. I KNOW this is by design in Drupal, but it's annoying the hell out of me and is edging towards "bug" rather than "feature" in my mind. It also appears that there is no way of getting around it.
You can edit /modules/blocks/block.admin.inc to force Drupal to show the blocks page in the chosen admin theme. BUT whichever changes you then make will not be transferred to the default theme, as Drupal treats each theme separately and each theme can have different block layouts. :x
function block_admin_display($theme = NULL) {
global $custom_theme;
// If non-default theme configuration has been selected, set the custom theme.
// $custom_theme = isset($theme) ? $theme : variable_get('theme_default', 'garland');
// Display admin theme
$custom_theme = variable_get('admin_theme', '0');
// Fetch and sort blocks
$blocks = _block_rehash();
usort($blocks, '_block_compare');
return drupal_get_form('block_admin_display_form', $blocks, $theme);
}
Can anyone help? the only thing I can think of is to push the $content area well below the areas where the image appear and use blocks only for content display.
Thanks!
in template.php you can put
function YOURTHEME_preprocess_page(&$vars) {
if (implode('/', arg()) == 'admin/build/block'){
$vars['body_classes'] = $vars['body_classes'].' administer_block';
}
}
and you'll have a nice body class which you can use to hide those images using CSS.
If anyone's still having a problem with this, a bit similar to barraponto's solution above, if you are using the admin menu module, it adds a class (.admin-menu) to the body, which you can use to hide any overlaying divs etc that are getting in the way.
you can apply admin theme wherever you want using hook_init() in your custom module:
function yourmodule_init()
{
if ( some condition here like arg(0) == 'foobar'
or node_load(arg(1))->type == 'something' )
{
$GLOBALS['custom_theme'] = variable_get('admin_theme', '0');
drupal_add_css(drupal_get_path('module', 'system') .'/admin.css', 'module');
drupal_add_js(drupal_get_path('theme', 'myadmintheme').'/jscripts/adminjs.js');
}
}
EDIT: then (probably) you have to use form_alter against the block editing form to restore the target theme. in this way you don't have to hack the core.
Thanks for bringing up this topic! I was having the same problem, and it's annoying. Here's how to remedy it without a single line of code:
1) Switch the main theme to your administration theme.
2) Configure Blocks. This always affects the currently selected main theme.
3) Switch the main theme back to what it's supposed to be. Your admin theme will still reflect your changes.
could just use the block-admin..... tpl file from block module and theme it in your custom theme. I have done this way as admin theme module never overrides block admin even when you use custom path bit.
If you don't need your new theme while performing administration tasks, you can use a different theme while doing so.
Goto "Site Configuration" -> "Administration Theme". Here you can pick the theme to be used while doing admin. So your new theme is only used while users are viewing your site. And you can do admin tasks without the interference of all your images.
I've defined a view with the CCK and View 2 modules. I would like to quickly define a template specific to this view. Is there any tutorial or information on this? What are the files I need to modify?
Here are my findings: (Edited)
In fact, there are two ways to theme a view: the "field" way and the "node" way. In "edit View", you can choose "Row style: Node", or "Row style: Fields".
with the "Node" way, you can create a node-contentname.tpl.php which will be called for each node in the view. You'll have access to your cck field values with $field_name[0]['value']. (edit2) You can use node-view-viewname.tpl.php which will be only called for each node displayed from this view.
with the "Field" way, you add a views-view-field--viewname--field-name-value.tpl.php for each field you want to theme individually.
Thanks to previous responses, I've used the following tools :
In the 'Basic Settings' block, the 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" to quickly find the field variable names.
View 2 documentation, especially the "Using Theme" page.
In fact there are two ways to theme a view : the "field" way and the "node" way. In "edit View", you can choose "Row style: Node", or "Row style: Fields".
with the "Node" way, you can create a node-contentname.tpl.php wich will be called for each node in the view. You'll have access to your cck field values with $field_name[0]['value']
with the "Field" way, you add a views-view-field--viewname--field-name-value.tpl.php for each field you want to theme individually.
Thanks to previous responses, I've used the following tools :
In the 'Basic Settings' block, the 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" to quickly find the field variable names.
View 2 documentation, especially the "Using Theme" page.
A quick way to find the template files you can create and modify for a view in Views 2.0 is to:
Edit the view
Select the style (e.g. page, block, default)
In the 'Basic Settings' block click on 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" feature is handy for seeing what template files Drupal is looking for when it goes to theme something. See the screenshot on that page for an example.
You should also check out Semantic Views. For simple Views theming, it is really handy.
One tip:
You'll likely have a number of views which require similar formatting. Creating templates for each of these views and copying them creates a nightmare of code branching - if you're asked to change the whole look and feel of the site (implying changing the display of each of these views formatted in this particular way), you have to go back and edit each of these separately.
Instead of using the views interface to select new templates for views, I sometimes simply insert some code branching into a single views file. E.g. for one site in views-view-fields.tpl.php I have:
if($view->name == 'articleList' || $view->name == 'frontList'
|| $view->name == 'archiveList') {
/* field formatting code */
} else {
/* the default code running here */
}
This then modifies the fields in the way I want only for this family of Views = articleList, frontList and archiveList - and for other views using this template runs the code one normally finds in this template. If the client asks, "Hey, could you make those pages showing the archives & that list on the front page to look more like ( ... )", it's simply a matter of my opening & editing this one file, instead of three different files. Maintenance becomes much more quick & friendly.
for me block-views-myViewName-myBlockId.tpl.php works
My shortcut option.
Go to theme.inc file in YOUR_MODULE_DIR/views/theme/ folder.
In the _views_theme_functions function print the $themes variable or put a breakpoint on the last line of the function to see the content of the variable.
Just convert views_view to views-view and __ to -- and add your template extension to get desired file name.
For example if an element of the $themes array is views_view__test_view__block (where test_view is the name of your view) then the name of the template file would be views-view--test_view--block.tpl.php.
In my opinion the simplest way to decide which template file to use for theming the views is :
1) Click on admin/build/views/edit/ViewName -> Basic Settings -> Theme
Clicking this would list all the possible template files. Highlighted (File names in Bold) files indicate which template file is being used to do theme what part of the view. After incorporating the required changes in the relevant view template file RESCAN .. now you should be able to see the changed template file highlighted .
If you want to do quick Drupal development with a lot of drag-and-drop, the Display Suite module def. is a something you should use: http://drupal.org/project/ds
According to me there are two ways to do it:
Programatic Way:
Go to edit view.
Select page/block style.
Go to 'Basic Settings' and click on 'Theme: Information' to see all the different templates you can modify.
Add the html you want to theme and print the variables of the view wherever needed
Configuration Update: The Display suite provides us an option to place your labels inline or above and add even to hide them. Custom classes to each of the view's elements can be added too.
Advanced options include:
Exportables
Add your own custom fields in the backend or in your code
Add custom layouts in your theme (D7 only)
Change labels, add styles or override field settings (semantic fields).
Full integration with Views and Panels
Extend the power of your layouts by installing Field Group
Optimal performance with Object cache (D6) or Entity cache (D7) integration