I'm looking for the equivalent of ModX's chunks in CMSMS. I've found Global Content but this doesn't appear to be what I want.
I want to be able to define some HTML, have it completely hidden from the end user editors that will be using the CMS to edit the site, and insert it into various templates like you can do with ModX's chunks.
You are looking for User Defined Tags.
They are PHP code blocks that you can use in your templates/global content blocks/content pages.
Related
I'm looking for something like gulp-html-replace but instead of replacing what's in between the
Will be useful for modifying html documents.
I think you're asking the wrong question. If you have a consistent part (content) present in multiple html documents, you should be using a server side language to generate the html pages. That way you can create partials and modularize them to be included in multiple pages so when you change it once the change can be reflected.
If this is somehow not an option (for whatever reason) you should consider looking at something like handlebars
Also if the content is fairly static, most modern editors will allow you to search / replace in multiple files, there should be no reason to use gulp for what you are describing.
That being said try gulp-inject
I´m trying to understand how the use of the stash plugin will affect the URls of my site.
The traditional way:
I have a template group called site. Within the TG site I have the templates articles, about_us, etc.
The URl will for a single entry be
www.mysite.com/index.php/site/articles/title_of_respective_article
URL for the About-us-page:
www.mysite.com/index.php/site/about_us
Both will reflect the template_group/template structure and thus be SEO-friendly and give users a hint where they are on the site.
But when I use stash I will have 2 wrappers (one for the homepage and one for the rest of the site.
Partials will be used for header, main content and footer.
As far as I understand it, I´ll use the template_groups layout for the wrappers and partials for the main content.
The templating look like
Two wrappers build the TG "layout" Both are hidden, since they should´nt be called directly.
layout
.homepage
.site
Three partials in the TG partials
partials
header
main_content
footer
And by the way shouldn´t those not also be hidden, since they aren´t complete HTML-pages either.
This is what confuses me. How do I get my nice URLs back?
A URL like
www.mysite.com/index.php/site/about_us
will not match the TG/T concept anymore.
Any help?
To expand on both their answers above, and just to be specific to your www.mysite.com/index.php/site/about_us request:
You'd create a template group called "site" and then you may alternatively have something like this code in the /index template
{embed="layout/.site"}
{exp:channel:entries limit="1" disable="categories|member_data|pagination"}
{exp:stash:set name='title'}{title}{/exp:stash:set}
{exp:stash:set name='maincontent'}
<section>
<h1>{title}</h1>
<article>{content}</article>
</section
{/exp:stash:set}
{/exp:channel:entries}
The embed calls the .site layout and the interior simply pulls your specific channel:entries data.
As you can see, it's still using the traditional templategroup/template ways of building URLs, it's just pulling data differently.
When using Stash and the template partials approach (which I don't use personally), the files you mention are all embedded. You still use the same template groups and template files as before.
The Stash-based approach is simply a different way of doing things within your existing templates - not a replacement for them.
Exactly as Derek says. The way to think about it is this - with the template partials approach, your templates contain mostly (if not only) the entries logic (channel entries loop, its parameters, what custom fields are in play for that channel, etc). The outcome of the logic gets stores as stash variables. The stash variables then get called upon by your embedded layout templates to display the content you've stashed. So your URL structure remains the same, but you have considerably less duplication of effort since the more you constrain your templates to logic (i.e. very little if any formatting/display markup) the cleaner they are and the easier it then is to manage your templates.
I would like to "customize" my sharepoint wiki by doing something very simple.
I would like to be able to run a regex on wiki pages looking for [math] and [\math] tags, then take the expression written in the middle (assume this value is stored in a variable x) and replace the whole block by
"<img src='http://latex.codecogs.com/gif.latex?" + x +"'/>"
So for example, the shortcode [math]a^2+b^2=c^2[\math] should end up being displayed as an image as follows (thanks to this online tool):
I have never developed anything in sharepoint, and I've been using it for a week.
Can anybody tell me how I should proceed to add such a feature (if it's possible)?
You can use existing solution like ShortPoint.
Sure - this is simmply done via two methods - 1) You could modify the page directly using SharePoint designer - fly in the code where you want it, 2) The better way - add your code to text file, upload the text file to a document library then use the Content Editor web part, drop it on the page, point it (through the properties) to the text file.
Note: The Content Editor part will allow you to modify the background HTML/Script, however, it has a nasty habit of overriding your code and I've had it actually duplicate itself (adding repeat scripts). Using the Text file eliminiates that issue.
If i understand you correctly, I don't think that the content editor web part is the solution you are looking for. I believe you are wanting to implement a shortcodes solution such as that found in WordPress, correct? In that case, the issue becomes a bit more complex. To really get any kind of custom code that would execute at the necessary stages, you would need a custom solution either implementing additional functionality in the existing rich text editor, or roll your own custom rich text editor.
At that point, you would have complete control over how the content is parsed and interpreted, so you could have both server-side and client side processing. You could make use of templating engines like mustache or handlebars.
To do this, you would need to write your own Custom field type, inherit from SPFieldMultiLineText, override the property FieldRenderingControl, and return your custom control. That way you have the option of implementing it in several different places (custom pege fields in a page layout, custom webparts, custom lists, etc.) and you still get the benefits you want from the out-of-the-box control.
I am trying to add a small "3 box news segment". I wanted it, to be visible on multiple pages. Normally I would just use chunks but the thing is that I want to be able to modify "3 box segment" content and preferably with a ritch text. Any Ideas how to accomplish that?
You can use getResources to grab the content from 3 hidden resources this way you still keep your chunks for the segment layouts and your actual content is in the resources [which you can update with the rich text editor].
Instead of getResources you could also use getResourceField to get the value of a field or template variable on for example the homepage. This allows one place to manage it, and you can just reference it with getResourceField when you want it to show elsewhere.
I have an entry form where the user can type arbitrary HTML. What do I need to filter out besides script tags? Here's what I do:
userInput.replace(/<(script)/gi, "<$1");
but the sanitizer of WMD (used here on SO) manages a white list of tags, and filters out (blanks) all other tags. Why?
I don't like white lists because I don't want to prevent the user from entering arbitrary tags if she so chooses; but I can use a more extensive black list, besides 'script', if needed. What do I need as a black list?
Short answer: anything they can do with the script tag.
The script tag is not required to run javascript. Script can also be placed in almost every HTML tag. Script can appear in a number of places additional to the script tag including, but not limited to, src and href attributes that are used for URLs, event handlers and the style attribute.
The ability for a user to put unwanted script into your page is a security vulnerability known as cross-site scripting. Read around this topic and read the XSS prevention cheat sheet.
You may not want to let users add HTML to your pages. If you need this feature, consider other formats such as Markdown that allows you to disable the use of any embedded HTML; or another less secure option is to use a filtering library that tries to remove all script, such as HTMLPurifier. If you choose the filtering option, be sure to subscribe to announcements of new releases and always go back to your project to install the bug-fixed releases of the filter as new exploits are found and worked-around.