We're using the WordPress REST API to power a static site. The site is "headless" in the sense that we don't use a WordPress theme; we rely on the content being exposed via the REST API.
Some of the default Gutenberg blocks - the Buttons block for instance - have styles with hashed class names associated with them that don't seem to be exposed in the API. This would be kind of ok if the class names were predictable but, since they aren't, we have no way of providing the styles on our end.
If we do render the blocks in a theme, the styles are rendered in the footer
Here's an example of the style block for the default Buttons block looks like in a WordPress theme
The Rest API endpoint exposes the markup in content.rendered (including the classnames) but no styles
Is this expected behavior for using Gutenberg and the WordPress REST API? If so, is the correct solution to expose the styles via a custom field (for lack of a better term) on the API?
The unique id (hash) in the classnames are randomly generated each time the blocks are parsed, even when directly calling the REST API. Unfortunately, the inline style attributes like .alignleft are absent from the content markup in the REST API. Being a REST API, it makes sense that style specific information isn't included; this keeps data and presentation of the data separate. It also prevents bloating the API by including style-specific information that would be rarely used outside of WordPress theme.
In your scenario, if you wish to style the resulting HTML content without worrying about the unique id, I'd suggest using css partial selectors, eg:
div[class*="wp-container-"] .wp-block-button{
...
}
Alternatively, as you mentioned, its possbile to extend the REST API to include the styles. While I haven't built a working example of this for styles, when blocks where introduced I ended up extended the REST API to include extra meta data. I'd suggest looking at render_block_data to handle adding in the styles into the content.
Eg. For the buttons block, the serialized content stored in the database as:
<!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link">Hello</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->
By using parse_blocks() you can obtain all the block properties into an array and get style information that way. I think this approach is do-able if you just add the generated classnames and not the inline styles. I am keen to know if you find a better way...
Related
I can't seem to grasp or find out why you should use HTML templates with web components when you can simply define the HTML inside the web component (shadowRoot.innerHTML).
What is the benefit of creating a template and cloning it inside the web component? I can see there being a reason if two web components share the same HTML but beside that I have no idea.
Is there something fundamentally important that I'm missing?
Yes, too many blogs do document.createElement("template") where an .innerHTML will do the same ... and with less code ... and faster.
Note, Templates are not tied to the Custom Elements API or shadowDOM.
Each of the 3 Web Components technologies can be used without the other.
Templates
Templates are great when you want to store re-usable content in the HTML Document, because it does not get parsed.
In the old days we would use a <div hidden> and pray its contents did not affect the rest of the page.
Just like the old days you can read the Template.innerHTML and do whatever you want with the String value.
More modern approach is to clone the Template, just be aware that .content property is required, and you get a Document-Fragment value in return.
<template id="MY-TEMPLATE">
<article>
...
</article>
</template>
document.getElementById("MY-TEMPLATE").content.cloneNode(true)
Templates & shadowDOM
When you have Custom Elements with shadowDOM, Templates are great to define that shadowDOM content.
Why so many developers want to do HTML-in-JS and CSS-in-JS I don't understand.
If you have an HTML document, store the content there, way easier to edit.
<template id="MY-ELEMENT">
<style>
/* style shadowDOM here */
</style>
<slot></slot>
</template>
All your MY-ELEMENT then needs to do is:
super() // or this when done in the connectedCallback
.attachShadow({mode: 'open'})
.append(document.getElementById(this.nodeName).content.cloneNode(true))
Performance
an innerHTML String with HTML content will get parsed for every usage.
A template is parsed once, so does save on CPU cycles, when you use the same template many many multiple times
Usage
My personal preference is to keep as much HTML (and CSS) inside <TEMPLATEs> in HTML as possible. Only when I want my components not to be configurable I use static HTML in JS, with .innerHTML, not .createElement("template") for code brevity over (minor) performance gain
Only in SDWCs (Self Destructing Web Components) that need to load/execute ASAP I contain everything inside the Component:
customElements.define('my-head',class extends HTMLElement{
connectedCallback(){
// generate <HEAD> content, <SCRIPTS> and <STYLE> CSS-in-JS here
this.remove();
}
});
What is the benefit of creating a template and cloning it inside the web component?
Speed. Parsing a string and generate internal html objects takes some extra time compared to just cloning nodes. If the web component is used in many places and each will parse string and convert it to html objects. Compare that with just parsing once.
tutorial about web components
Typo3 provides option to add multiple images to a page content, but all the images are wrapped under some default <div> tags. I want these images to be wrapped under <ul> and <li> tags instead and giving my own custom CSS ids and classes to it.
There are not many resources on TYPO3 for me to approach this issue. Can TYPO3 allow to use custom tags for the page content elements?
UPDATE
From Jost's answer was able to get my images displayed, but how do I split the image details?
My each image will have title, alt-text, image-path and image-link. Now, using TypoScript how do I retrieve this, because each details has to go in separate tags.
Check the TypoScript object browser. There you will find the object tt_content, which contains the rendering definitions for content elements. The rendering definition for images is found at tt_content.image.20, for example
tt_content.image.20.imageStdWrap.dataWrap = <div class="csc-textpic-imagewrap" style="width:{register:totalwidth}px;"> | </div>
The default definitions given there are usually provided by the static TypoScript of CSS-styled-content. You can overwrite them in your own TS, but when updating to a newer TYPO3-version, the default template may change, which could result in additional wrappers.
Update
Most content rendering in TYPO3 is defined in the TypoScript object tt_content. You can browse all TS-objects that will be used on a page by selecting the "Template" module and the page in question, and then choose "TypoScript Object Browser" in the selectbox at the top of the window. To understand what that stuff means, knowledge of TypoScript is necessary (Tutorial, Reference).
You can add your own TypoScript, which may override existing settings. You can do that in the Template-module too, but usually this is done by creating a file containing the script somewhere in the fileadmin folder and including it from the Template module.
The above enables you to edit the markup of the page. (Additional) CSS is usually defined in external files, that are included by a PAGE object (see the reference about that).
This post is a bit older but I want to add the following:
If you want to understand how the different content elements are wrapped, you may have a look into the css_styled_content extension. I assume that you have included the "Static Template (from extension)" in your main Typoscript template.
You can find the setup.txt here:
typo3/sysext/css_styled_content/static/setup.txt
There you´ll find the line Jost mentioned in line 860 (TYPO3 version 6.1), for example. And of course a lot of other definitions, too.
But check to read the documentation and tutorials on typo3.org.
HTH
merzilla
EDIT: Would it be more elegant to tweak the GUI using CSS, or some other way?
Is there any good documentation (the official one only shows a basic example) for this tag?
I want to use it like this:
<s:decorate template="template.xhtml">
....richfaces UI...
</s:decorate>
in order to format a list of question-answer pairs without using rich tables or nested panels.
I get the gist of what it does, but I don't understand exactly how I can edit my own template.xhtml files and make the UI look as I want by using it.
The s:decorate is basically the same as ui:decorate with some extra functionality like rendered
The ui:decorate can be explained as:
The UI Decorate tag is a templating
tag that decorates content included
from another Facelet. Any content
outside of the UI Decorate tag will be
displayed by the Facelets view
handler. Any content within the
decorate tag will be passed to the
associated template as parameters or
simply ignored. You can use nested
ui:define tags to pass named content
to the associated template. See
ui:insert for more information.
For more info you can read here and here
To answer your update question. You should also use CSS to style the content of your template
A web designer has created a design for our Drupal web site which requires a different color scheme for various sections of the site. Drupal does not support this design requirement by default.
Currently I am using JavaScript to change the color scheme based on the page title. After adding some content pages I now realize that this is a terrible way of doing things. I need some ideas for a better way of changing the color scheme depending upon the content.
Is there a way to apply a different theme to a page based on its node value? I could create a slight variation of my theme for each color scheme, although that makes theme maintenance more difficult.
I've also thought about using CCK to add a field to my page content type and then changing the color scheme based on that custom field. This would eliminate the need to add code to my JavaScript for every new page.
Or is there a module for changing color schemes per page?
You might want to take a look at the ThemeKey module, which allows you to determine which theme is used based on conditions like node type or path.
You could add some css in hook_preprocess_page function based on node or other criteria and add the css in the page template as embedded styles.
The idea will be the same as doing it in JavaScript, but you will have php, drupal etc available to do what you need. It should be a lot easier since you can test the node type, or a value you set on the node object.
The CSS module does node-specific CSS, so you could use that to adjust colors.
I would suggest implementing hook_preprocess_page in your theme, and applying a body class based on the node type (or types) being displayed. Or, potentially, put these classes in the node's preprocess for display. So, for instance, if you're viewing a 'project' node, put:
<body class="... node-type-project">...
Then the designer can target styles based on which classes the body has. This is fairly easy to automate, just do a "node-type-". strreplace("_", "-", $node->type) to change any future node type into a class, which you then feed into either the body or the node.
I know that I need to add the tracking code snippet at the bottom of all my pages, but is there a central location to do this?
Or do I need to add this tracking code to all of my templates?
I guess that I could wrap the snippet in a user control, or external .js file, and reference it on each page, but is there a global footer somewhere? The site I'm working on has about 30-40 layouts, and adding it to each one would be a pain!
Thanks in advance!
Actually, the role of a Sitecore layout is exactly this; to act as a global file that all individual page templates "derive" from.
Normally you'd stick the analytics code into the master layout, and use Sitecore sublayout/placeholder techniques to construct the various page templates you need. You would not normally need more than perhaps one or two layouts for any device you are serving content to. And I guess for most sites, the only device in use is regular web content delivery.
That being said, what you could do, is have all the layouts inherit their codebase from a common base class (inheriting from Page), and inject the google code centrally from here. Would still require you to go through all layout files however.
I have not tried the module, I think that is codebehind version. I have made this in XSLT, its pretty fast and easy to make. I have footer.xslt where I put the code that simply checks if page you are standing on uses template that I want to index and does not belong to page names that I want to exclude. Then I have an item with a custom template for Google Analytics with following memo fields.
IncludeTemplates -field contains list of templates that I want to include for analytics :
ExcludeItemsNames -field for excluding pages by item name
contains($includeTemplates, concat('|',./#template,'|')) and not(contains($excludeItemNames, concat('|',./#template,'|')))
Remember #key and #template is always in small letters
If you run many domains don't forget to add pageTracker._setDomainName("www.example.com"); in analytics script so you can separate sub-domains etc. if they use same footer.xslt
Normally we consider the actual Google code as content. Within Sitecore we normally have a settings folder, something like /sitecore/content/settings. This exists outside the root of the site. Beneath this have a settings item with a plain multi-line text field, I think the field type is memo or something similar.
Afterwards create an XSLT that renders out the content of this settings item. Something like (assuming the field is called value in the setting item):
<xsl:value-of select="sc:fld('Value','/sitecore/content/settings/footerJavaScript')" />
You may or may not need to set the disable-output-escaping attribute.
Then on the aspx page that your pages use as the template add a control that looks at the xslt rendering:
<sc:XslFile runat="server" Path="/xsl/footerJavaScript" />
The reason that we normally keep the javascript as content is this allows the client to change the analytics code without having to contact us.