Hello,
it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.com organisation.
The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content.
All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples.
Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits.
The github repository for the wiki content is available at:
* https://github.com/kamailio/kamailio-wiki
It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done:
* convert relative links between wiki pages – the conversion tools used relative paths without file extensions, like:
[Install Kamailio v4.4.x From GIT](/install/4.4.x/git)
They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.com portal — practically the leading / has to be removed and .md added at the end, like:
[Install Kamailio v4.4.x From GIT](install/4.4.x/git.md)
* some section heading markers were not detected/converted, onee may notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example:
======= Install And Maintain Kamailio v4.4.x From GIT =======
Should be converted to:
# Install And Maintain Kamailio v4.4.x From GIT
* some Dokuwiki paragraphs used special formatting based on plugins, for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content:
<color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color>
Has to be transformed to:
:fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:*
You are welcome to propose a better syntax for this kind of transformation.
* review config examples and evaluate what improvements can be done (e.g., in terms of formatting and syntax highlighting)
Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of.
A very important decision is how to present the wiki markdown content on kamailio.org website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.org website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know.
Any questions and suggestions should be addressed to sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort!
Cheers, Daniel
We'd like to help.
Select one from Jekyll, Hugo and TailwindBlog
Jekyll: Ruby based https://jekyllrb.com/, can directly convert to html by github Hugo: Go based, can also auto covert to html https://gohugo.io/hosting-and-deployment/hosting-on-github/ TailwindBlog: Next.js based https://github.com/timlrx/tailwind-nextjs-starter-blog
We built a few websites with the TailwindBlog recently and it looks very good. But as all JS projects, you have to download a giant deps of node_modules and build locally manually to generate static html pages, we haven't found how to do it automatically, since our updates are not frequent, we are ok to do it by hand.
There may be other options. Anyway, look and discuss, as long as it's determined we can help to build.
As a reference, these are sites we just built recently:
- https://xswitch.cn/ - http://rts.cn/
On Mon, May 9, 2022 at 8:11 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.com organisation.
The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content.
All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples.
Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits.
The github repository for the wiki content is available at:
It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done:
- convert relative links between wiki pages – the conversion tools
used relative paths without file extensions, like:
[Install Kamailio v4.4.x From GIT](/install/4.4.x/git)
They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.com portal — practically the leading / has to be removed and .md added at the end, like:
[Install Kamailio v4.4.x From GIT](install/4.4.x/git.md)
- some section heading markers were not detected/converted, onee may
notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example:
======= Install And Maintain Kamailio v4.4.x From GIT =======
Should be converted to:
# Install And Maintain Kamailio v4.4.x From GIT
- some Dokuwiki paragraphs used special formatting based on plugins,
for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content:
<color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color>
Has to be transformed to:
:fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:*
You are welcome to propose a better syntax for this kind of transformation.
- review config examples and evaluate what improvements can be done
(e.g., in terms of formatting and syntax highlighting)
Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of.
A very important decision is how to present the wiki markdown content on kamailio.org website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.org website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know.
Any questions and suggestions should be addressed to sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort!
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Thanks, I will check them.
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
Cheers, Daniel
On 10.05.22 00:28, Seven Du wrote:
We'd like to help.
Select one from Jekyll, Hugo and TailwindBlog
Jekyll: Ruby based https://jekyllrb.com/, can directly convert to html by github Hugo: Go based, can also auto covert to html https://gohugo.io/hosting-and-deployment/hosting-on-github/%C2%A0 TailwindBlog: Next.js based https://github.com/timlrx/tailwind-nextjs-starter-blog
We built a few websites with the TailwindBlog recently and it looks very good. But as all JS projects, you have to download a giant deps of node_modules and build locally manually to generate static html pages, we haven't found how to do it automatically, since our updates are not frequent, we are ok to do it by hand.
There may be other options. Anyway, look and discuss, as long as it's determined we can help to build.
As a reference, these are sites we just built recently:
- https://xswitch.cn/ - http://rts.cn/
On Mon, May 9, 2022 at 8:11 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello, it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.com <http://github.com> organisation. The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content. All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples. Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits. The github repository for the wiki content is available at: * https://github.com/kamailio/kamailio-wiki It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done: * convert relative links between wiki pages – the conversion tools used relative paths without file extensions, like: [Install Kamailio v4.4.x From GIT](/install/4.4.x/git) They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.com <http://github.com> portal — practically the leading / has to be removed and .md added at the end, like: [Install Kamailio v4.4.x From GIT](install/4.4.x/git.md) * some section heading markers were not detected/converted, onee may notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example: ======= Install And Maintain Kamailio v4.4.x From GIT ======= Should be converted to: # Install And Maintain Kamailio v4.4.x From GIT * some Dokuwiki paragraphs used special formatting based on plugins, for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content: <color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color> Has to be transformed to: :fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:* You are welcome to propose a better syntax for this kind of transformation. * review config examples and evaluate what improvements can be done (e.g., in terms of formatting and syntax highlighting) Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of. A very important decision is how to present the wiki markdown content on kamailio.org <http://kamailio.org> website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.org <http://kamailio.org> website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know. Any questions and suggestions should be addressed to sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online * https://www.asipto.com/sw/kamailio-advanced-training-online/ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
thanks Seven for your feedback.
I have made good experiences with static site generators that just generate html that you can serve with standard web servers.
I did not personally have used it, but I heard that hugo works well and is used a lot. I personally have used gravcms, which is based on PHP.
You can easily combine this static generators with some cron job and it should work for our existing setup by just adding another path to the apache. In my experience this is easier as having another app to deploy, monitor and frequently update.
Cheers,
Henning
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: Tuesday, May 10, 2022 8:29 AM To: Seven Du dujinfang@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Info: converting dokuwiki content to markdown files
Thanks, I will check them.
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
Cheers, Daniel On 10.05.22 00:28, Seven Du wrote: We'd like to help.
Select one from Jekyll, Hugo and TailwindBlog
Jekyll: Ruby based https://jekyllrb.com/, can directly convert to html by github Hugo: Go based, can also auto covert to html https://gohugo.io/hosting-and-deployment/hosting-on-github/ TailwindBlog: Next.js based https://github.com/timlrx/tailwind-nextjs-starter-blog
We built a few websites with the TailwindBlog recently and it looks very good. But as all JS projects, you have to download a giant deps of node_modules and build locally manually to generate static html pages, we haven't found how to do it automatically, since our updates are not frequent, we are ok to do it by hand.
There may be other options. Anyway, look and discuss, as long as it's determined we can help to build.
As a reference, these are sites we just built recently:
- https://xswitch.cn/ - http://rts.cn/
On Mon, May 9, 2022 at 8:11 PM Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> wrote: Hello,
it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.comhttp://github.com organisation.
The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content.
All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples.
Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits.
The github repository for the wiki content is available at:
* https://github.com/kamailio/kamailio-wiki
It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done:
* convert relative links between wiki pages – the conversion tools used relative paths without file extensions, like:
[Install Kamailio v4.4.x From GIT](/install/4.4.x/git)
They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.comhttp://github.com portal — practically the leading / has to be removed and .md added at the end, like:
[Install Kamailio v4.4.x From GIT](install/4.4.x/git.md)
* some section heading markers were not detected/converted, onee may notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example:
======= Install And Maintain Kamailio v4.4.x From GIT =======
Should be converted to:
# Install And Maintain Kamailio v4.4.x From GIT
* some Dokuwiki paragraphs used special formatting based on plugins, for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content:
<color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color>
Has to be transformed to:
:fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:*
You are welcome to propose a better syntax for this kind of transformation.
* review config examples and evaluate what improvements can be done (e.g., in terms of formatting and syntax highlighting)
Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of.
A very important decision is how to present the wiki markdown content on kamailio.orghttp://kamailio.org website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.orghttp://kamailio.org website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know.
Any questions and suggestions should be addressed to sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort!
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda Kamailio Advanced Training - Online * https://www.asipto.com/sw/kamailio-advanced-training-online/
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Kamailio Advanced Training - Online: June 20-23, 2022
* https://www.asipto.com/sw/kamailio-advanced-training-online/
Fiddled around w/ pandoc [1]
[1] https://github.com/kamailio/kamailio-wiki/pull/3
On Tue, May 10, 2022 at 9:08 AM Henning Westerholt hw@gilawa.com wrote:
Hello,
thanks Seven for your feedback.
I have made good experiences with static site generators that just generate html that you can serve with standard web servers.
I did not personally have used it, but I heard that hugo works well and is used a lot. I personally have used gravcms, which is based on PHP.
You can easily combine this static generators with some cron job and it should work for our existing setup by just adding another path to the apache.
In my experience this is easier as having another app to deploy, monitor and frequently update.
Cheers,
Henning
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: Tuesday, May 10, 2022 8:29 AM To: Seven Du dujinfang@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Info: converting dokuwiki content to markdown files
Thanks, I will check them.
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
Cheers, Daniel
On 10.05.22 00:28, Seven Du wrote:
We'd like to help.
Select one from Jekyll, Hugo and TailwindBlog
Jekyll: Ruby based https://jekyllrb.com/, can directly convert to html by github
Hugo: Go based, can also auto covert to html https://gohugo.io/hosting-and-deployment/hosting-on-github/
TailwindBlog: Next.js based https://github.com/timlrx/tailwind-nextjs-starter-blog
We built a few websites with the TailwindBlog recently and it looks very good. But as all JS projects, you have to download a giant deps of node_modules and build locally manually to generate static html pages, we haven't found how to do it automatically, since our updates are not frequent, we are ok to do it by hand.
There may be other options. Anyway, look and discuss, as long as it's determined we can help to build.
As a reference, these are sites we just built recently:
On Mon, May 9, 2022 at 8:11 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.com organisation.
The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content.
All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples.
Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits.
The github repository for the wiki content is available at:
It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done:
- convert relative links between wiki pages – the conversion tools
used relative paths without file extensions, like:
[Install Kamailio v4.4.x From GIT](/install/4.4.x/git)
They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.com portal — practically the leading / has to be removed and .md added at the end, like:
[Install Kamailio v4.4.x From GIT](install/4.4.x/git.md)
- some section heading markers were not detected/converted, onee may
notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example:
======= Install And Maintain Kamailio v4.4.x From GIT =======
Should be converted to:
# Install And Maintain Kamailio v4.4.x From GIT
- some Dokuwiki paragraphs used special formatting based on plugins,
for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content:
<color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color>
Has to be transformed to:
:fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:*
You are welcome to propose a better syntax for this kind of transformation.
- review config examples and evaluate what improvements can be done
(e.g., in terms of formatting and syntax highlighting)
Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of.
A very important decision is how to present the wiki markdown content on kamailio.org website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.org website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know.
Any questions and suggestions should be addressed to sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort!
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online: June 20-23, 2022
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Thanks for all your PRs this morning! I got the one with pandoc locally and run it, I noticed some warnings, but didn't get deep into them. Opened the start page and I could browse locally a few links.
To be able to organize better in the future, I am considering to relocate the wiki content to a new docs/ subfolder.
Then we can have a main Makefile in the root folder that can be used to generate various formats, like the one you proposed using pandoc. A new subfolder (fmt/, misc/, tools, ...) can be created to collect configs/scripts specific to each formatting variant.
The root folder should be like:
docs/[wiki files] fmt/pandoc/links.lua fmt/mkdocs/... Makefile README.md ...
I used pandoc and mkdocs as examples just to express what I meant.
Any other opinions/suggestions?
Cheers, Daniel
On 10.05.22 11:25, Bastian Triller wrote:
Fiddled around w/ pandoc [1]
[1] https://github.com/kamailio/kamailio-wiki/pull/3
On Tue, May 10, 2022 at 9:08 AM Henning Westerholt hw@gilawa.com wrote:
Hello,
thanks Seven for your feedback.
I have made good experiences with static site generators that just generate html that you can serve with standard web servers.
I did not personally have used it, but I heard that hugo works well and is used a lot. I personally have used gravcms, which is based on PHP.
You can easily combine this static generators with some cron job and it should work for our existing setup by just adding another path to the apache.
In my experience this is easier as having another app to deploy, monitor and frequently update.
Cheers,
Henning
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Daniel-Constantin Mierla Sent: Tuesday, May 10, 2022 8:29 AM To: Seven Du dujinfang@gmail.com; Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] Info: converting dokuwiki content to markdown files
Thanks, I will check them.
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
Cheers, Daniel
On 10.05.22 00:28, Seven Du wrote:
We'd like to help.
Select one from Jekyll, Hugo and TailwindBlog
Jekyll: Ruby based https://jekyllrb.com/, can directly convert to html by github
Hugo: Go based, can also auto covert to html https://gohugo.io/hosting-and-deployment/hosting-on-github/
TailwindBlog: Next.js based https://github.com/timlrx/tailwind-nextjs-starter-blog
We built a few websites with the TailwindBlog recently and it looks very good. But as all JS projects, you have to download a giant deps of node_modules and build locally manually to generate static html pages, we haven't found how to do it automatically, since our updates are not frequent, we are ok to do it by hand.
There may be other options. Anyway, look and discuss, as long as it's determined we can help to build.
As a reference, these are sites we just built recently:
On Mon, May 9, 2022 at 8:11 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it was discussed a couple of times during the past Kamailio development meetings and several days ago the works started to convert the Kamailio Wiki content to markdown format and host the files on Kamailio github.com organisation.
The Dokuwiki engine has served us very well during more than a decade and a half, but open editing had to be disabled many years ago due to bad actors pushing inappropriate content. The contributors had to make a dedicated account on our portal only for Wiki editing. More recently we had add another layer of protection requiring to grant manually edit permissions to newly created wiki accounts because bots started to work around CAPTCHA and other security extensions, posting again inappropriate content.
All these added to operational overhead, but also made it difficult for new people to contribute, specially for small editing to fix typos or add usage examples.
Thanks to Kenneth Stowe, who undertook the first big effort of converting the Dowkuwiki files to markdown format, we are now in the position of moving further with the plans of using github for hosting the content of the wiki and enable easier contributions via pull requests. The history of changes done via Dokuwiki show up now as git commits.
The github repository for the wiki content is available at:
It is still work in progress, therefore we ask for the help of community to speed up the conversion, among the tasks that need to be done:
- convert relative links between wiki pages – the conversion tools
used relative paths without file extensions, like:
[Install Kamailio v4.4.x From GIT](/install/4.4.x/git)
They have to be converted to relative path with .md extension in order to be able to browse directly :n the github.com portal — practically the leading / has to be removed and .md added at the end, like:
[Install Kamailio v4.4.x From GIT](install/4.4.x/git.md)
- some section heading markers were not detected/converted, onee may
notice many equal signs (=) around a section name, it has to be replaced with the appropriate markdown format based on hash signs (#). For example:
======= Install And Maintain Kamailio v4.4.x From GIT =======
Should be converted to:
# Install And Maintain Kamailio v4.4.x From GIT
- some Dokuwiki paragraphs used special formatting based on plugins,
for example the notes, warnings, … had special colors. The common markdown format does not specify a syntax to color the text, the propose solution is to use emoji at the start of the paragraph to signal its special purpose. For example, the Dokuwiki content:
<color blue>//IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**://</color>
Has to be transformed to:
:fire:*IMPORTANT: Content for older releases than 3.2.0 is available at the **Old Wiki Site**:*
You are welcome to propose a better syntax for this kind of transformation.
- review config examples and evaluate what improvements can be done
(e.g., in terms of formatting and syntax highlighting)
Any of these changes do not require any C programming knowledge, nor much Kamailio config knowledge. Can be your first contribution to the project and it will be very appreciated. It can also help you learn more about Kamailio, because you may discover documentation that you were not aware of.
A very important decision is how to present the wiki markdown content on kamailio.org website. Besides being able to see it on github repository, we want to process the markdown pages somehow and make them available in html format on kamailio.org website for easier navigation and better indexing (e.g., with tables of content for large pages). If you are aware of a suitable cli or web app that can convert markdown to html and generate table of content, let us know.
Any questions and suggestions should be addressed to sr-users@lists.kamailio.org mailing list. Looking forward to your contributions on this community effort!
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online: June 20-23, 2022
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the browser window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
* https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
* https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the browser window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
* https://www.kamailio.org/wikidocs/
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
* https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
* https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the browser window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
On 11.05.22 14:11, Daniel-Constantin Mierla wrote:
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it.
Cheers, Daniel
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
* https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
* https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the browser window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
I looked hugo today, and looks like we have to add yaml meta data to each markdown file and relocate files to follow the hugo convention. The worse things is, different themes have different conventions. while we will eventually use one theme, but it's not easy to try different themes, we will have to play themes if we make it better later, but we don't want to be expert on hugo.
So as mkdocs kind of work, maybe we can stick with it. I also played some css tricks to pin the TOC to the left of the page if we use pandoc. the PR maybe not ready to merge before we figure out the path problem.
https://github.com/kamailio/kamailio-wiki/pull/5
On Wed, May 11, 2022 at 8:19 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
On 11.05.22 14:11, Daniel-Constantin Mierla wrote:
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it.
Cheers, Daniel
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and
adapting
the wiki structure for a static site generator from .md files is
enough
or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the
browser
window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
found a new wheel lol:
https://rust-lang.github.io/mdBook/index.html
On Thu, May 12, 2022 at 10:36 AM Seven Du dujinfang@gmail.com wrote:
I looked hugo today, and looks like we have to add yaml meta data to each markdown file and relocate files to follow the hugo convention. The worse things is, different themes have different conventions. while we will eventually use one theme, but it's not easy to try different themes, we will have to play themes if we make it better later, but we don't want to be expert on hugo.
So as mkdocs kind of work, maybe we can stick with it. I also played some css tricks to pin the TOC to the left of the page if we use pandoc. the PR maybe not ready to merge before we figure out the path problem.
https://github.com/kamailio/kamailio-wiki/pull/5
On Wed, May 11, 2022 at 8:19 PM Daniel-Constantin Mierla < miconda@gmail.com> wrote:
On 11.05.22 14:11, Daniel-Constantin Mierla wrote:
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it.
Cheers, Daniel
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy
and
serve html pages generated from the .md files directly from the
folder
with the clone of the github repo. But maybe I ask too much and
adapting
the wiki structure for a static site generator from .md files is
enough
or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the
content
files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the
browser
window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Other: http://rts.cn
Interesting, do you know if it supports rendering emoji out of the box?
For mkdocs I had to install some python extensions to get them built in the html output.
Cheers, Daniel
On 12.05.22 08:47, Seven Du wrote:
found a new wheel lol:
https://rust-lang.github.io/mdBook/index.html
On Thu, May 12, 2022 at 10:36 AM Seven Du dujinfang@gmail.com wrote:
I looked hugo today, and looks like we have to add yaml meta data to each markdown file and relocate files to follow the hugo convention. The worse things is, different themes have different conventions. while we will eventually use one theme, but it's not easy to try different themes, we will have to play themes if we make it better later, but we don't want to be expert on hugo. So as mkdocs kind of work, maybe we can stick with it. I also played some css tricks to pin the TOC to the left of the page if we use pandoc. the PR maybe not ready to merge before we figure out the path problem. https://github.com/kamailio/kamailio-wiki/pull/5 On Wed, May 11, 2022 at 8:19 PM Daniel-Constantin Mierla <miconda@gmail.com> wrote: On 11.05.22 14:11, Daniel-Constantin Mierla wrote: > I played a bit with mkdocs on kamailio-wiki files and published the html > output at: > > * https://www.kamailio.org/wikidocs/ Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it. Cheers, Daniel > > Some internal links may not work because I noticed warnings when mkdocs > was building the html pages, I will review and fix when I get a chance. > > The kamailio-wiki gtihub repo has now a Makefile that enables building > html files using pandoc or mkdocs. Maybe someone can contribute support > for using hugo or other static site generator, then we can decide in the > community which result is better to publish on the website. > > Cheers, > Daniel > > On 10.05.22 16:31, Daniel-Constantin Mierla wrote: >> Thanks for the useful details about hugo! >> >> For the records, in the past we used the mkdocs for a couple of >> tutorials, like the one for KEMI framework or install guidelines, eg: >> >> * https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/ >> >> Built from: >> >> * >> https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framework >> >> But I can't say I am that familiar with it to assert if it is the best >> one for the wiki, which has lot of content and some pages could end up >> with large ToC (e.g., the cookbooks for core, variables, ...). >> >> Anyhow, let's have it in the list and see if we get more feedback or >> other suggestions from the community. >> >> Cheers, >> Daniel >> >> On 10.05.22 13:01, Greg Troxel wrote: >>> Daniel-Constantin Mierla <miconda@gmail.com> writes: >>> >>>> Ideally it is an app that can run on or behind a http server/proxy and >>>> serve html pages generated from the .md files directly from the folder >>>> with the clone of the github repo. But maybe I ask too much and adapting >>>> the wiki structure for a static site generator from .md files is enough >>>> or even better. >>> I have been slowly converting my own content to hugo. It's a very >>> straightforward static site generator, and it runs very quickly. >>> >>> It also has a built-in webserver, and by default it watches the content >>> files and provides the built website on port 127.0.0.1:1313 <http://127.0.0.1:1313>. This is >>> intended for previewing while editing - once you save a file the browser >>> window gets the new content in under a second. >>> >>> So if you either make hugo use your layout, or adapt to hugo's idea of >>> layout (which is quite sane), then not only can bits be pushed to a >>> server, but "hugo server" will make them available. >>> >>> So if I were tackling this, of all the options listed, I would lean >>> strongly to hugo. >> -- >> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> >> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >> Kamailio Advanced Training - Online: June 20-23, 2022 >> * https://www.asipto.com/sw/kamailio-advanced-training-online/ >> > -- > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > Kamailio Advanced Training - Online: June 20-23, 2022 > * https://www.asipto.com/sw/kamailio-advanced-training-online/ > -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online: June 20-23, 2022 * https://www.asipto.com/sw/kamailio-advanced-training-online/ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Other: http://rts.cn-- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Other: http://rts.cn
On 12.05.22 04:36, Seven Du wrote:
I looked hugo today, and looks like we have to add yaml meta data to each markdown file and relocate files to follow the hugo convention. The worse things is, different themes have different conventions. while we will eventually use one theme, but it's not easy to try different themes, we will have to play themes if we make it better later, but we don't want to be expert on hugo.
Thanks for pursuing this one!
I would prefer to keep the content of markdown files (and directory structure) as much as possible not dependent/specific of a html generating tool.
For mkdocs I could not find a way to have the custom css in another folder than inside (sub-folder) docs folder, so I created the _xcfg/ subfolder to collect files having such constraints, otherwise, files specific to tools should be inside the fmt/__TOOL_/ folder (e.g., fmt/mkdocs/).
So as mkdocs kind of work, maybe we can stick with it.
For me it looks good as well so far.
I also played some css tricks to pin the TOC to the left of the page if we use pandoc. the PR maybe not ready to merge before we figure out the path problem.
It can be merged and future improvements can be done, if anyone comes up with new ideas.
Cheers, Daniel
On Wed, May 11, 2022 at 8:19 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
On 11.05.22 14:11, Daniel-Constantin Mierla wrote: > I played a bit with mkdocs on kamailio-wiki files and published the html > output at: > > * https://www.kamailio.org/wikidocs/ Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it. Cheers, Daniel > > Some internal links may not work because I noticed warnings when mkdocs > was building the html pages, I will review and fix when I get a chance. > > The kamailio-wiki gtihub repo has now a Makefile that enables building > html files using pandoc or mkdocs. Maybe someone can contribute support > for using hugo or other static site generator, then we can decide in the > community which result is better to publish on the website. > > Cheers, > Daniel > > On 10.05.22 16:31, Daniel-Constantin Mierla wrote: >> Thanks for the useful details about hugo! >> >> For the records, in the past we used the mkdocs for a couple of >> tutorials, like the one for KEMI framework or install guidelines, eg: >> >> * https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/ >> >> Built from: >> >> * >> https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framework >> >> But I can't say I am that familiar with it to assert if it is the best >> one for the wiki, which has lot of content and some pages could end up >> with large ToC (e.g., the cookbooks for core, variables, ...). >> >> Anyhow, let's have it in the list and see if we get more feedback or >> other suggestions from the community. >> >> Cheers, >> Daniel >> >> On 10.05.22 13:01, Greg Troxel wrote: >>> Daniel-Constantin Mierla <miconda@gmail.com> writes: >>> >>>> Ideally it is an app that can run on or behind a http server/proxy and >>>> serve html pages generated from the .md files directly from the folder >>>> with the clone of the github repo. But maybe I ask too much and adapting >>>> the wiki structure for a static site generator from .md files is enough >>>> or even better. >>> I have been slowly converting my own content to hugo. It's a very >>> straightforward static site generator, and it runs very quickly. >>> >>> It also has a built-in webserver, and by default it watches the content >>> files and provides the built website on port 127.0.0.1:1313 <http://127.0.0.1:1313>. This is >>> intended for previewing while editing - once you save a file the browser >>> window gets the new content in under a second. >>> >>> So if you either make hugo use your layout, or adapt to hugo's idea of >>> layout (which is quite sane), then not only can bits be pushed to a >>> server, but "hugo server" will make them available. >>> >>> So if I were tackling this, of all the options listed, I would lean >>> strongly to hugo. >> -- >> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> >> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> >> Kamailio Advanced Training - Online: June 20-23, 2022 >> * https://www.asipto.com/sw/kamailio-advanced-training-online/ >> > -- > Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> > www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > Kamailio Advanced Training - Online: June 20-23, 2022 > * https://www.asipto.com/sw/kamailio-advanced-training-online/ > -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - Online: June 20-23, 2022 * https://www.asipto.com/sw/kamailio-advanced-training-online/ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users-- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Other: http://rts.cn
More on emoji support with mkdocs: I installed the extensions but they seem to point to CDN sites with links to svg/png images. This is also done by github when browsing the files in the repo (they point to their CND server), but I think it's not the optimal solution for the variant to be stored on kamailio.org, because every time someone loads it from our website, the emojis are downloaded from the remote CDN servers (can be slower, privacy concerns, ...).
Apparently it works to paste the UTF-8 character code for the emoji in the md file and then all looks good in github repo and mkdocs/mdbook/pandoc output. Therefore I think this is better to do.
For now, my solution for getting the UTF-8 code for a specific emoji is to select & copy the character from another file having it. For example open in browser:
* https://github.com/ikatyang/emoji-cheat-sheet/blob/master/README.md
Then do "View source", search in it for the emoji you want, e.g.: ":warning:" and you should find something like:
<td align="center"><g-emoji class="g-emoji" alias="warning" fallback-src="https://github.githubassets.com/images/icons/emoji/unicode/26a0.png">⚠️</g-emoji></td> <td><code>:warning:</code></td>
The character looks like a small image, respectively the yellow triangle with exclamation before the end tag </g-emoji>. Select it, copy and paste in the md file where you want to use it.
Cheers, Daniel
On 11.05.22 14:17, Daniel-Constantin Mierla wrote:
On 11.05.22 14:11, Daniel-Constantin Mierla wrote:
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it.
Cheers, Daniel
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
* https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
* https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy and serve html pages generated from the .md files directly from the folder with the clone of the github repo. But maybe I ask too much and adapting the wiki structure for a static site generator from .md files is enough or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the content files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the browser window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
more on mdBook, Nav Summary page doesn't work well without https://github.com/rust-lang/mdBook/issues/167
So only mkdocs and pandoc left.
On Thu, May 12, 2022 at 5:06 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
More on emoji support with mkdocs: I installed the extensions but they seem to point to CDN sites with links to svg/png images. This is also done by github when browsing the files in the repo (they point to their CND server), but I think it's not the optimal solution for the variant to be stored on kamailio.org, because every time someone loads it from our website, the emojis are downloaded from the remote CDN servers (can be slower, privacy concerns, ...).
Apparently it works to paste the UTF-8 character code for the emoji in the md file and then all looks good in github repo and mkdocs/mdbook/pandoc output. Therefore I think this is better to do.
For now, my solution for getting the UTF-8 code for a specific emoji is to select & copy the character from another file having it. For example open in browser:
Then do "View source", search in it for the emoji you want, e.g.: ":warning:" and you should find something like:
<td align="center"><g-emoji class="g-emoji" alias="warning" fallback-src=" https://github.githubassets.com/images/icons/emoji/unicode/26a0.png ">⚠️</g-emoji></td> <td><code>:warning:</code></td>
The character looks like a small image, respectively the yellow triangle with exclamation before the end tag </g-emoji>. Select it, copy and paste in the md file where you want to use it.
Cheers, Daniel
On 11.05.22 14:17, Daniel-Constantin Mierla wrote:
On 11.05.22 14:11, Daniel-Constantin Mierla wrote:
I played a bit with mkdocs on kamailio-wiki files and published the html output at:
Following up: I noticed mkdocs does not support emoji (which I thought of using to highlight paragraphs, notes, etc.), but there seem to be extensions for it.
Cheers, Daniel
Some internal links may not work because I noticed warnings when mkdocs was building the html pages, I will review and fix when I get a chance.
The kamailio-wiki gtihub repo has now a Makefile that enables building html files using pandoc or mkdocs. Maybe someone can contribute support for using hugo or other static site generator, then we can decide in the community which result is better to publish on the website.
Cheers, Daniel
On 10.05.22 16:31, Daniel-Constantin Mierla wrote:
Thanks for the useful details about hugo!
For the records, in the past we used the mkdocs for a couple of tutorials, like the one for KEMI framework or install guidelines, eg:
https://www.kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/
Built from:
https://github.com/kamailio/kamailio-docs/tree/master/kamailio-kemi-framewor...
But I can't say I am that familiar with it to assert if it is the best one for the wiki, which has lot of content and some pages could end up with large ToC (e.g., the cookbooks for core, variables, ...).
Anyhow, let's have it in the list and see if we get more feedback or other suggestions from the community.
Cheers, Daniel
On 10.05.22 13:01, Greg Troxel wrote:
Daniel-Constantin Mierla miconda@gmail.com writes:
Ideally it is an app that can run on or behind a http server/proxy
and
serve html pages generated from the .md files directly from the
folder
with the clone of the github repo. But maybe I ask too much and
adapting
the wiki structure for a static site generator from .md files is
enough
or even better.
I have been slowly converting my own content to hugo. It's a very straightforward static site generator, and it runs very quickly.
It also has a built-in webserver, and by default it watches the
content
files and provides the built website on port 127.0.0.1:1313. This is intended for previewing while editing - once you save a file the
browser
window gets the new content in under a second.
So if you either make hugo use your layout, or adapt to hugo's idea of layout (which is quite sane), then not only can bits be pushed to a server, but "hugo server" will make them available.
So if I were tackling this, of all the options listed, I would lean strongly to hugo.
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online: June 20-23, 2022
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Bastian Triller -
Daniel-Constantin Mierla -
Greg Troxel -
Henning Westerholt -
Seven Du