Mkdocs hyperlink not working in static pages - mkdocs

I'm trying to build a documentation with mkdocs.
The problem is that the links in the static created pages are not working.
Instead of going to [folder]/index.html I'm presented with the following page like in the following image
The problem however doesn't exist when i try mkdocs serve

Set the use_directory_urls setting to false in your mkdocs.yml config file:
use_directory_urls: false
The documentation explains:
This setting controls the style used for linking to pages within the
documentation.
The following table demonstrates how the URLs used on the site differ
when setting use_directory_urls to true or false.
Source file | Generated HTML | use_directory_urls: true | use_directory_urls: false
------------ | -------------------- | ------------------------ | ------------------------
index.md | index.html | / | /index.html
api-guide.md | api-guide/index.html | /api-guide/ | /api-guide/index.html
about.md | about/index.html | /about/ | /about/index.html
The default style of use_directory_urls: true creates more user
friendly URLs, and is usually what you'll want to use.
The alternate style can occasionally be useful if you want your
documentation to remain properly linked when opening pages directly
from the file system, because it create links that point directly to
the target file rather than the target
directory.
The last paragraph is the key to why this makes a difference.

Related

MediaWiki different site title for different namespaces

I have found that there is a special MediaWiki page, MediaWiki:Pagetitle, in which I can set the site name to be displayed for all pages between <title> tags (default: $1 - Wiki's_name). I would like to have different messages depending on the namespace, for example:
for the main namespace a longer message: $1 - Wiki's_name, wiki's_subtitle
for files the default: $1 - Wiki's_name
This is because files usually have a longer name and everything becomes too long.
Is it possible to do this, perhaps with a condition, or doing this from another place rather than using MediaWiki:Pagetitle?
Set MediaWiki:Pagetitle to this:
{{#switch: {{NAMESPACENUMBER}}
| 6 = $1 - Wiki's_name
| $1 - Wiki's_name, wiki's_subtitle
}}
provided that ParserFunctions extension is installed.
Six is the number of File: namespace.

DWG Sheet Combination failing on AutoDesk Forge

We are using Forge to import a STEP file into the modelspace of an output.DWG. Then a DLL combines modelspace geometry of several DWG files into several layout/paperspace of a single DWG. This sheet combination was working perfectly until just recently, when the combination process completely stopped happening.
Has something in Forge changed recently that we're not aware of? Updates/patches, or something like that which could have caused this issue?
This is an issue for a production application and is considered an outage at this point, and is very time-sensitive.
Edit: Here are some differences we noticed between the log files generated by this process. In this first section, the verbiage being written by AutoCAD has changed slightly during an extraction process:
[08/01/2019 17:15:35] End downloading https://.... 1556909 bytes have been unpacked to folder T:\Aces\Jobs\a43e5ca7faaa4db8b5374aaef71b36d3\cadlayouts.
[08/19/2019 17:25:53] End downloading file https://.... 1771363 bytes have been written to T:\Aces\Jobs\d12f3bed13b84d29b31226222e3cf3c9\cadlayouts.
In the log from 8/19, all lines logged in between:
Start AutoCAD Core Engine standard output dump.
And:
End AutoCAD Core Engine standard output dump.
Are being written twice, but this did not happen in the log file from August 1st or any of the logs before that date.
Edit 2:
Yesterday we used the .NET DirectoryInfo class to pull all directories into one list and all files into another and write them all to the log. The cadlayouts entity that should be recognized as a directory (because it's a zip that is extracted by Forge) is instead listed as a file. Our process runs a Directory.Exists() check before the work item merges the DWGs into the output, and this call returns false for the cadlayouts folder, bypassing our combination logic. How can the Forge zip extraction process be working correctly if the resulting entity on the file system is not considered a directory?
It sounds like you have an input argument that is a zip and you expect it to be unzipped into a folder. Please look row 4 in the table below. I suspect that this is what you are experiencing. There WAS a recent change here: we used to look at downloaded bits and unconditionally uncompressed if we found a zip header. (i.e. we acted identically for row 3 and row 4). We now only do this if you ask us to do it.
EDIT: The first column in the table is the value of the zip attribute of Activity's parameters while the second column is the pathInzip attribute of Workitem's arguments.
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| # | Activity | Workitem | Arg direction | Comments |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1 | zip==true | pathInZip!=null | input | Zip is uncompressed to the folder specified in localname. Any path reference to this argument will expand to full path of pathInZip. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 2 | zip==false | pathInZip!=null | input | Zip is uncompressed to the folder specified in localname. Any path reference to this argument will expand to full path of pathInZip. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 3 | zip==true | pathInZip==null | input | If zip is provided then it is uncompressed to the folder specified in localname. Any path reference to this argument will expand to full path of localName. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 4 | zip==false | pathInZip==null | input | If zip is provided then it is left compressed. Any variable referencing this argument will expand to full path of localName. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 5 | zip==true | pathInZip!=null | output | Workitem will be rejected. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 6 | zip==false | pathInZip!=null | output | Workitem will be rejected. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 7 | zip==true | pathInZip==null | output | Output(s) at localName will be zipped if localName is a folder. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 8 | zip==false | pathInZip==null | output | Output at localName will not be zipped. |
+---+------------+-----------------+---------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------+

how to handle import of files using Jinja that don't exist

In Salt Pillars I need to load the contents of a file into a Jinja variable. If the file doesn't exist Jinja throws an error (TemplateNotFound:...)
I have some folders (Company A, Company B, etc) in my Pillars that may or may not contain a file called Default.sls. If the file exists - it will be loaded into a variable. The problem arises when the file doesn't exist - in this case Jinja throws a TemplateNotFound exception.
My Pillar folder looks something like this:
pillar
|
|-Default.sls
|
|-Company A
| |-Default.sls <-- This could be missing
| |-init.sls
| |-prod.sls
| |-test.sls
| |-etc...
|
|-Company B
| |-Default.sls <-- This could be missing
| |-init.sls
| |-prod.sls
| |-test.sls
| |-etc...
|
|-Company C
|...
I have not found a good way to solve this. I have been using the following code (info: tpldir contains the name of the current foldername the sls file (in this case init.sls) is located in):
{{Company x}}/init.sls
----------------------
{% from tpldir + '/default.sls' import companyDefaultX with context %}
xx:
companyDefault: {{ companyDefaultX | yaml }}
In order to check if the file exists - I have been using:
salt['file.file_exists']('/srv/pillar/' + tpldir + "/default.sls")
This works fine as long as file_roots defined in Salt master config is setup as default. We have now moved to using gitfs - now the above use of file.file_exists obviously does not work since the files no longer is located on the salt master in /srv/pillar/...!
The reason for the above code is that it is a way of making a Tiering between default- and companyDefault configurations. First default (Defalt.sls) is read, then {{Company X}}/Default.sls is merged into/onto default. Thirdly environment (prod.sls, test.sls, etc) is merged with the new default...
Bonus question: How can I loop over files in a folder without using:
salt['file.readdir']('/srv/pillar/' + tpldir)
As this is the same problem (/srv/pillar)...
I have found a solution to the above. Only way is to use include in combination with "ignore missing":
{%- load_yaml as customerDefaultX %}
{% include tpldir + '/default.sls' ignore missing with context %}
{%- endload %}
The customerDefaultX variable will now contain the content of the {{Company X}}/default.sls file OR None if it doesn't exist...
Original bonus question is still open though ;-)

How to set up system properties per user?

We're upgrading to play 2.3.5 and it's the first time I've used the activator.
If I run the activator headless, I can still pass in a bunch of command line flags, but if I try out the new UI I don't know how to pass in overrides for my developer setup (which are different from other developers). I don't see a way to set unique java properties in a meta activator config that we would exclude from version control.
-Dlogger.file=./conf/my-special-logger.xml -Dprop1=special -Dconfig.file=./conf/my-special-file.conf
I can symlink my-special-file.conf to application.conf and get most of what I want. It's not really an ideal solution and if I leave the symlink in place during bundling, the packager blows up.
[error] (*:stage) Duplicate mappings:
[error] ./my-project/target/universal/stage/conf/my-special-file.conf
[error] from
[error] ./my-project/conf/application.conf
[error] ./my-project/conf/my-special-file.conf
Typesafe Activator uses ~/.activator/activatorconfig.txt as a means of setting Java system properties.
With the following ~/.activator/activatorconfig.txt:
-Dhello=world
I could query for the hello property in the shell:
[play-new-app] $ eval sys.props("hello")
[info] ans: String = world
As a reference - this is for Play 2.3.5:
[play-new-app] $ dependencies
...
+------------------------------------------------------------+------------------------------------------------------------+--------------------------------------------+
| Module | Required by | Note |
+------------------------------------------------------------+------------------------------------------------------------+--------------------------------------------+
...
+------------------------------------------------------------+------------------------------------------------------------+--------------------------------------------+
| com.typesafe.play:play_2.11:2.3.5 | com.typesafe.play:play-ws_2.11:2.3.5 | As play_2.11-2.3.5.jar |
| | com.typesafe.play:play-jdbc_2.11:2.3.5 | |
| | play-new-app:play-new-app_2.11:1.0-SNAPSHOT | |
| | com.typesafe.play:play-cache_2.11:2.3.5 | |
+------------------------------------------------------------+------------------------------------------------------------+--------------------------------------------+

PHPStorm exclude files by mask from indexing

I'm having a PHP project that for some reason (not my initiative) has some backup files like "somefile - backup.php".
How do I exclude "%backup%.php" from indexing?
Settings/Preferences | Editor | File Types | Ignore files and folders field on the bottom -- add *-backup.php pattern (or whatever pattern you need).
PLEASE NOTE: this affects all projects as it is an IDE-wide setting.
Alternatively (have not tried myself, but should work):
Settings/Preferences | Editor | File Types | Recognized File Types | Text
Add *-backup.php pattern there.
This will also affect all projects .. but instead of excluding it will treat them as plain text files, so no indexing/code completion/syntax highlighting/etc while still having such files in the Project View tree (so you can edit/delete/upload/etc them if necessary).
"Settings > File Types > Ignore file and folders" and add the path of the folder.
Example: *.lib;client/build;
This worked for me to ignore a folder.