I've made a change to what I thought was the main default template page in a hosted version of Sharepoint 2007, but the search page hasn't picked up the change.
Can someone please either give me a list of all the default page files, or tell me how to identify them? It's really important that I add a JS script call across all pages everywhere on the site.
Thanks!
Point of clarification: for now, I'm just trying to include a jQuery reference. I really don't think I'm trying to do anything complicated or unusual - I just want this include to be be global across all pages by default. I've modified /_catalogs/masterpage/default.master with:
<HEAD runat="server">
<script src="/Global%20Site%20Files/jq1.4.2.js" type="text/javascript"></script>
EDIT
I just did a search of the source code for a statically defined meta-tag and found that the default.master I altered is in fact the only file in the search results!!! This means, as far as I understand, that my jQuery include should have worked! I'm more confused than ever...
Hi What i can see is the way you are refrencing is wrong you should use full Qualified URL for
src attribute in script tag currently you are using relative path that might be a cause of error
Turns out that the issue is not a question of multiple page templates or master files. The search results page (which is the primary page in question) does not use the default.master file. Moreover, even as an administrator, I don't have the ability to edit the search results page.
In the end, it looks as though I was looking for what I thought was a solution, but was really just a red herring. I'm going to repost a more specific question to my problem.
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
We have inherited a web application in Lotus Notes in which we are trying to introduce XPages (we are new to both Lotus Notes and XPages, please forgive our inexperience).
We have a view that we are trying to swap with an XPage. The current view is called like this from the application menu (the view is being called from a form):
<a href="FRVWFACSPROVXEstadoAno?openform" target="ifat">
And we are trying to call the XPage like this:
<a href="Prueba.xsp" target="ifat">
For some reason, the link is expanded at runtime to this:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/Prueba.xsp
The page is not found because the database name is in uppercase (in fact, if we change TBS_AGORA_FIN.NSF to TBS_AGORA_FIN.nsf, it works). It is also strange that the current link is in uppercase, too, but nevertheless it works:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/FRVWFACSPROVXEstadoAno?openform
We would like to know why the database is in uppercase. Could the Domino server be doing this?
I'm going to assume based on your question that you're calling your link from a form or page that's rendering as HTML. Since it's a relative link, you're probably navigating to it through a link that includes uppercase for the .NSF in the title. This can be solved either by fixing all your links so that .nsf is lowercase, or by calculating your XPages links better.
To do the latter, I usually do the following for XPage Links:
Link
Where XPage.xsp is the name of my xpage and the value of the Computed Text is:
"/" + #WebDbName + "/"
This will calculate the link based on what Notes wants to refer to the database as.
Hope this helps.
What OS is the server running on? If the server is running on Linux/Unix then you need to be aware that directories and filenames are case sensitive. The tricky thing, however, is that once they have been opened they are cached by the server - and will work without being case sensitive (for some time...). This can be really tricky to troubleshoot if you are not aware of the cause ;-)
I agree with the possible solution suggested by Aaron, however, it really should not be necessary... It should be better to leave that to the server.
If you are running on a *nix OS then ensuring that all paths and filenames are in the same case (I use lowercase) is a good practice...
/John
I don't know a huge amount about htacess and modrewrite, so I find myself in yet another predicament approaching this new zone for myself.
I will seperate my Inquiries over 2 different questions to allow answers to be on-topic and better targetted to users searching for solutions to their own questions.
This is the second of those 2 inquiries;
I have the following in my htaccess file;
RewriteRule ^install/([a-zA-Z0-9]+)/$ index.php?module=faq&page=howto&program=$1
The concept is that install/abcd/ would call index.php?module=faq&page=howto&program=abcd
That works. It pulls the content, matches it and shows what it is meant to. I have used server variables to show me what is being simulated and it matches up.
However the CSS and images on the page are being stripped as they are relative to the document, not statically assigned.
I am only using htaccess (For Now I guess?) for one solution, with the intention to soon impliment another fairly soon. The intention is to offer our customers easy to read URL's for support purposes, but not rewriting the entire site. SEO isnt a major issue as our site is only to be used by those it is intended for as opposed to a wide audience.
Other than statically assigning css, JS and image files, is there a way to fix this issue so that the page is displayed styled and with the javascript in tact?
Thanks for your help, I hope the question was understandable and as always I appreciate the time you guys take to help us all!
We need to either make the css links absolute (starts with a /) or add a base for all our relative links by adding an extra attribute to the header:
<base href="/">
This would mean that you we start with the subdirectory of /test/. so instead of the css being;
http://domain.com/install/abcd/style.css
It would instead
http://domain.com/style.css
This is the problem I was having due to all my CSS and JS being included relativly (Allowing me to change the directory my script is in).
The above adjustment has in fact fixed my original problem, however without the use of PHP may open up an issue for some who want to be able to deploy the scripts and allow them to be fully dynamic without having to edit the base. Good luck!
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.