I've been playing around with a theme for a ghost blog (ghost.org). It uses handlebars for its templates and I've been looking at existing ones to see what is possible and what isn't.
I have come across {{!< default}}. default is the name of a template.
What does !< mean?
If you look in the index.hbs file of the default theme you'll find this comment:
{{! The comment above "< default" means - insert everything in this file into
the {body} of the default.hbs template, which contains our header/footer. }}
It simply tells the page which parent template it should be inserted into
According to official page section about comments, {{! }} is used to mark a template comment. So, basically < default - just a comment which is simply being ignored.
EDIT:
Also in mustache man page it's clearly stated:
Comments begin with a bang and are ignored.
So, I presume, it's safe to say, that if tag starts with !, it's not going to be rendered.
Related
I've recently taken over dev of a Wordpress site using Timber (which I wasn't familiar with). I'm attempting to use a new plugin and accompanying shortcode, which of course doesn't work.
I've been researching this for a couple hours and there doesn't seem to be a simple answer. In order to use a simple shortcode like this:
[sp_faq category="7"]
Do I really need to create a custom shortcode function in functions.php, add some sort of template file for it, etc? This seems counterintuitive to Twig's making things 'simple'.
The documentation for this is less than stellar unless I'm missing something obvious.
You could try this (example using a gravity form shortcode):
{% filter shortcodes %}
[gravityforms id="1"]
{% endfilter %}
If you want to render a shortcode from a custom field you can do it like this:
{{post.custom_shortcode_field|shortcodes}}
Taken from the docs:
https://timber.github.io/docs/guides/filters/#shortcodes
Or if it's comming from the main-editor try:
{{ post.content|wpautop }}
Seems like this is too late for OP, but for anyone else coming across this: The correct solution is combined in the Luckyfella's answer and the comments on it. I think OP would have got it working if he had tried Luckyfella's final suggestion.
You need to put {{post.post_content|wpautop|shortcodes}}* into your Twig file(s). This will render both auto paragraphs and shortcodes that are put into the main WYSIWYG editor, by default.
*post is simply the conventional default name in Timber for a TimberPost, you will also need to check in your PHP template files to see what the Timber context and Timber post variables are called. For OP it seems to have been page, not post.
Just thought I'd chime in here.
post.post_content contains the raw data that is contained in the database (before any filters have been applied to it) and post.content contains the data after the filters have been applied, so using the filter |shortcodes shouldn't be needed to be run on that.
I was using post.post_content for some reason and found this question because I was trying to figure out why my shortcodes weren't working and hence it led me to do some more research.
Now, reading the answers in this question, I wasn't really satisfied with as I had also been using |e('wp_kses_post') to sanatise the data that I output, but if I used something like this:
{{ post.content|wpautop|e('wp_kses_post') }}
...then obviously I would get the correct filtered data with the shortcodes processed, but it would also at the same time strip out any non-allowed data with the e('wp_kses_post') filter.
Sure, you could add allowable tags within this filter, but obviously that isn't very realistic as you don't know exactly what output the shortcodes will be outputting nor do you want to keep updating it.
So, we had a problem... we want to allow shortcodes to be parsed, but also sanatise the content at the same time - what to do!?
The solution is the below:
{{ post.post_content|wpautop|e('wp_kses_post')|apply_filters('the_content') }}
Here we use post.post_content so we have the content before it has been filtered, then after the wpautop filter it is followed by e('wp_kses_post'); this will sanatise the data, but the important part being it will leave shortcodes alone, so they can be still be filtered!
Lastly, we apply the filters for the content with the apply_filters filter, and this then takes care of all the filters applied to the_content including parsing the shortcodes.
Though if you are already using universal escaping you will have to consider how the above will apply to your situation.
Reads like you want to use a shortcode outside of post.content.
You can use {% function('do_shortcode', '[shortcode here]') %} to process a shortcode where ever you want to in a template.
I am trying to edit a wordpress-theme (translations that are hardcoded in the theme etc) and stumble upon a problem here:
How do I identify, where a content block comes from?
Like, if my theme is constructed by 3 files post.php header.php and footer.php (which would make things pretty simple, but in my case it's quite some more files) and the content isn't set there consistently and the naming is neither "semantic", how could I identify that compiled block abc comes from header.php?
Is that something that can be done via Firebug/DevTools?
Although this question is specifically aiming at Wordpress as a system, the same problem occurs with other file-heavy systems like Typo3 or Magento. Isn't there some other routine then opening, searching all existing files?
Thanks for your answers
If your theme is translation-ready, you could try using Poedit. If not, you can identify where a block comes from knowing that:
Header.php: you'll find there all the strings that come in every page of your blog. Normaly Header.php includes all the code from the beginning of the HTML document until body, but it can be different from one theme to another. There may be diferrents headers, like header-gallery.php (for galleries) or similars.
Index.php: That's the index of your blog, normally it includes the code from the BODY of the html document for the index page.
Single.php, Page.php, Content.php, Aside.php or similars: They include the code for the body of every post/page type. For instance, single.php includes the BODY code for the single post. Sometiems, instead of single.php there are another options like content.php, content-wide.php or similars ("content-TypeOfPage.php"
Footer.php: It closes the HTML document for every post/page. Normaly it includes from the last lines before closing the BODY until the closing of the HTML tag.
Functions.php:: Take care editing this one. This file and the other files required/included on it include the code for the settings of the theme and any other functions implemented. For instance, the custom admin pages on the Dashboard are coded there.
I was looking for a way to check the plugin's position within a placeholder in Django-CMS. I found this question Detect last plugin in a placeholder
Is "plugin" a django cms keyword? I can't find documentation about it.
My question is: How can I obtain information about the plugins rendered within a Placeholder?
Thanks
if you don't override your plugins render method (2.4 and up), you'll have your plugin as instance in your context. using the following, you'll get the 1 based position of your plugin:
{{ instance.get_position_in_placeholder }}
also interesting: is_first_in_placeholder and is_last_in_placeholder. in fact, #paulo already showed you the direction in his comment ;) this is the code, with new line number: https://github.com/divio/django-cms/blob/develop/cms/models/pluginmodel.py#L382
Quick question about WordPress. I've been Googling all over the place and cannot find an answer.
Basically I'm looking to replicate what happens when you add a gallery: have an image displayed as a stand in for the gallery shortcode [gallery]. The shortcode's visible when you go to edit HTML.
I'd like to exactly copy this effect: When a shortcode inserted into the editor I'd like for to to be rendered as an image.
Things I've Tried:
Inserting an element (image, div, I found an input is pretty unfuckwithable, etc) that's wrapped by a shortcode (This works ok, not great. The short code's still visible and WP will auto add paragraphs to the element to create space that users could, possibly, add content that'll be eaten by the short code) -
Inerting the short code as a < !-- --> comment (This also doesn't work great, WP will occassionally eat it moving between Visual/HTML. The comments ALSO eat your content < !-- [shortcode]--> placeholder < !--[/shortcode] --> = < !-- rendered shortcode -->)
That's the extent that I've thought of things. I cannot find a guide on how to do mimic the [gallery]'s behavior and can't find it by going through wp-admin's guts.
Thanks!
Alright, found the answer thanks to Dan's hint. Here's how to do it:
First (as Dan suggested) take a look at how they add the Gallery plugin to Tiny MCE. There's actually an uncompressed js file that will give you the overview you need, find it in:
/wp-includes/js/tinymce/plugins/wpgallery/editor_plugin.dev.js
This goes over the basics on adding this type of plugin to TinyMCE (more info here). To get WP to load the .js file with your TinyMCE plugin, see this helpful guide.
Basically here's the code:
if ( get_user_option('rich_editing') == 'true') {
add_filter("mce_external_plugins", "add_jolokia_tinymce_plugin");
//Applying the filter if you're using the rich text editor
}
function add_jolokia_tinymce_plugin($plugin_array) {
$plugin_array['example'] = '/path/to/example.js';
return $plugin_array;
}
Add this to a plugin or function.php in a theme And you're good!
I tried calling a block programmatically but it's not displaying the block title.
I added a block from the "add block" page. It has an id of 53.
I have this code in my page.tpl.php or node.tpl.php:
<?php
$blockTest = (object) module_invoke('block', 'block', 'view', 53);
print theme('block', $blockTest);
?>
It does show the contents (body) of the block, but not the block title (subject).
Any ideas why?
This appears to be a bug in Drupal core, at least in my reading of http://drupal.org/node/162899 and a potentially related issue at http://drupal.org/node/521668 The first one has a proposed patch, but it's a bit outdated, and will cause the update script to break. You can change the function in update.php after applying the patch to a number higher than what your current version is, but that might be a lot to ask. Even then, I couldn't get it to work.
Adding a cross-reference to your comment at http://drupal.org/node/26502#comment-3781716 which asks the same question.
You should have a look at the block_load() function, it might help you.