Is it possible to automatically namespace the links in a page (with the pagename), in Dokuwiki?
i.e., If I create a page [[projects]] in the global namespace, and put any further links inside it
e.g. [[project1]], [[project2]]
these pages should automatically be under the 'projects' namespace.
Is this possible (either natively, or through a plugin) ?
I found a workaround which does what I was trying to achieve.
Any link in a page, which is meant as belonging to the subject of that page, I link as follows
[[.subject:]]
This automatically makes it a link to
current_namespace:subject:start
Having changed my landing page of a namespace from 'start' to 'index', I get a behavior close to what I was looking for in the first place, i.e., a link
[[.topic1:]]
in a page
[[project1:index]],
will point to
[[project1:topic1:index]]
Related
I want to build a Web app with SvelteKit with one page listing all items (with potential search query parameters), and then one page for each individual item. If I had to build this the old school way with everything generated in the backend, my paths would be /items/ for a the listing of items, and /items/123 for item 123, etc. That is, to go to the page of item 123, a link will with href="123" will work no matter if you are currently at the index (/items/) or at the page of one particuler item (/items/[id]).
With SvelteKit, if I create files routes/items/index.svelte and routes/items/[id].svelte, then routes/items/index.svelte will have path /items, without a trailing slash, and as a result a link with href="123" will lead to /123, resulting in a "not found" error.
This same link will work however from the page of an individual item, say, /items/456.
This is radically different from what you would have in the traditional HTML model, where a link from /items/ (or /items/index.html) would work the same as a link from /items/[id].html.
Now in svelte.config.js there is a trailingSlash option you can set to always so that routes/items/index.svelte corresponds to path /items/, but then routes/items/[id].svelte has path /items/[id]/ and we have the same problem again: one href value cannot work from both the index and the page of an individual item.
The only way I see right now is to use absolute path, but it's not very composable. My guess is that there is something I am doing wrong.
You're not missing anything - it's not currently possible in SvelteKit to have a trailing slash for some pages but not for others. There is an open GitHub issue you may be interested in that proposes adding additional trailingSlash options. This issue cites the exact problem you described:
The trailingSlash options introduced in #1404 don't make it straightforward to add trailing slashes to index pages but not to leaf pages. For example you might want to have /blog/ and /blog/some-post rather than /blog and /blog-some-post, since that allows the index page to contain relative links.
Until that feature is added, you'll need to use absolute paths.
In Capella, in the descriptions of my model elements, I am using hypertext links towards other elements of the model. When I generate a document with M2Doc, these links are not properly transformed/interpreted.
Example: a Capella hypertext link towards the "Cabin Screen" model element...
<p>Link:</p>
<p>Cabin Screen</p>
... becomes an hypertext link with the following address in the generated Word document:
hlink://11e922f1-192b-43a5-9060-f935c26998a5/
But there is no way to "follow this link":
Resulting link in Word & Impossible navigation
What I need to achieve is to have the original link transformed in a bookmark reference (I have a bookmark for this element somewhere else in my document)
{REF 11e922f1-192b-43a5-9060-f935c26998a5 \h }
I was wondering whether one service allows to automatically transform these links in bookmark references (BookmarkRef)? If not, has this request been raised already?
This replacement depend on the way you are creating your bookmark IDs. If you are using the same way as the sample templates provided with the M2Doc IFE project, you can use the replaceLink() service. This service is only available if you install M2Doc Capella extensions. You can use it like this:
myCapellaElement.description.fromHTMLBodyString().replaceLink(myCapellaElement)
Otherwise you can have a look at the implementation to implement your own version.
Using Diagrams.net (draw.io), I would like to link specific elements to web pages. This is easily accomplished currently by creating a link for the element (say a rectangle).
However, I would like to navigate directly to a specific id bookmark in the HTML page. I cannot seem to get that to work.
For example, if I try to use this syntax (which works in the browser location bar):
https://en.wikipedia.org/wiki/Canada#Geography
I will be taken to the main page:
https://en.wikipedia.org/wiki/Canada
However, the goal is to go to the "Geography" section of this page.
I have also tried the json syntax without any success:
data:action/json,{"actions":[{"open":"https://en.wikipedia.org/wiki/Canada#Geography"}]}
I have also played with different action syntax such as:
data:action/json,{"actions":[{"open":"https://en.wikipedia.org/wiki/Canada"},{"scroll":{"tags":["Geography"]}}]}
Note: I'm using the diagrams.net desktop version 14.1.8.
Thank you for taking the time to read this question.
Paul
On Windows this only seems to work if the browser isn't already open. There is not much we can do to fix this as we're passing the link to the OS.
In my home page I have the following snippet that fetches all blog posts:
var docs = CurrentPage.Children.Where("Visible")
What I don't understand is that Visible is controlled by a property in the document named umbracoNaviHide. Setting it to true on the document excludes the page from the list above.
How is umbracoNaviHide translated to Visible? I have no macros or XSLT (none actually) that is doing anything funny...
umbracoNaviHide is one of umbraco's internal property implementations.
We used to have to check the property explicitly in xslt but nowadays it is used as you are using it here.
Here is a more complete explanation from the Umbraco wiki
The "umbracoNaviHide" is an Umbraco convention for marking nodes which
should not show up in a navigational context. It is normally added (or
inherited) on every Document Type with a Data Type of "True/false".
NOTE: This property is not added by default on new installations,
meaning you need to add it manually
There are a number of other useful properties that everybody should know about:
umbracoSitemapHide
umbracoUrlAlias
umbracoUrlName
umbracoInternalRedirectId
umbracoRedirect
We always insert these properties on a master page doctype so that all other doc types that represent data on web page content nodes inherit them
Wing
I inherited a DNN (6.2.5, upgraded several times from 5.6.2) site and every time I add a new page, multiple instances of several modules (i.e. 3 copies of module A, 3 copies of module B, 1 copy of module C, etc.) appear automatically in the page, as if there were a template specifying them. I don't want them and have to delete them all every time I add a new page, which is a pain. Funny thing is, I have looked in all the *.template files and they are not specified in anywhere.
Does anyone have an idea of where to look to find why these modules appear automatically on adding a new page, despite their not being in any template file?
Thanks.
It's possible that each of them has "Display Module On All Pages" checked in the module settings. When that happens, they are injected implicitly on every page on the site.
Ian Robinson's comment is the root cause with the display issue.
BUT: I wanted to post a separate answer as a warning with more detail on how it works and a word of caution on making a change
You can find the module then "Uncheck" the "Display Module On ALl Pages" option. However, on certain versions of DotNetNuke doing this will remove it from all pages that it was automagically added to. Re-Checking this option will result in the content being added to the COntentPane of all pages, which might be what you want, and could have a major impact on your layout. SO be careful and I strongly recommend a backup of the site/database in case it goes wrong.
In general, this option is VERY scary to use!