I'm trying to add superscript to the new editor in Wagtail.
I see the documentation here: http://docs.wagtail.io/en/v2.0/advanced_topics/customisation/extending_draftail.html
Where am I supposed to add the example code?
And am I correct in assuming that I will be able to just change the example from feature_name = 'strikethrough' and type_ = 'STRIKETHROUGH' to superscript and it will work?
Once this is registered, do I have to modify each RichTextField that I have to include it in the features setting, or is there a way to add this to all RTF in my application?
I believe I have figured out how to do this, hopefully, someone will correct me if there is a better way!
Create a file in one of your registered (in INSTALLED_APPS) app directories called wagtail_hooks.py.
Put the following code in the file:
import wagtail.admin.rich_text.editors.draftail.features as draftail_features
from wagtail.admin.rich_text.converters.html_to_contentstate import InlineStyleElementHandler
from wagtail.core import hooks
#hooks.register('register_rich_text_features')
def register_strikethrough_feature(features):
feature_name = 'superscript'
type_ = 'SUPERSCRIPT'
tag = 'sup'
control = {
'type': type_,
'label': '^',
'description': 'Superscript',
}
features.register_editor_plugin(
'draftail', feature_name, draftail_features.InlineStyleFeature(control)
)
db_conversion = {
'from_database_format': {tag: InlineStyleElementHandler(type_)},
'to_database_format': {'style_map': {type_: tag}},
}
features.default_features.append(feature_name)
features.register_converter_rule('contentstate', feature_name, db_conversion)
The line features.default_features.append(feature_name) is what answers the last part of my question - and is missing from the docs (well, it's there, but not in this context). This adds the feature to all RichTextFields without having to add the features=[] setting to each existing and/or new RTF.
To modify this to work with another built in Draftail feature, modify the feature_name, type_, tag, label, and description fields. Draftail supports the following types:
Block types: H1, H2, H3, H4, H5, H6, Blockquote, Code, UL, OL, P
Inline styles: Bold, Italic, Underline, Code, Strikethrough, Mark, Keyboard, Superscript, Subscript
And HR, BR
With bold, italic, h2, h3, h4, ul, ol, hr, and br already being in the Wagtail default set for a RichTextField.
As of Wagtail v2.5, superscript is a built-in format, disabled by default. To use it, all that's needed is to enable it. Either per-field, in the model definition:
# [...]
body = RichTextField(features=['superscript'])
# [...]
Or for all editors on a site:
from wagtail.core import hooks
#hooks.register('register_rich_text_features')
def enable_superscript_feature(features):
features.default_features.append('superscript')
Note that currently, while superscript will work as expected in the editor, it won’t be possible to copy-paste content with superscript from third-party sources (Google Docs, Word, web pages) and have the superscript formatting be preserved.
Related
I want to click an element by the text of a span who is the child of the element. How do I do this?
<button type="button" class="alert-button ion-focusable ion-activatable sc-ion-alert-md" tabindex="0"><span class="alert-button-inner sc-ion-alert-md">OK</span><ion-ripple-effect class="sc-ion-alert-md md hydrated" role="presentation"></ion-ripple-effect></button>
This is what I have tried but it didn't work.
#FindBy(css = "button[span:contains('OK')]")
Selenium doesn't supports the :contains pseudo-class anymore as #jari.bakken in their comment confirms:
AFAICT, the :contains pseudo-class isn't in the CSS spec and is not supported by either Firefox or Chrome (even outside WebDriver).
Further #dawagner in their comment also mentions:
contains isn't a valid CSS3 selector; because of this several browsers don't natively support contains, so Selenium (and WebDriver) don't claim to support it._
Solution
However you can still use the other attributes to construct a CssSelector to identify the element as follows:
#FindBy(css = "button.alert-button.ion-focusable.ion-activatable.sc-ion-alert-md span.alert-button-inner.sc-ion-alert-md")
As an alternative you can also use either of the following Xpath based locator strategies:
#FindBy(xpath = "//button[#class='alert-button ion-focusable ion-activatable sc-ion-alert-md']//span[#class='alert-button-inner sc-ion-alert-md']")
Using the innerText:
#FindBy(xpath = "//button[#class='alert-button ion-focusable ion-activatable sc-ion-alert-md']//span[#class='alert-button-inner sc-ion-alert-md' and text()='OK']")
or even:
#FindBy(xpath = "//span[#class='alert-button-inner sc-ion-alert-md' and text()='OK']")
even possibly:
#FindBy(xpath = "//span[text()='OK']")
CSS Selectors with Selenium do not support locating elements by their text content. Only XPath supports that.
Try this XPath:
//button//span[text()='OK']
or
//button//span[contains(.,'OK')]
or
//button//span[contains(text(),'OK')]
So the element could be defined as following
#FindBy(xpath= "//button//span[text()='OK']")
Or
#FindBy(xpath= "//button//span[contains(.,'OK')]")
I recently successfully implemented using react-18next for localization needs inside my app. I have a small package that contains the localization files, react-i18next setup, and exports a class which is referenced in another application to get the i18n instance and pass it to the which wraps my components.
This has been deployed and works as expected.
I stumbled upon the documentation here (https://react.i18next.com/latest/typescript#create-a-declaration-file), which says that you are able to make the t function fully type safe. I would love to implement this, so that I am able to catch mis-matched key errors at compilation time, rather than needing to hunt for each case within the application.
I am having some trouble achieving this desired type-safety though, and wasnt sure if it was something that I am doing wrong or possibly a bug in the typing (I assume the former, as others seem to get the safety working without any issue).
Versions:
react-i18next “^11.15.6”
i18next “^21.6.14”
react “16.14.0”
typescript 4.1+
Repo structure (excluding package.json, tsconfig.json, etc) :
src
translations
translations_en.json
translations_es.json
MyTranslationManager.ts
react-i18next.d.ts
The translation files do not use any nested strings, and are separated by language (”_en” vs “_es”). Each language has all the needed strings in their localized format. The files are in this format:
{
"string1": "First string",
"string2": "Second string"
}
In my live (working) setup, this is how I initialize my instance:
import translationEN from "./translations/translations_en.json";
export class MyTranslationManager {
private readonly i18nInstance: i18nType;
constructor() {
this.i18nInstance = i18n.createInstance();
const defaultResources = {
en: { translation: { ...translationEN } },
};
this.language = "en";
this.i18nInstance
.use(initReactI18next)
.init({
resources: defaultResources,
lng: "en",
keySeparator: false, // we do not use nested translation resources
interpolation: {
escapeValue: false, // React already prevents XSS
},
});
}
// WORKING ON TYPE SAFETY
As directed in the docs, I create a react-i18next.d.s file to redeclare the “react-i18next” module - specifically the CustomTypeOptions interface:
import "react-i18next";
import translationEN from "./translations/translations_en.json";
declare module "react-i18next" {
interface CustomTypeOptions {
resources: typeof translationEN;
}
}
I do not declare a “defaultNS” option to CustomTypeOptions because I rely on the default namespace, “translation”.
When I attempt to compile the project with the above code, I get the following TS2344 issue:
node_modules/react-i18next/ts4.1/index.d.ts:203:25 - error TS2344:
Type 'string' does not satisfy the constraint 'Namespace<"btn_cancel" | "btn_save" | ... 86 more ... | "msg_unsavedChanges">'.
203 N extends Namespace = DefaultNamespace,
The error is thrown from each line in react-i18next/ts4.1/index.d.ts that attempts to set Namespace = DefaultNamespace.
I copied over as much of the code in index.d.ts as I could into the Typescript playground to try and get some insight into what is happening here, and I am able to get the compilation error to repro.
Hovering over the following items in the Typescript playground gives some interesting insight:
DefaultResources will resolve to { “btn_cancel”: string; “btn_ok”: string; }
DefaultNamespace will resolve to “ type DefaultNamespace<T = "translation"> = T extends "btn_cancel" | "btn_ok" ? T : string “
I assume this gets set by the use of the Fallback type, which gets passed in each key from DefaultResources via the keyof...
Link to playground.
My question is, why are the keys for the language files being set as the namespace? Is this by design? Am I importing the resources in an incorrect manner?
I noticed that the example here (https://github.com/i18next/react-i18next/blob/master/example/react-typescript4.1/no-namespaces/%40types/react-i18next/index.d.ts) only shows what the docs point to as an older version, i.e using the DefaultResources type instead of CustomTypeOptions. Any guidance on using the new method without namespaces would be greatly appreciated :)
For anyone working with i18next#v22.0.0 and react-i18next#v12.0.0, following the documentation here was successful for me (as of the time this was posted):
https://www.i18next.com/overview/typescript
I am now getting types for my translations inside of the t() function
I'm using MathJax I can't able to break the new line.
I am already tried using <br/> , \nand \\ but its not works for me.
const blockFormula = `x =√(t ) \\
\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}}`;
MathJax Doc version 1.0.1
The line-breaks you show are for HTML and for regular Latex. MathJax only treats the MATH MODE PART of Latex, not all of Latex so you need to accomplish line-breaks math mode style. You basically have at least 3 options:
Use the math mode gather environment:
<MathJax>
{
`$$\\begin{gather}
x =√(t ) \\\\
\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}} \\\\
\\end{gather}$$`
}
</MathJax>
Use the math mode align environment if you also want to align the rows:
<MathJax>
{
`$$\\begin{align}
x &=√(t ) \\\\
\\mathrm{V}=\\frac{d x}{d t}&=\\frac{1}{2} t^{\\frac{-1}{2}} \\\\
\\end{align}$$`
}
</MathJax>
Since you're doing this in React with HTML, you can also add the different rows to different HTML / React components to accomplish what you want:
<MathJax>{`$$x =√(t )$$`}</MathJax>
<MathJax>{`$$\\mathrm{V}=\\frac{d x}{d t}=\\frac{1}{2} t^{\\frac{-1}{2}}$$`}</MathJax>
There are probably more ways too.
I took the liberty of using my own better-react-mathjax in the sandbox that I prepared for you, showing all these options using both display math and inline math, but it should work the same in all libraries that correctly uses MathJax with React.
Is it possible to use template parameters in the content of a post with Hugo? E.g. if I have the following parameters:
[params.company]
name = "My Company"
Can I then do something like this in the content of a post?
This site, {{ .Site.BaseURL }} is operated by {{ params.company.name }}
I've tried, but it's literally printing the above instead of interpolating the variables.
1. Front matter way
As far as I'm aware, it's not possible* to put variables within the markdown file's content because MD parser would strip them, but it's possible to do it using custom variables on the front matter of each .md content file. The Hugo engine can target any fields you set in front matter. Front matter fields can be unique as well.
In your case, the template which is called to show the rendered .MD file has access to front matter parameters and you can change template's behaviour (like add classes of extra <div>'s) or even pull the content right from the parameter.
For example, on my .md files I have:
---
title: "Post about the front matter"
<more key pairs>
nointro: false
---
The key nointro: true would make my first paragraph to be normal size. Otherwise, if key is absent or false, first paragraph would be shown at larger font size. Technically, it's adding a custom class on a <div>.
In the template, I tap into the custom parameter nointro this way:
parent template which shows your markdown file, which has front matter parameters:
<div class="article-body {{ if .Params.nointro }} no_intro {{ end }}">
{{ .Content }}
</div><!-- .article-body -->
Notice I can't put variables within {{ .Content }}, but I can outside of it.
For posterity, that's piece of the content from a file hugo/themes/highlighter/layouts/partials/blog-single-content.html, it's a partial for single post content. You can arrange your partials any way you like.
Obviously, that's Boolean parameter flag, but equally it could be content which you could use directly:
MD file's top:
---
title: "One of our clients"
<more key pairs>
companyname: "Code and Send Ltd"
---
Text content is put here.
Then, reference it like this (extra insurance against blank value using IF):
Anywhere in Hugo template files:
{{ if .Params.companyname }}{{ .Params.companyname }}{{ end }}
2. Using config.(toml/yaml/json)
Now, looking at your example, "This site is operated by " would almost warrant a custom field in more global location, for example, hugo/config.toml. If I wanted to add a companyname into my config, I'd do it this way:
hugo/config.toml:
BaseURL = "_%%WWWPATH%%_"
languageCode = "en-uk"
title = "Code and Send"
pygmentsUseClasses = true
author = "Roy Reveltas"
theme = "Highlighter"
[params]
companyname = ""
Then I'd use it anywhere via {{ .Site.Params.headercommentblock }}.
I guess if you want your client pages to be static pages then single location might not be the best and you might want to tap into front-matter. Otherwise, if it's a site's footer, this way is better. Alternatively, you could even put this data even on data files.
3. Using custom placeholders and replacing via Gulp/npm scripts
I said not possible*, but it's possible, although unconventional and more risky.
I had such setup when I needed two builds for my website: 1) Prod and 2) Dev. Prod URL's were coming from two places: CDN and my server. Dev had to come from a single place in a static folder because I wanted to see images and was often working offline on a train.
To solve that, I used two custom variables in all my templates (including markdown content): _%%WWWPATH%%_ and _%%CDNPATH%%_. I came up with this unique pattern myself by the way, feel free to adapt it. Then, I put it also on hugo/config.toml as:
hugo/config.toml:
BaseURL = "_%%WWWPATH%%_"
After Hugo happily generated the website with those placeholders, I finished off the HTML's using a Grunt task:
grunt file:
replace: {
dev: {
options: {
patterns: [{
match: /_%%CDNPATH%%_+/g,
replacement: function () {
return 'http://127.0.0.1:1313/'
}
}, {
match: /_%%WWWPATH%%_+/g,
replacement: function () {
return 'http://127.0.0.1:1313/'
}
}...
For posterity, I recommend Gulp and/or npm scripts, I'd avoid Grunt. This is my older code example above from the days when Grunt was the best.
If you go this route, it's riskier than Hugo params because Hugo won't error-out when your placeholder values are missing or anything else wrong happens and placeholders might spill into the production code.
Going this route you should add multiple layers of catch-nets, ranging from simple following Gulp/Grunt/npm scripts step which searches for your placeholder pattern to pre-commit hooks ran via Husky on npm scripts that prevent from committing any code that has certain patterns (for example, %%_). For example, at a very basic level, you would instruct Husky to search for anything before allowing committing this way:
package.json of your repo:
"scripts": {
"no-spilled-placeholders": "echo \"\n\\033[0;93m* Checking for spilled placeholders:\\033[0m\"; grep -q -r \"%%_\" dist/ && echo \"Placeholders found! Stopping.\n\" && exit 1 || echo \"All OK.\n\"",
"precommit": "npm run no-spilled-placeholders"
},
Basically, grep for pattern %%_ and exit with error code if found. Don't forget to escape the code because it's JSON. I use similar (more advanced) setup in production and nothing slips through. In proper setup you should creatively look for anything mis-typed, including: %_, _%, %__, __% and so on.
Normal Go template is not supported in the markdown file, but shortcodes are:
{{< param "company.name" >}}
To access arbitrary other Go template values, create a custom shortcode for it and call that from your markdown file.
For your example, you need the site's baseUrl, so save this as layouts/shortcodes/base_url.html:
{{ .Site.BaseURL }}
And write this in your markdown file:
+++
[company]
name = "My Company"
+++
This site, {{< base_url >}} is operated by {{< param "company.name" >}}
There is also the shortcode param : {{< param "companyName" >}} : https://gohugo.io/content-management/shortcodes/#param
In Ext JS 4, they added a way to override the default coloring scheme by using SASS/Compass, so what I'm trying to do is create a new button style, using extjs-button-ui, and then applying that style to a button. The button's code is as follows:
xtype: 'button',
text: 'should be orange',
ui: 'orange'
My SASS code is as follows:
$button-default-background-color: mix(blue, red);
$orange-button-background-color: mix(yellow, red);
#import 'compass';
#import 'ext4/default/all';
#include extjs-button-ui(
'orange',
$button-small-border-radius,
$button-small-border-width,
$button-default-border-color,
$button-default-border-color-over,
$button-default-border-color-focus,
$button-default-border-color-pressed,
$button-default-border-color-disabled,
$button-small-padding,
$button-small-text-padding,
$orange-button-background-color,
$button-default-background-color-over,
$button-default-background-color-focus,
$button-default-background-color-pressed,
$button-default-background-color-disabled,
$button-default-background-gradient,
$button-default-background-gradient-over,
$button-default-background-gradient-focus,
$button-default-background-gradient-pressed,
$button-default-background-gradient-disabled,
$button-default-color,
$button-default-color-over,
$button-default-color-focus,
$button-default-color-pressed,
$button-default-color-disabled,
$button-small-font-size,
$button-small-font-size-over,
$button-small-font-size-focus,
$button-small-font-size-pressed,
$button-small-font-size-disabled,
$button-small-font-weight,
$button-small-font-weight-over,
$button-small-font-weight-focus,
$button-small-font-weight-pressed,
$button-small-font-weight-disabled,
$button-small-font-family,
$button-small-font-family-over,
$button-small-font-family-focus,
$button-small-font-family-pressed,
$button-small-font-family-disabled,
$button-small-icon-size
);
I have a couple of questions/observations. When I compile this, I get no errors and the standard Ext JS theme with purple buttons, but the button I defined above, has no style... it's just text. These variables are all included in the _all.scss file, which imports the _variables.scss file, which includes the variable definitions that are in variables/_button.scss, and if the vars were undefined, the compiler would whine.
My first question is, why is this not working/what am I missing?
And my second, more broad SASS question, how do I inherit from a mixin? The orange include is actually inheriting all of those variables from the default-small extjs-button-ui. So I want the background-color and name to be orange, but I want everything else to be inherited from the default-small include. Is this possible? I thought something like:
#include extjs-button-ui(
#include extjs-button-ui('default-small'),
'orange',
$button-default-background-color: mix(yellow, red)
}
would be the ticket, but I was apparently horribly wrong. I can inherit a mixin by doing something like:
.orange {
#include extjs-button-ui('default-small', $icon-size: 16px);
$button-default-background-color: mix(yellow, red);
}
But that's not creating an orange ui that I can use in Ext JS... just an orange CSS class that has the button values, but not my background-color. So what am I doing wrong? I've tried looking all over for ways to accomplish this, but nothing's working. Does anyone have any insight?