I'm writing an app that uses the GitLab API, and I'd like to list the pages in the wiki. I can do something like http://gitlab/username/project/wikis/home.md to get the source of an individual file, and see all pages with http://gitlab/username/project/wikis/pages, but I can't do http://gitlab/username/project/wikis/pages.md due to a 500 error.
Is there a way I can retrieve the list of files in the wiki?
So there's now a GitLab Wiki API available which does everything I need:
https://docs.gitlab.com/ce/api/wikis.html
It can be used something like this:
https://gitlab.example.com/api/v4/projects/:project_id/wikis?with_content=1&private_token=yourtokenhere
Note; if this list is to facilitate a TOC (Table of content) for navigation purpose, you now have GitLab 13.5 (October 2020), which comes with:
Deep-level wiki navigation
In GitLab 13.5, along with the release of group wikis, we have another huge improvement in how to view and navigate the file structure of a wiki.
Currently, it’s very difficult to see where you are or understand the structure of a wiki if you have multiple folder levels. This makes it difficult to navigate, find pages, and mentally map your information.
With this release, we’ve introduced wiki deep nesting in the sidebar so you can see all of your pages and navigate accordingly.
See Documentation and Issue.
Possibly not what you wanted (and a bit late) but if you have modified your Sidebar (i.e. _sidebar) you can make a copy of it and then delete it.
You could also add link:pages[List all pages]
to your home page. That might avoid, somehow, the 500 you get from pages.md
Related
So in gitlab you can use [[_TOC_]] to display a table of contents for the current page - which works on headings.
But I want to have a heirachy in my wiki like:
<home-url>/Project1
<home-url>/Project1/Tools
<home-url>/Project1/Debugging
<home-url>/Project1/Debugging/GDB
<home-url>/Project1/Debugging/MSVS
Such that in the Project1 page I get an index (links) to each section similar to the table of contents layyout - e.g.:
- Tools
- Debugging
- GDB
- MSVS
I can do this manually, but that's a pain to maintain. Is there some automatic tool to do this for me like TOC?
The TOC support steams from issue 2494, and was implemented in issue 21901, which gave us the Markdown [[_TOC_]] syntax.
Even the current request to support [TOC] instead (issue 14193) does not mention any layout option to include a hierarchical display.
As mentioned in the first issue:
If you need more control, you can open a new issue at https://gitlab.com/gitlab-org/gitlab/issues and upvote it.
For example: issue 215988: "Add Gollum depth level support for Wikis Table of Contents [[_TOC_]]"
Having the ability to limit a [[TOC]] depth is useful to show a more synthetic view of a page while keeping its deeply nested structure.
See also GitLab 15.3 "Visualize table of contents in the WYSIWYG wiki editor".
Thanks to VonC for the actual answer - i.e. there is not such a feature at the moment (well, not quite as I want it) - but there is the side bar in gitlab wiki which shows you the pages within your wiki.
If you structure you wiki into folders and subfolders then you can navigate with this side bar "tree". Its not collapseable - so its just a bog-roll off text, but it is indented to aid navigation.
It works well enough for simple wikis with a few dozen pages - but probably if there are hundreds of pages it might start to breakdown - at that point you might want to break your wiki up into several wikis with a top-level links page or some such.
Here is (a crap) picture - it was the best I could see on google without looking too hard see here
You get this for free (without doing anything) so its decent for most cases.
I would like your support in order to get some help in customizing the search component in Liferay DXP 7.0 Enterprise.
I have reviewed all the available documentation but although I have found many articles about the issue, the step by step is not so clear for me.
I need to customize the native search component:
Change the input component to give suggestions while the user is typing the search terms
Change the search result page look and feel.
Anyone ever implemented anything like this?
I know this is an old thread, but StackOverflow keeps showing it as the first open question when I am navigation this particular tag...So here are some pointers, as this is a pretty broad topic...
The search is really confusing for adding customization. Mainly you have to provide some of them as contributors, using the asset framework. following the regular steps to build an asset for the asset publisher you will hit the best place to find documentation about the search contributors.
About the search page, best is to create a new page, besides the default one for extra freedom. As long you use the friendly URL /search it will a basic replacement. In this page you can add everything you need, except for translations for the friendly URL - not great. Another option is to keep the default page (which will not be visible in the build area 7.1.x, but you can edit after you search something and fall inside it).
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
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.
I've got two sharepoint site collections. Now i have a Wiki in one and i want to move it to te second one. I did the move with creating a template and import it into the new one. The problem í've got now is the links. The Wiki links are refering to the old location.
Does any one a solution for this?
The problem with the SharePoint Wiki system is that it resolves the Wiki style links [[link]] at save time to absolute links to the page in the Wiki page list.
I think you will need to write some code that loops through and updates the text in your Wiki pages. Use the WSS object model to to find and update each list item that represents a Wiki page.
You can also have a look at www.sharepointproducts.com where you can download a free version of a tool (CopyMove for SharePoint) that can also move Wiki pages across site collections. It does, however, not update the links on the Wiki pages. But it is my tool - so I will give it some thought whether to add support for this. It is not the first time I have heard about this problem.