Does there exist Plone add-on, or method, for centralized portlet text management?
A site has a set of standard static text portlets which text is updated time to time. The assigment of portlets do not follow any particular rules. For example, the same static text may appear in two different folders.
Could it be possible to centralize the management of this text, so that you can change it in one place and it would be automatically updated across different portlet assignments?
Could reference portlet + rendering hack do this?
Plone 4.1b.
Try looking at collective.portlet.content
You can create content in a reserved, administrative section of your site and have it referenced and rendered site-wide as a portlet. I'm using it in combination with Products.ContentWellPortlets to render header and footer text.
Related
I am new to Umbraco, and just discovered that the Image editor (the one that is included in selectable editors for content rows) does not provide a way to enter a CSS class. This is surprising, considering that it is pretty standard these days to use Bootstrap classes to style images (img-responsive, for example). NOTE: I had planned to add screen shots of this; however, I've been given a message that I cannot do this until I earn 10 something-or-other-points. THIS NOT HELPFUL TO NEW MEMBERS!
While I understand that I can set a class within the Umbraco UI on the containing column div, this is not ideal. I also understand that I could use the Rich Text Editor, but this seems to be overkill for a column that is intended to contain images only.
What I would like to do is modify the existing editor to allow users to enter CSS classes, but I cannot find it.
Has anyone made this modification to your own implementation of Umbraco, and if so, could you guide me to how I could do this?
The image picker just stores the id of the image, it's up to you how you render it, if the classes are the same for all of the images in the column, you can just assign the class in the view/partial that renders the images.
If you want to have different classes for each image, rather than modifying the built in image picker, best practice is to create a new property editor. There is a tutorial on this here: https://our.umbraco.org/documentation/tutorials/Creating-a-Property-Editor/. Modifying the built in one will cause you problems if you ever upgrade Umbraco (your changes will be overwritten). But a custom property editor will be unaffected, and you can also use it on other Umbraco sites that you build!
We are building a Page with dynamic functionality using ASP.NET + Sitecore 7.0.
Is it practical and appropriate use Sitecore templates for:
SQL Stored Procedure Name to be invoked
JavaScript to be invoked
ColumnNames to be used etc (related to coding customization)
Or should these configuration properties remain inside the ASP.NET Project itself?
What is the primary purpose of Data Templates in Sitecore?
Are they for developer customization or customer-level customization?
The purpose of a data template in Sitecore is to define the set of fields for content items which inherit from that template. - Think of a data template as a class and the content items (pages) as instances of that class.
Templates are usually used to define the user-editable content of pages within a site, that being said you can have items to store information which is not managed by regular content editors. The question is where do you draw the line between things which should be put into Sitecore and things which should be a part of the solution. My advice is only put things in Sitecore if they need to be there. If you have to have the ability for editors or admins to configure those settings/properties.
I would say that putting SQL/ColumnNames is probably a bad idea unless you are building some sort of report builder interface in which case it may be essential?
Likewise with placing JavaScript into Sitecore; this can be OK in moderation (e.g. snippets of analytics code which content editors may want control over?). If you're placing whole libraries of JavaScript into Sitecore, you're probably doing it wrong.
One final point to note is findability/re-factorability of code: if you have code spread between Sitecore and your solution, it can make it very difficult to maintain as it is difficult to get a complete overview of code involved.
I find the hardest thing to explain to Plone end users is the concept of having to make a folder, a page and set the folder's default view to a page in order to have nested pages. Is there any reason I shouldn't include a folderish version of a page content type in my product?
there are existing products that provide folderish types that almost behave like pages for the end-user
eg. Products.Richdocument and raptus.article.
personally i prefere raptus.article because of it's concept of components. editors can activate carousels, or image galleries and define which of the contained images are displayed in which component.
in many project i also define custom components eg one for showing addthis integration under the article text if editors turn on the component.
Ulrich Schwarz is right when commenting that using folderish content types as pages brings in extra complexity when it comes to versioning.
the problems in versioning with cmfeditions could most likle be solved by using attributestorage instead of annotationstorage for archetypes fields. (see https://dev.plone.org/ticket/11887)
The simplest was is to compare Plone as a filesystem.
There are discussions/rumors about making all content types folderish, but right now I suggest you to to something folderish only when really needed. The UI of a folderish content is more complex
Keul is right. Compare Plone as a filesystem.
I think also that you don't always have to set a page as the default view of a folder, sometimes you just want to have a list of contents (files, images, pages, etc...).
I am new to Umbraco CMS. I have an existing website which is developed in asp and asp.net.
Now I have requirement to convert this existing website to new website using Umbraco CMS.
The pages available in existing website are almost all static pages..
My question : Is there any way to import these static pages into my Umbraco website.
So that I can skip the manual content creation of these pages in Umbraco.
In short, it depends on how much you need to edit on the original pages and how many pages there are.
If the content is never going to be edited, then you can maybe create most as just normal masterpages (umbraco templates). You can then just add in Navigations and other CMS spec
Or another way of doing it would be to create 1 template and add a big text box to the DocType which you can then paste the HTML into. However this will mean you will end up with loads of HTML in the DB.
If you want to make it a 'true' Umbraco site and use as much of the CMS functionality as possible then there is no really easy way of converting HTML into an Umbraco site.
If the data was in a DB you could use CMSImport and map the old to the new DocType fields, but you would still probably have to do some HTMLTidy work on it before importing.
Depending on the amount of pages, the best and easiest way is usually to just copy and paste in my opinion because it allows you the chance to perform a content audit at the same time and clean up HTML where necessary.
I did this before.
Created a basic template / view with header and footer and main content area.
Then use Screaming Frog (or a similar tool) to crawl the site.
Use the output of the page crawl to make a comma delimited list of Urls
then use this to find each page.
For each page, create an Umbraco page with the name of the url, ie /something-page-name = 'Something Page Name' Use HTML Agility pack to navigate the HTML and pull out key elements such as Title, Description etc and locate the main content by navigating the DOM and literally take the InnerHTML of that section into the content field of the Umrbaco page and save and publish it.
Make sure you allow your content editor in Umbraco to edit all the html elements found in the source page. Ie you may have section or small tags which the editor may not recognise.
I was wondering if someone with Drupal experience could advice what are the best practices in the following situations. I think they are all common tasks for any website that you build.
Display a custom HTML of a certain content type at front-page (e.g., only the link and title).
Should I build a module only for this?
Customize the login form HMTL, including inputs, labels etc, to something very different from the default login block.
Again, another module?
Format the node view of some content types; for example: showing additional fields values. I have some Joomla experience and with it, it's very easy to override the template on your theme.
But with Drupal, it seems HTML is hard-coded on PHP files and there are very few thing that uses templates. Or am I missing something?
You should create a view (from Views module), and for this create display 'block'. This block you can use later on your site. Within your view settings you can choose what and how you will display.
It depends what you would like to put there. If you put just some static text, change theme could be a solution. But still, a bit smelly. What you should do, is to create a module use hook_form_FORM_ID_alter and add both - field to your form, and code to use values which user added.
Change templates for this content type in your custom theme; or use Panels module - here you have nice introduction; or use Display Suite module - which do pretty much the some work as creating a template
html is in php files, but where else can it go? Drupal also has it template overwrite system. The customization of the theme can be usually done using that alone.
As for your questions (there are also other alternative)
load the content type in view/block, display in list format on home page.
create your own theme for css changes. create custom tpl.php for
layout, and div naming etc.
same as above.
It doesn't hurt to create a new module, but generally it's not necessary unless you are going for something like a muti-step form.
You can use both Views & Panels in order to achieve what you've mentioned above.
For instance, Panels gives you the option to override the home page with your own content. This content can be organized with Views.
From drupal.org:
"The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented."
"The Panels module allows a site administrator to create customized layouts for multiple uses. At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout."