Knowledge Base Article Formatting
When writing a Knowledge Base article, I insert blank lines between paragraphs or distinct items for readability sake. I've found, however, that when viewing completed articles in the Knowledge Base, all the blank lines and paragraphs are gone--the article becomes just one long impenetrable paragraph.
Is there some trick I need to know to keep the blank lines and paragraph formatting within articles?
Thanks.
Is there some trick I need to know to keep the blank lines and paragraph formatting within articles?
Thanks.
0 Comments
[ + ] Show comments
Answers (7)
Please log in to answer
Posted by:
Larry Mateo
13 years ago
Posted by:
GillySpy
13 years ago
I got a notification on this so was this message on the K1000 boards originally and is this about the K1000 Knowledge Base? If so, my favourite way to create articles that are going to be viewed on the web is to use an editor like Xinha which is a browser pluging that gives me a wysiwyg view. I can copy / paste from other web pages and use the GUI tools for formatting then click apply and all the markup is saved in the KB article. Of course i check the box "use markdown".
The drawback with this is you cannot them embed the article intoa ticket using the "KB Article lookup mechanism". Since the ticket comments and ticket emails are text-based when you do a lookup on a highly marked up document you just get the source and when that is saved it does not strip out the HTML -- even worse it converts the tags into html entities. e.g. <tag> becomes <tag>
If you intend to view the article:
The drawback with this is you cannot them embed the article intoa ticket using the "KB Article lookup mechanism". Since the ticket comments and ticket emails are text-based when you do a lookup on a highly marked up document you just get the source and when that is saved it does not strip out the HTML -- even worse it converts the tags into html entities. e.g. <tag> becomes <tag>
If you intend to view the article:
- only in a ticket: just use text and no markdown at all. Trust the editor view and not the saved view.
- only in the web view: use a WYSIWYG editor like Xinha and turn on markdown.
- in both: check the box and use markup and markdown sparingly. enough to mark itup but not enough to make it hard to read in plain text.
Posted by:
bkelly
13 years ago
Posted by:
Gearshock
12 years ago
This answered most of my questions, but I have a separate issue as well. I entered in the KB like so as a simple test
(This is about the k1000 btw)
But when I append information from a KB into a ticket, it shows it as code, not as formatted text. Is there a solution for this?
(This is about the k1000 btw)
<p>REPORTS
</p>
<p>When making a report if there are too many columns for landscape page printing, it will not let you save.
</p>
<ol>
<li>Go to the Layout Page, you should be here if you received the error (final page with option to save report)</li>
<li> Click the title of your report, it should be just above your reporting fields on the left in parentheses. </li>
<li>Next hover down to Page Size and then select Custom Page Size</li>
</ol>
<p>There is a .docx attachment with this KB article that includes screenshots.
</p>
But when I append information from a KB into a ticket, it shows it as code, not as formatted text. Is there a solution for this?
Posted by:
GillySpy
12 years ago
Posted by:
Gearshock
12 years ago
Posted by:
GillySpy
12 years ago
ok, i see what you mean. I missed the part about putting it in a ticket. However, putting an article in a ticket is just one thing you might want to do with it.
The purpose of "markdown" is to be a markup language that is not very complex so that it provides useful formatting both when viewed in it's raw source AND when parsed into html.
It's similar to the concept of many wiki editors.
E.g. this is very readable in both formats:
The purpose of "markdown" is to be a markup language that is not very complex so that it provides useful formatting both when viewed in it's raw source AND when parsed into html.
It's similar to the concept of many wiki editors.
E.g. this is very readable in both formats:
*Taken from [http://docs.phplist.com/SetupCronJob](http://docs.phplist.com/SetupCronJob)*
Your schedule will be of the format
* * * * *
E.g. Every Monday at 1am is:
0 1 * * 1
More specifically the format is:
------------- minute (0 - 59)
| ----------- hour (0 - 23)
| | --------- day of month (1 - 31)
| | | ------- month (1 - 12)
| | | | ----- day of week (0 - 6) (Sunday=0)
| | | | |
* * * * *
You can use several operators for specifying scheduling values. These are the ones commonly used:
* The comma (',') operator specifies a list of values, for example: "1,3,4,7,8"
* The dash ('-') operator specifies a range of values, for example: "1-6", which is equivalent to "1,2,3,4,5,6"
* The asterisk ('\*') operator specifies all possible values for a field. For example, an asterisk in the hour time field would be equivalent to 'every hour'.
* The slash ('/') is an operator -available with some extended versions of cron support- which can be used to skip a given number of values.
Examples:
------------
* I want the script to run every 15 minutes starting at 5 p.m. (17) and running through 11:00 p.m. (23). This should happen Mon. (2) through Fri. (6).
*/15 17-23 * * 2,3,4,5,6
* Same thing as above, except runs it at midnight as well (0). (as an aside, this means it will run at 12:00, 12:15, 12:30 and 12:45.)
*/15 0 * * 2,3,4,5,6
* Sets the script to run from 1 a.m. to 6 a.m. (every 15 minutes) only on Mon., Wed., and Fri.
*/15 1-6 * * 2,4,6
* Script starting at 1 a.m. Tue., Thu., and Sat.
10 1 * * 3,5,7
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.