I'd like to have a hierarchical URL structure in my site. Something on these lines:
tutorials
javascript
jquery
There should be a page at each level (tutorials, tutorials/javascript and tutorials/javascript/jquery). Obviously, using Taxonomies would help me organize my content in this manner, but how do I get Autoroute URLs generated for this scenario?
Bertrand Le Roy made a comment on this SO answer about using taxonomy terms as pages but it still doesn't seem to create the right URL structure for me. Am I missing something? Is there something specific I need to configure or enable to make this happen?
Are there any other approaches I can look at?
I was thinking of specifying the default route as something like {Content.Fields.Page.TaxonomyName}. It appears that this isn't really possible right now according to this bug report.
Here's an approach that seems to work without having to use taxonomies:
I added a Content Picker field called ParentPage to the Page content type and updated the Page's Autoroute default to
{Content.Fields.Page.ParentPage.Content.Path}/{Content.Slug}
Now in each page I get to pick what the parent page is and the URL is constructed how I expect it. From what I remember of working with WordPress, I think this is pretty close to how it allows you to do this parent page thing, too.
Related
I've never used Drupal before (development or managing content). I was asked to extend the admin content page to have a filter and simply don't know enough to get moving quickly.
Can anyone tell me if adding a search by text filter in the admin content area requires code or is there a CMS feature like adding a node for this task.
If code is required, is there something like a hook for this area? Not sure where to start. I will be investigating on my own but pointers to get me oriented to Drupal would help.
By default Drupal provides search mechanism ready to use. But there are also additional module which can improve search experience. You don't need any coding to use that search. You already have search form block ready to use.
Go to Structure -> Blocks and find block called "Search form". Now all you have to do is to put that block in some region and it will appear on front-end. Of course if it's not already styled by your theme it may be needed to put some extra CSS to make it look nice. There are also some template files which you can override and put some your HTML if you need.
There's also template file for search results page (which of course will work out of box also).
You may also need to create new block region if you want to place your form at some specific place, not covered by any existing region defined by your theme (easy thing to do!).
See https://drupal.stackexchange.com/q/30633/101329, the "Admin Views" module lets you configure the search form as you like.
We are using Liferay as a classic CMS meaning that we compose pages using web content articles. There is an issue with Liferay's internal search I could not yet find a proper answer for:
Because web content articles are pretty much only building blocks for pages we don't want the search to show them as distinct items. The user should only get a list of pages that contain their search keywords, including all the articles put onto this page.
At the moment we can see two different approaches and both come with certain problems we could not solve yet:
Idea 1
We modify the journal indexer and try to obtain all URLs of the pages (how?) where the article has been placed on. Then we add them to the document to be indexed. In the search result we then can access the URLs and collect them. In the end we make sure every URL is only shown once.
Idea 2
At some point Liferay renders the entire page before sending it to the browser. If we somehow could put an indexer there, we could index the entire page. We then could limit the search to the special "page documents". Getting the fully rendered page would be the main issue here, because either we would have to run a crawler to frequently trigger this indexing or we would need to find a way to trigger page rendering from within an indexer or something like that.
I have been carrying this problem around for quite a while now and still could not find an idea good enough to spend time trying it out. If anyone of you has some input on those two ideas or maybe an entirely different approach, I would be extremely grateful.
I'll just answer myself, because by now we found a suitable solution to solve our problem:
In addition to the default search portlet there is also a "Web Content Search Portlet" shipped with Liferay. It seems to have been part of Liferay for quite a while now, but it's somewhat hard to find, because there is hardly any documentation for it (I only found the Liferay wiki page, which isn't really anything at all). It searches only within web content articles and shows links to the pages rather than just a link an isolated view of the article. It has much less configuration options than the default search portlet, however. Pretty much all it allows to change is whether articles actually have to be placed on at least one page to show up in the results.
So there is no need for any kind of custom indexer or any other "hack"...all we need to do is use the correct portlet. We will only need to write a hook that changes the appearance of the result page.
What you ask is interesting but your ideas are on the wrong direction.
Specially idea 2 it's particulary wrong because you cannot do indexing work meanwhile a page is rendered. Think about performace only.
In Liferay pages and assets are not directly linked: pages have portlets and portlets display assets (web content and more).
Liferay indexing refers and scans assets content, not refers the display result of the assets. Think about permission: the same page can display different contents depends on the user who looks.
bye
I need to divide long content to sub-pages.
Rule for dividing: Heading1 (H1)
Cms-system: MODX Evolution
As far as i know, there is nothing in modx to use for this kind of problem.
I probably got to do this manually anyway, but i still would like to know if there is a way to do this in MODX Evo / Revo.
Edit:
I need to do this in MODX; sub-pages got to be actual subpages, and original page becomes to container.
Navigation will be done with wayfinder.
Edit2:
All done.. manually. Question still open, though.
This is not possible out of the box and I don't know of any extra that archieves what you want. You would have to write a plugin that acts everytime you save a resource and split up the content, create/delete sibling resources as needed etc. Sounds like a lot of work for what you want to archieve to me.
I suppose you have a look at the MIGX extra. It provides you with a TV with the possibility to store an indefinite amount of distinct TV content sets. Have a look at the documentation and Mark Hamstra's tutorial (with screenshots) to see how it is done. You should define one MIGX entry to consist of a text field for the <h1> and a rich text field for the content of the "subpage".
Afterwards, you can use form customization to hide the original content field and display your MIGX Tv instead.
I think, this is a much easier way to archieve, what you want, and can't think of any way, where you would benefit from actual subpages.
Edit: Sorry, I just recognized that you were asking about Evolution, not Revolution. My solution would work in Revo, but I don't think there's something like MIGX for Evo. Sorry, my mistake.
not 'out of the box' you will have to run your content through a snippet to parse it into separate divs or something that you can run some javascript on to possibly 'tab' the content.
If you need to show the 'subpages' in your navigation, you will probably have to use the gatResources extra to parse your content ~ which will be very expensive on resource usage.
You can (depending on how you're using the tree) just create actual sub resources under the parent resource, using Ditto or Wayfinder to build navigation for it.
If you can't use the tree like that (though from your description I think you can), you could also set up a number of template variables ("content1", "content2", "content3" etc) and show that with a simple snippet or so.
I am using drupal 6. I created a content type called 'Mobile' using CCK and added content for it. I want to change the way the content is displayed to the user. How do i do this.
Currently looks like this. I want to play around with the fields in this only for this content type. How do i do it and can i do some work around with the form of the mobile content type.
Questions like "teach me how to walk"
You need to learn Drupal theming system. you can get general idea http://drupal.org/node/17565 and by looking at node.tpl.php from your theme - that's for the beginning.
P.S: as far as I see from your other questions, you didn't tried to search in the web for this.
I have seen many somewhat similar questions, but nothing quite what I'm looking for. So at the risk of being told this is a duplicate... here it goes.
I've found that there are times I have a node that simply contains content that will be displayed somewhere else, but shouldn't be viewed directly. That is, no one should ever go to node/1234, but the content in node 1234 should be displayed somewhere else.
For example, I create an about page with tabbed content using views. So there are "About Me", "About Us" and "About Them" pages. All of these are displayed in a single page with tabs using Views. So I don't want people to get directly to the "About Us" node because then they wouldn't see the tabs for the other pages. At the same time, I don't want Google giving people a direct link to this node, I want to limit access so users can only get to it through the View (i.e., the tab).
So I need to restrict access to the node, remove it from the Drupal search results, and make sure Google doesn't pick up on it. Any suggestions?
---- Note ----
I've accepted the answer from mingos (thanks btw) because even though it's not a full answer / solution, it gave me some good things to think about. Additional answers are still welcome.
In Drupal 7 you can use: http://drupal.org/project/internal_nodes
Description: Some content/nodes should never be viewed directly; only visible be through something else such as Views or Panels. This module denies access to node/[nid] URLs while allowing the content to stay published and otherwise viewable.
Full disclosure: I am the creator and co-maintainer of Internal Nodes. I found this question while searching to see how the module could be found on Google.
Tough one.
If you want to have many nodes like this and do the "displaying elsewhere" dynamically, I can't think of anything right now (at 2:20 AM I rarely can).
If there is onne such page (or very few), I'd restrict access to it by any available means (Permissions, Nodeaccess, Content Access, TAC, whatever) and then create special themes for the pages where the restricted content should be displayed. The themes would contain database queries, fetching content from the restricted nodes.
Other possibility might include creating a special theme for the hidden nodes in question (perhaps all belonging to the same content type?). Make full node display nothing (or a message saying the access is restricted) and add a ROBOTS meta tag asking Google not to index the page. Make the teaser view available though - you can display it freely inside a view, but since /node/1234 is the FULL view, the actual content will be unavailable here.
Dunno if this solves your problem, hope it helps at least a bit.
I found this page after running into this same problem.
What I found worked for me might be part of the answer you need:
Take a look at the Page Manager Redirect Module http://drupal.org/project/page_manager_redirect . I just started playing with it.
It uses the Page Manager module of CTools to redirect one page to another. What makes this most powerful is that Page Manager uses Contexts. So, if you want to redirect all pages of a particular content type, you can do so.
I just started to use it (instead of Taxonomy Redirect and Path Redirect) to redirect (301 response code) my taxonomy terms for a particular vocabulary to particular nodes.
In your instance, you should be able to use contexts to filter for specific pages.
Of course this doesn't solve the problem of these nodes coming up in search results.
There is also another module Rabbit Hole which has a similar functionality like Internal Nodes but works for all entities, not only nodes.
I am having the same problem, and are currently thinking of the following solution where all the content of a node is to be displayed to certain users (permission based):
- unpublish node
- create a new published checkbox
- create a view with fields that shows alle the content
Haven't tested it thoroughly yet, but it seems to work.
The node is to be displayed to the creator (only one in permission 1), some of it to permission 2 and all of it to permission 3.
Any comments on this solution.
I assume this will also exclude it from search, but permission 2 and 3 needs to be able to search it. Still haven't figured that one out.
I used Rules module with an "entity is of bundle" and the built-in "Page redirect" action.
There is a really easy way to do this if you only want to show a content type through a view.
create a content type as and make it unpublished.
create a view and on the filter option set the filter to "Content: Published (No)"
the view will give anon users access to the content through the view but they won't have access to the unpublished content at the direct link to the content.