I have a CMS that includes some content via a self-hosted instance of Squidex. Right now, I can iframe Squidex into the CMS with proper authentication and such. The problem is that I get the whole Squidex UI (eg., the ability to create schemas and such) when I really just want the editor for a specific schema's content.
The outer CMS knows the app and schema names.
My guess is that I'd need to add a query parameter or two to the Squidex iframe URL, but I can't find documentation about what that might be.
How do I hide everything but the actual content editor bits from within the outer CMS?
Related
Below is some info to have context about the problem I am looking for solution:
"I only want to have a prod environment for contentful. the preview url is being used for UAT and Dev environments. So if the content is in the draft it will be reflected in Dev and UAT and when published it will be reflected in both environments as well as Prod".
Now the issue is there are some links in content that has a prod domain like www.[prod-domain]/blah blah, I need those URLs domain to be replaced with UAT or Dev domains in the draft (depending on environment) like www.[UAT-domain].blah blah
Is there any middleware for this? if not, what's the best way to achieve this in-app?
Salma from Contentful here!
If you use relative links in the content (e.g. /blahblah), they would automatically resolve to the current domain when navigated to on the front end.
If you're using Rich Text and outputting links in the flow of the text, you could get around the protocol requirement in the usual link formatter by creating a custom 'internal link' entry content type, which you can embed as an inline entry. For this content type, you could ask editors to provide a path to a page without the https protocol and domain, and ensure there is validation for that in the web app (using the pattern validation).
Another option would be to remove the protocol and domain from the urls when rendering on the front end to avoid the editors having to create extra entries when adding content to the Rich Text field.
I have followed this tutorial https://help.liferay.com/hc/en-us/articles/360018167031-Creating-Layout-Templates to create custom layout for Liferay 7.3. After deploy the layout to the Liferay manually using app manager, I'm not able to find the custom layout in Fragment and Widget option.
When I check in Global Menu > Control Menu > Components > Layout Templates. I'm able to see my custom layout.
Did I missed anything or is there any other way to add custom layout to Fragment and Widget options?
Thanks
You missed one crucial info: "Layout Templates" are only applicable to pages of the type "Widget Page" (the default and pretty much only page layouting method in Liferay 6 and earlier). "Page Fragments", on the other hand, are only applicable to pages of type "Content Page" (which came up somewhere between 7.0 and 7.3). You set the type of a page at the moment you create them, by selecting one of the corresponding page templates.
So, if you want to create a certain row/column layout as a template for your "Content Page", you may want to look into the page fragment type "section". Basically, you'll be creating a Page Fragment that incorporates some <lfr-drop-zone id="invent-your-own-id"></lfr-drop-zone> tags in its HTML. Documentation on dropzones is very sparse at the moment (best source I found is Liferay's issue tracker plus experimenting yourself), but as this tag currently does not allow more attributes than id, you can simply experiment with it.
(Side notes: Due to some arcana in some standard documents, you cannot use the self-closing form of the <lfr-...> tags, so <lfr-drop-zone id="abc" /> will fail silently. Also, remember that the HTML part of a page fragment actually will be interpreted as an FTL template using Freemarkers alternative syntax before the <lfr-...> tags are interpreted., which gives you the option of placing a configurable amount of dropzones using a loop.)
But: take a moment to check whether you really need a custom "dropzone layout", as Liferay already provides you with a configurable "row section" in the content page editor; and anything more complex will give you headaches when making it responsive.
We are going through this exact same situation. Up until 7.1, we used Layout Templates on Widget Pages to enforce a consistent design over our Org's Intranet, while still having per-Department Authors (see Herding Cats).
New requirements, including the Users overall desire to have more control over page layout and simplified editing, as well as personalization (using Segments), are forcing us to implement the features of Widget Pages (and Layout Templates) in Content Pages. So far, Page Fragment Sections (as #orithena suggested) are giving us a path forward.
Now, we're developing for 7.2. 7.3 seems to be taking this concept even further, with the afformentioned drop zones, nested row layouts, and Master Pages.
I am new to TYPO3 and have trouble understanding the general relation between extensions and the backend of TYPO3.
For example, is it true that the goal of making an extension is to be able add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
For example if I wanted to add a carousel to my page, would I make an extension and design it in such a way that I can add it from my backend to the desired page? Or would it make more sense to, for example, put it as a partial and import it to the desired page using fluid (all of this without using the backend and just using code).
Or are both approaches possible and when would you go for the first or the second (or seek out a third approach)?
Sorry if this question is too general/vague. I feel like I do not understand how the backend and the files in my TYPO3 folder communicate to generate the website and that I am using content elements in the backend one time and typing out the elements in HTML the next time without a good reason for it.
I try to bring some light into the dark areas.
Backend This is the admin area of the CMS where in most cases the content is created by editors.
Frontend: How the website looks to a regular visitor
Extension: An extension is custom code, either your own code or by others which extend TYPO3 in one or more ways. The benefit is that you don't change the code of TYPO3 core itself and therefore it can be always updated.
An extension can be used for a lot of things:
- Shipping a site template with all the assets like CSS, JavaScript, HTML template, ..
- Providing custom content elements
- Providing new record types like news or forms
- Improve user experience
So yes, if you want to have a new kind of content elements you need to use an extension:
Search on https://extensions.typo3.org to check if there is already something which fits your needs
Use https://extensions.typo3.org/extension/mask/ (best in combination with https://extensions.typo3.org/extension/mask_export/) or https://extensions.typo3.org/extension/dce/ to make it a lot faster to create content elements
If experienced you can also create a custom content elements without any additional extension but for start I don't recommend that.
One approach to look at this question in a different way might be to differentiate between content created and maintained by editors (the backend users which typically add and maintain content) and parts of the visible webpages created in other ways. For example, the header, footer, menu of a site may be created by a sitepackage extension - this is something the editor (backend user without admin access) typically has no permission to access and that is one of the points of a CMS - the content is editable by someone without technical background. Of course this improves the stability as well because you don't have people fiddling around with things they should not be able to have access to and thus cannot break.
If you want your editors to be able to add (remove, change) content - do it in a way they have access to (typically using content elements).
You are right, the core provides content elements (such as "textmedia"), extensions can extend this by adding other content elements.
For your example with "carousel" you might want to look at the (official) Introduction Package which uses the bootstrap_package which offers a carousel content element. The Installation Guide explains how to setup a TYPO3 installation with "Introduction Package" so you may already be using that.
For example, is it true that the goal of making an extension is to be able to add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
That is one of many, many other possible purposes of an extension. For example, look at the extension "min". It does not provide any content element and there is no visible change for the editor. An extension is just a way to extend the TYPO3 core (while the core itself also consists of extensions).
Introduction of Extensions in TYPO3 Explained
Sitepackage Tutorial
On the google website there an example of a simple GWT appliatoin, following is a link:
http://code.google.com/webtoolkit/doc/1.6/tutorial/create.html
The above application has a host page:StockWatcher.html
and StockWatcher.java is the entry point.
If I wanted to add more html pages to this application, we keep one single host page and the entry point will add different panels depending on which link the user clicked on? In this case, how to know which link the user clicked on? If I create a navigation panel and each link has a request parameter, then after the user clicks on the link, How to get the request parameter?
Are there any tutorials available online on how to create a fully functional application? The one example google provides is too simple.
Thanks so much in advance
You have two options to have multiple page web application using gwt.
1) Use gwt history feature and listen for the history change. In this approach at the initial page load itself browser downloads all the javascripts(Including the widgets which are not useful in current link). Still this can be avoided by using gwt code splitting.
2) Create multiple modules. In this case you have to create multiple html pages and GWT entry points. For each major functionality create a gwt module and link that with [modulename].html file. In this approach browser downloads only particular feature's javascript. Not all the javascripts.
Based on your application requirement you can pick one of the option. IMHO I would suggesst second option.
I have a website that has related pages. They have links that point back and forth to one another but I have no integrated system, nor do I know what that would mean.
What is the minimum code that a group of web pages must have to be considered a Content Management System (CMS). Is it that all the settings are in the database and the pages are generated somehow? Is there some small snippet that all my pages could share that makes them a CMS, database or not?
Thanks. I was also hoping not to have to study a giant CMS to see what makes it a CMS . After maybe a basic understanding I would know what I was looking for.
edit: here's why I ask about code. Whenever I have looked at a CMS, and maybe they aren't all the same, I saw that to develop a module you always had to inherit from certain classes and had some necessary code. I didn't know if there was some magic model that I just don't get that all cms makers understand.
edit: perhaps my question is more about being extendable or pluggable. What would a minimum look like? Is it possible to show that here?
edit: how about this? Is something a CMS if it is not extendable and/or pluggable?
I think this is really impossible to say. We all manage content. The "system" is just whatever mechanism you use to do so(dragging and dropping in Explorer or committing content changes via a SQL query). To say there is a minimum amount of code needed really isn't indicative. What is indicative is how often you find yourself making mistakes and how easy it is for a given user of a given skill level and knowledge to execute the functions in the designed system. That tells you the quality/degree of what you have in place being worthy of being called a "CMS."
Simply put a CMS is an application that allows the user to publish and edit existing web content.
In response to the edit:
A "good" CMS allows of extensibility. By using inheritence you can extend the functionality of a CMS outside of the core components provided. That's the magic.
About Extensibility:
Depending on the language/framework you want to build your CMS with, you can load pages or controls(ASP.NET) using command built into the framework. Typically what is being done is a parent class/interface is being defined that forces an module that is to be developed to follow some given standards:
Public MustInherit Class CMSModule
'Here you will define properties and functions that need to be global to all modules being developed to extend your CMS.
public property ModuleName as string
End Class
public class PlugInFooCMSPage
inherits CMSModule
end class
Then it's just a matter of simply loading a module dynamically in whatever construct a given language/framework provides.
Ultimately, a CMS is a system that lets you manage content, so it needs an user interface that is dedicated to letting you easily create, edit and delete pages on your website.
However, it's fairly usual to expect from a CMS to provide a browser-based WYSIWYG page editor, file uploading, image resizing, url rewriting, page categories and tags, user accounts (editor, moderator, administrator), and some kind of templae system.
Without dragging you into a theoretical explanation of what a CMS is and what it's not, perhaps some tutorials on the building methodology of a CMS will help you better understand.
http://css-tricks.com/php-for-beginners-building-your-first-simple-cms/
http://www.intranetjournal.com/php-cms/
A Content Management System is a System that Manages Content. :)
So if you got many pages that share the same layout, you can create a system that stores the content into a database and when a page is requested, it gets that content, merges it with a template that contains the page header, menu, etc.. and outputs the result.
The basis idea is that you don't want to copy HTML pages, and have to edit hundreds of them when you want to change your layout.
Such a system can be very complex, featuring wysiwyg editors, toolbars, version control, multiple user publishing and much more, but it could be as simple as a single page behind a standard loging, that contains only an input field for the title and a textarea in which you type the html content.