CQ: Content centric OR page centric? - content-management-system

I have a query regarding CQ. Your reply will really make the difference to my understanding.
In other CMS like Vignette, content authors create the contents separately (not directly on the page) for ex. products details and then those contents are iterated / processed to display on the page. But in CQ, the scenario is other way round. Authors directly create the content on the page. Now if same content is needed on other page, how will that be re-used ?
Regards,
Ronak

Content can be reused across pages via Reference components. From the docs:
The Reference component lets you reference text in another part of a
CQ based website (within the current instance). The referenced
paragraph will then appear as if it was on the current page. Instead
of referencing a specific paragraph, the path can also be modified to
specify an entire [paragraph-system]...
There are some other techniques for sharing content and reference data across pages, including inheritance and "data components," described in this SO Q&A.

Related

How can i edit an existing Typo3 Extension (Backend Configuration Page)?

i want to edit an existing Typo3 Backend configuration page.
I want to edit a configuration page like this here:
Where can i edit the extensions backend?
To be more clear: where can i change the edit page that an editor can use to change content.
Can someone give me a hint to the right directory or file in generall?
I'm using Typo3-7.6
Thanks
Sorry, can't manage to put all questions in an unformatted comment.
there are a lot of questions, as you are not clear what you want. Maybe that is a problem of the correct words, the vocabluary, but in TYPO3 we have some fix terms for specific object. And I think you do not handle these terms according to the TYPO3 community.
let's define some terms:
first the concept of TYPO3:
all data is stored in record of differnt database tables. All records are organized with some fields and teh main field is uid, the unique ID.
the main table is pages according to the folders of your disk. those folders can contain other records (like files). (nearly) each record in TYPO3 has a relation to a pagesrecord ina field named pid. even pagesrecords have this field and so they build a tree of pages and subpages.
There is one special page, which is no real page: the page with the ' uid' zero. As there is no real pagesrecord with the uidzero, there are other records with are stored in that page by having a pid zero. for example the start of your page tree is anchored in page zero, or global records like languages, user, storages.
Aside of being the anchor to other records, the pagesrecords have information themself. (page name, kind of page, a teaser image, SEO-information, visibility, accessibility, ...)
your screenshot looks like a content record (normaly in the table tt_content), in the lower right corner there you can see the table name and the uidthe the currently edited record.
'Backend': with backend we name the view to the data where an editor can change the content of the website. The real website is the frontend. This can be seen by everyone without the need to login in the backend (you might have access-restriccted areas of your website which need a login, but that still is 'frontend' as there is no option to edit content.
in the backend the editor might be restricted what he can access and what he can modify. An adminuser has no restriction (up until version 9 where the role of a maintainer occured to manage more general and basic options)
so we have not a single 'backend configuration page' but multiple places where we could configure special aspects of the website.
also there is no special 'extension backend'. we have global extension configuration and records belonging to an extension. (And an extension can enhance existing records with additional fields.)
Please be more specific what you want to change

internal links in Lektor's markdown blocks

I want to build a website, maybe similar to a movie database, where every page has, say, actors, director, year (it seems that Lektor can deal very well with such structured metadata), and I am thinking about how to realize internal links between pages on that site.
Say I have a text such as
just like in [his previous movie](link), he shows again ...
then I guess I could use the absolute path of the linked page as link target, but that makes me very inflexible with respect to changing URL structure. Can I somehow just use the ID of the target content?
Or, better yet, can I somehow automatically obtain the title of the linked page?
just like in his previous movie <<link:title>>, he shows again ...
Can I use the standard Markdown blocks for that or would I have to add some handcrafted database lookup logic?
if some contents will be changed in future. I think you can use the databag feature to implement it. you just modify the databg in case changed is need.

Repeatable data content in umbraco

I am just wondering is there any plugin to create dynamic content for a page i.e something similar to a data repeaters in .net. To make it simple it should be a section that should contains 5 to 6 fields/property like
heading
heading 2
image
content - rich text editor
info
This must be in repeatable control so that the editor can add any number of these section a page and all these should be displayed in a single page.
Is there a plugin for the above functionality or what is the best way to achieve this.Any help would be greatly appreciated.
Thanks
Aneesh
You can achieve this without any plugins.
Create your repeatable section (containing the relevant fields) as a document type, and then use the multi-node picker in another document type to select one or many of the sections.
So for example, I could have a FAQs page (which uses a document type called "FAQs Page"), and I want to be able to add multiple question and answers to this page. I could set up a document type called "Question". This will contain two fields: Question and Answer.
On the "FAQs Page" document type, I would add a multi-node picker field called "Questions". This way, an author could select multiple "Question" nodes to appear on the FAQs page.
You would obviously need the code to output this, and also you would create a data type that inherited from multi-node picker, so that you could limit the selection to only Question nodes.
There is also the Repeatable Custom Content datatype which works well but does not support all data types. But it does support all the ones you need for your stated purpose (textstring, media picker, richtext area, etc).
You can find it here: http://our.umbraco.org/projects/backoffice-extensions/repeatable-custom-content I've used it a few times and it works really well in certain situations (e.g. where the items will not be shared across different pages of your site).
If you are sharing content components across multiple pages then #Digbyswift's solution is perfect.
I've always Digbyswifts method, but whilst looking for an alternate solution tonight I found this plugin, which is excellent for those situations where creating lots of widget nodes feels like overkill. It's licensed but the free older version is also available.
http://inaboxdesign.dk/blog/widget-builder-for-umbraco/

How page activation take place for pages containing inherited component i.e components dropped in iparsys?

I have created a website structure in CQ5 WCM. I have created one template and defined few parsys and iparsys into its page level component. After this i have created one page and several more pages under it. Now my question is if make changes to the iparsys component and activate it, would all the pages inheriting it will also get activated or i need to activate all the pages individually?
Yes, all the nested pages would pick-up the change. Look at it as a "computed" reference - your page containing the original content gets replicated to the publish instance's repository, and all other pages compute their HTML based on that indirectly-referred content.
Dispatcher's cache however is another beast - make sure you're invalidating whole site's cache, rather than just the page you activated.

How can I use the Inversion of Control concept in Sitecore to get non-page items to display themselves?

I have a number of non-page content items that are used as "callouts" on the side of pages throughout my website that I am building in Sitecore. Ideally I would like to be able to define the presentation information for these callouts independently. Then when a CMS author selects callouts for a particular page in the site, they know how to display themselves. I read an excellent blog post about how to do this here: http://www.awareweb.com/AwareBlog/InversionControl2.aspx. I used the first method that he describes in the post.
However my implementation of that code doesn't completely work. It seems to get the correct rendering and it iterates properly through the selected non-page callout items. But when it displays them on the page it seems like the callout items are still using Sitecore.Context.Item as their source item and not the source item that was passed in to them via the strDataSource variable as seen in the example code.
Do I have to do anything special in the code behind for the sublayouts for the callouts to tell them not to use Sitecore.Context.Item and instead to use the source item that was passed in? Otherwise I can't figure out why it's not working. Any ideas?
Thanks,
Corey
Setting the DataSource in a sublayout doesn't explicitly set the Context.Item to a different value, it just sets a property in a sublayout that it can use itself.
Rather than write up the solution again, John West's blog already covers this subject here, so I'd recommend you read that - http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2010/11/How-to-Apply-Data-Sources-to-Sitecore-ASPNET-Presentation-Components.aspx
I would recommend using the SublayoutParameterHelper Shared Source library which provides a Helper and a base class to use with your sublayouts for accessing the Item represented by an ID set in the DataSource; John also cites this library in his blog post.