My company is using Wagtail to build robust pages for our website, likely using the StreamField component. We're wondering if Wagtail allows the possibility of us creating reusable parts (perhaps in a snippet), and injecting them into a page.
I'm including a simple diagram of what I'd like to do. Note that while snippets are one possible suggestion, it doesn't need to the specific solution.
The goal of course is to create an element which can be embedded in another page, but can be updated in a single place and cascade everywhere it's used.
Wordpress for example, has a plugin which offers this functionality in short code format:
[embed id=123456]
You can create new block for stream field, let's say MySnippetBlock and then use SnippetChooserBlock to choose the snippet you want.
MySnippetBlock(StructBlock):
title = CharBlock()
snippet = SnippetChooserBlock()
Then in your StreamBlock field you can use above custom block:
MyPage(Page):
stream_field_content = StreamField([('snippet_block', MySnippetBlock())])
...
Or you can use SnippetChooserBlock directly within StreamField if there is no need for additional info attached to it.
stream_field_content = StreamField([('snippet_block', SnippetChooserBlock())])
Related
I'm trying to create some tests for my first Django site. One thing that is burdensome is creating example pages for testing (at least you have to specify a lot of parameters and some (such as ContentType) are not always obvious. More generally, I'd like to use Model Mommy to create many of the objects I need.
Near as I can tell, it can't create an instance of a Page (claiming that a "Page matching query does not exist"). [the test case is a simple import of Page and Model Mommy then create an instance of a page].
I'm not sure if this is properly an issue for Wagtail or for Model Mommy, but debugging it is getting a bit out of my depth and it would be very useful if it could work.
Unless there is something obvious I'm missing or can/should do, I'm posting this more to flag the problem than to try to get a solution right now.
Thx,
--Don
Mommy doesn't handle Django Tree Beard relations. Tree Beard is the package used by Wagtail to create the page tree.
Mommy doesn't create the tree structure correctly. You should add your pages to the tree yourself. You can do this with add_child.
Root is created by the Wagtail migrations: https://github.com/wagtail/wagtail/blob/master/wagtail/core/migrations/0002_initial_data.py#L13-L38
There is no need to set the content type manually if you use your specific class directly. I used FooPage in the example below.
from wagtail.wagtailcore.models import Page
from app.models import FooPage
root = Page.objects.get(slug='root')
page = FooPage(title='Example', ...)
root.add_child(instance=page)
I am trying to add links in the form 555-555-555 arbitrarily into paragraphs of text on my wagtail site. These phone numbers are currently peppered throughout the site as plain text, but I want to convert them to links.
I found this old wagtail github issue where they explained why they would not add them, but the 'Special-purpose pages' use case they described seems to be different than mine: my site has these numbers in paragraphs of text on most of the content pages (blog, product, marketing, etc).
Can anyone explain how I can add telephone links that can be used throughout the site?
I am using wagtail 1.x
To have telephone link within rich text, you'll need to create a plugin for Hallo.js. Have a look at the documentation and how Wagtail 1.13 creates and register such plugins.
Be aware though that it's usually quite involved and that Wagtail 2.0 rich text editor is now Draftail and Hallo.js is deprecated. Therefore, if you create a Hallo.js plugin and upgrade to Wagtail 2.0, you'll have to add some configuration to continue using Hallo.js or recreate the plugin for Draftail.
FWIW, if you are interested in having a look at what would be involved with creating an plugin for Draftail, you'll need to create an entity (also note that the API for creating entities should receive some enhancements in Wagtail 2.2).
With Raw HTML there is nothing to prevent editors from inserting malicious scripts into the page. Do not use this block. http://docs.wagtail.io/en/v2.1/topics/streamfield.html#rawhtmlblock
A workaround would be a custom filter. Eg:
{{ self.text|richtext|phonify }}
In your templatetags.py:
>>> def phonify(val):
... for tel in re.findall(r'tel:(\d+)', val):
... tag = '{}'.format(tel, tel)
... val = val.replace('tel:{}'.format(tel), tag)
... return val
...
>>> phonify('Hello tel:123 world tel:456!')
'Hello 123 world 456!'
>>>
Now you can instruct editors (via help_text) to add phone numbers like tel:5555555555.
This example does not handle - and +1. But if you figure that out, I'll update the answer ;)
I ended up chopping up my paragraphs and including raw html where I needed to add the tel links. A bit tedious, and the styles were slightly different on some pages, but shorter than doing it any other way.
In Drupal one can basically style the elements, like the search box, or the basic page etc. and then put some content in the site and the resulting page will be generated. But what if you want one specific site (e.g. the index page) to be different? E.g. have a image as a background, a different navigation styling etc.
What's the best paractice way of doing this?
Best practice is to have a different theme which you can switch to by using hook_custom_theme() where you check the current path. Also make sure that your theme to switch to is enabled:
/**
* Implements hook_custom_theme().
*/
function YOUR_MODULE_custom_theme() {
# check path with arg(0)
# return theme name to switch to
return 'different_theme_machine_name';
}
Alternatively you can also try ThemeKey doing this out of the box with an interface & allowing you the specify rules.
If you need to change only the content(body) section of your page, use Disply Suite. You can create unique look and feel layouts for your body section of each page.
If you trying to change the complete layout of one page (eg: Services), Create new Content Type 'Services'. Then create a template file for this content type, You must name this template call page--services.tpl.php. And also you can overwrite the index page layout by creating page--front.tpl.php template. Done!
What you are saying you want to change is all styling. And you know you can do a page to look drastically different with CSS... and you can do it that way depending on your chosen Drupal theme.
Now, with the Chrome Inspector (or FF inspector) look at the body tag, it probably has many classes which indicates in what page you are, what type of node (if it's a node) or if it's an admin section, or an anonymous user.
Using those specific classes you can style a frontpage, or a view, or a node, or anything, without installing more modules... with some limitations because you can't change rendered HTML this way.
Finally, don't get scared by using modules in Drupal, it's how Drupal works and it works pretty well. The thing is to install the best tools to increase your productivity, and Drupal have excellent options to change your theming and content like Display Suite (like #BaikHo suggested).
Hope that helps.
PD: Using the less module and with custom your theme you can have LESS css which is considerably faster than using only CSS, and because it's integrated with Drupal you can theme make everything even faster. Give it a try.
I'm currently making a bilingual Expression Engine 2.5.2 website. I'm using this technique to create the two langues, which works perfectly.
I have created a {country_code} global variable in the two index.php files which allows me to detect the current language.
Using this technique, I have no problems to get language-relative data when accessing an entry. My only concern is that I apparently have to privilege a language-specific "clean" URL.
Example entry:
{entry_id} = 123
{title} = My test article
{title_permalink} = my-test-article
{name_fr} = Mon article
{name_en} = My article
If I request http://www.example.com/index.php/en/blog/articles/my-test-article, I expect to to find, in english, "My article" using the template articles in the blog template group.
Everything is fine, but the french translation is accessible when requesting http://www.example.com/index.php/fr/blog/articles/my-test-article. The correct translation of the URL should be http://www.example.com/index.php/fr/blogue/articles/mon-article-test.
Anyone encountered a problem like this? Any solutions via extensions or modules?
I believe the Transcribe module solves this by both providing the ability to translate template group and template names, and having you create a separate entry for each language and piece of content in your site (hence, you have two separate URL titles). But that means buying into their entire methodology for a multi-lingual site.
Myself, I usually just stick to using the entry_id instead of the url_title, and live with the template names being in the primary language.
The best way I found to achieve this is by embedding templates with segment translations, duplicating template groups and duplicating channels.
In the blog/articles template:
{embed="shared/.head" segment_2_translation="blogue" segment_3_translation="articles"}
In the blogue/articles template:
{embed="shared/.head" segment_2_translation="blog" segment_3_translation="articles"}
In shared/.head template:
[...] {if lang == "fr"}English{if:else}Français{/if} [...]
And then you can create a Articles (FR) and a Articles (EN) channels, and each will have their unique URL titles. You can also add a relationship custom field for each channel to associate an entry with it's translation.
It feels messy, but it is the only way I could make it work without modules, plugins or whatnot.
I have a requirement to perform an indexed search across content which must include a couple of tags in the result. The tags must be a random selection. The platform is Drupal 7.12
I have created a view that manages the results of a SOLR search through the search_api. The view returns the required content and seems to work as intended. I have included a couple of Global: custom text fields as placeholders for the tag entries.
I am now looking for a solution to manage the requirement to randomise the tag values. The randomisation is not the issue, the issue is how to include the random values into the view result.
My current approach is to write a views_pre_render hook to intercept the placeholders which appear as fields ([nothing] and [nothing_1]). The test code looks like the following
function MODULE_views_pre_render( &$view )
{
$view_display = $view->display['default'];
$display_option = $view_display->display_options;
$fields = $display_option['fields'];
foreach( $view->result as $result )
{
$fields['nothing']['alter']['text'] = sprintf("test %d", rand(1,9));
}
}
I am currently not seeing any change in the placeholder when the view is rendered.
Any pointers to approach, alternate solutions etc would be gratefully received as this is consuming a lot of scarce time at the moment. Calling print_r( $view ) from within the hook dumps over 46M into a log file for a result set of 2 items.
There are two possible solutions for your task.
First approach is do everything on the template level. Define a template for the view field you want to randomize. In advanced settings of your display go to Theme: Information. Make sure that the proper theme is selected and find the template suggestions for your field. They are listed starting from most general to the most specific and you can choose whatever suits you better.
I guess the most specific template suggestion for your field would be something like this: views-view-field--[YOR VIEW NAME]--[YOUR DISPLAY NAME]--nothing.tpl.php. Create the file with that name in the theme templates directory and in this template you can render what ever you want.
By default this template has only one line:
print $output;
you can change this to:
print sprintf("test %d", rand(1,9));
or to anything else, whatsoever :)
Second approach is to go with Views PHP module. WIth this module you can add a custom PHP field in which you can do whatever you want. Even though the module hasn't been released it seems to work quite well for the most of the tasks and most certainly for such a simple task as randomizing numbers it will work out for sure.
I stumbled upon this while searching for another issue and thought I would contribute.
Instead of adding another module or modifying a template, just add a views "sort criteria" of "Global: Random".