Wiki improvements
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: Wiki improvements
Shared Library Example
Using Shared Libraries on Windows
Using Shared Libraries on Linux
Executables that export symbols
Loading Shared Libraries Dynamically
Exchanging/Sharing variables with shared library on Windows
Creating import Libraries from def files on Windows
The point are every time I create such import lib I don't remember the command line switches for 64-bit
so I think the section of shared libraries are the right place to collect such information.
Joshy
Using Shared Libraries on Windows
Using Shared Libraries on Linux
Executables that export symbols
Loading Shared Libraries Dynamically
Exchanging/Sharing variables with shared library on Windows
Creating import Libraries from def files on Windows
The point are every time I create such import lib I don't remember the command line switches for 64-bit
so I think the section of shared libraries are the right place to collect such information.
Joshy
Re: Wiki improvements
Done:
- ProPgSharedLibraries → fxm [added syntax for creating import Libraries from def files on Windows]
- ProPgSharedLibraries → fxm [added syntax for creating import Libraries from def files on Windows]
Re: Wiki improvements
I'd really like fb.net/wiki to rank better in search results. I don't know anything about search engine optimization (SEO).
Based on some remarks by misterc I looked at the wiki code:
As of May 21, 2022 - I modified the <TITLE> element for wiki pages. The HTML title is now extracted from {{fbdoc item="title" value="string"}} action.
I investigated some other things we could do:
- adding META keywords to all wiki pages (a global setting for all pages)
- adding META description to all wiki pages (a global setting for all pages)
- add {{titletag}} actions to override the HTML TITLE element (individual for each page, and I would need to update fbdoc software).
- changing the name of the wiki - for example from FbWiki to "FreeBASIC Wiki" (a global setting) which is automatically appended to all HTML TITLE elements.
Any suggestions on what to improve and how are welcome.
Based on some remarks by misterc I looked at the wiki code:
As of May 21, 2022 - I modified the <TITLE> element for wiki pages. The HTML title is now extracted from {{fbdoc item="title" value="string"}} action.
I investigated some other things we could do:
- adding META keywords to all wiki pages (a global setting for all pages)
- adding META description to all wiki pages (a global setting for all pages)
- add {{titletag}} actions to override the HTML TITLE element (individual for each page, and I would need to update fbdoc software).
- changing the name of the wiki - for example from FbWiki to "FreeBASIC Wiki" (a global setting) which is automatically appended to all HTML TITLE elements.
Any suggestions on what to improve and how are welcome.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: Wiki improvements
@fxm here are "how to create a *.def file from *.dll" and how to create a "*.dll.a" file directly from "*.dll" file.
Create "*.def" file from "*.dll" file:Create the import lib "*.dll.a" file directly from "*.dll":
Create "*.def" file from "*.dll" file:
Code: Select all
x:\FreeBASIC\bin\win32\dlltool --dllname XXX.dll --output-def XXX.def
x:\FreeBASIC\bin\win64\dlltool --dllname XXX.dll --output-def XXX.def
or using -D and -z
x:\FreeBASIC\bin\win32\dlltool -D XXX.dll -z XXX.def
x:\FreeBASIC\bin\win64\dlltool -D XXX.dll -z XXX.def
Code: Select all
x:\FreeBASIC\bin\win32\dlltool -k -d XXX.dll -l libXXX.dll.a
x:\FreeBASIC\bin\win32\dlltool -k -d XXX.dll -l libXXX.dll.a
Re: Wiki improvements
Done:
- ProPgSharedLibraries → fxm [added syntaxes for creating def files or import libraries from DLL files on Windows]
- ProPgSharedLibraries → fxm [added syntaxes for creating def files or import libraries from DLL files on Windows]
Re: Wiki improvements
Hi coderJeff, thanks for taking the time to look into this for the wiki.coderJeff wrote: ↑May 21, 2022 20:39 I'd really like fb.net/wiki to rank better in search results. I don't know anything about search engine optimization (SEO).
Based on some remarks by misterc I looked at the wiki code:
As of May 21, 2022 - I modified the <TITLE> element for wiki pages. The HTML title is now extracted from {{fbdoc item="title" value="string"}} action.
I investigated some other things we could do:
- adding META keywords to all wiki pages (a global setting for all pages)
- adding META description to all wiki pages (a global setting for all pages)
- add {{titletag}} actions to override the HTML TITLE element (individual for each page, and I would need to update fbdoc software).
- changing the name of the wiki - for example from FbWiki to "FreeBASIC Wiki" (a global setting) which is automatically appended to all HTML TITLE elements.
Any suggestions on what to improve and how are welcome.
I do SEO templating as part of my day job, and thought I'd offer a basic priority list for changes.
My example page would be something like this:
https://www.freebasic.net/wiki/KeyPgIfthen
The reasoning here is that it's a topical page you'd want a beginner to be able to land on. To really get the Wiki being used widely in search results, we'd want to aim for people who search for e.g. "freebasic install" or "freebasic if else" etc., in other words (product) (thing I need to learn about)
So here would be my suggested order of changes:
- Title tags: Add proper page title and "FreeBASIC" keyword for sure. Keeping "FBWiki" is fine, especially to retain people already searching for it, who may have made it a habit. I'd lean toward something like
"(Proper Page Title) - FreeBASIC Wiki Manual | FBWiki" - Heading tags: I'm not sure why the highest-level tag on a page like the example page above is h2. h1 would be more appropriate since it's the first level heading on the page. But regardless, in terms of their content, something like the title tag would be appropriate, maybe just dropping the "FBWiki" part for that.
- Adding relevant words to the page. For example "IF ... THEN" ...OK, I know this is the title of the manual page, but for SEO I would add ELSE in there, to catch those also searching for "if else freebasic". I tried this and MDN's javascript reference "if...else" ranked really highly.
- Relevant stopwords in internal search: It seems there are some stopwords that are relevant that should be un-stopped in the internal search, to make the wiki more useful. I'd try to get "if" "else" and others if found, searchable.
- Search results pages in internal wiki search: If it's possible, proper titles and excerpts in search results would be really helpful here. For example, I searched "wend" and couldn't decide what result to click on. But also, search result pages can show up as third-party search engine results (this is great--the wiki uses GET vars for search, nice job wiki), so the appearance is important.
- Metas -- These are lower on my list because most search engines will ignore these these days, but the description is used by some search engines to describe the page in the search results, if not for ranking. So filling them out is not a bad idea, less keywords and more description IMO.
Thanks again for looking into this.
Re: Wiki improvements
@misterc, thank-you for the feedback and assessment.
I think I got the first couple (easier) items done:
HTML <title> Tag:
Before: "KeyPgIfthen: FBWiki" ( or maybe it was "IF...THEN: FBWiki", I lost track )
After : "IF...THEN - FreeBASIC Manual | FBWiki"
Top Level Page Title:
Before: <h2>FBWiki : KeyPgIfthen</h2>
After : <h1>IF...THEN - FreeBASIC Manual | FBWiki</h1>
Content Title (on the page itself):
Before: <h3>IF...THEN</h3>
After : <h2>IF...THEN</h2>
If it doesn't look right or doesn't quite work right, can keep tweaking the output.
For the search related items, some effort will be required. The wiki just uses a sql fulltext search with the minimum word size of 4 and I don't have control over the minimum word size. Also, the search terms only act on the raw wakka (wiki) script, so the rendered text isn't getting indexed.
Adding proper page titles to wiki pages that list pages is easy. I just need to watch I don't break any of our external tools. The actual page name keys like 'KeyPgIfThen' are meaningful to our tools that convert the wiki to offline formats.
----
I ran a maintenance function on the database that should extract the title from the wakka script and cache it in it's own field in the database. It's possible there are a couple of pages that didn't get updated. (i.e. the cache didn't get updated). I noticed this on the main page FBWiki. However, editing the page will also update the cached title.
I updated fbdoc action to allow visible property for titles: {{fbdoc item="title" value="text" [visible="1"]}} . This allows setting the <title> tag and the top level title without actually displaying in the page's content. There may be a couple of special pages (like FBWiki) where we want to set a page title but display some image or something else on the actual page content.
I think I got the first couple (easier) items done:
HTML <title> Tag:
Before: "KeyPgIfthen: FBWiki" ( or maybe it was "IF...THEN: FBWiki", I lost track )
After : "IF...THEN - FreeBASIC Manual | FBWiki"
Top Level Page Title:
Before: <h2>FBWiki : KeyPgIfthen</h2>
After : <h1>IF...THEN - FreeBASIC Manual | FBWiki</h1>
Content Title (on the page itself):
Before: <h3>IF...THEN</h3>
After : <h2>IF...THEN</h2>
If it doesn't look right or doesn't quite work right, can keep tweaking the output.
For the search related items, some effort will be required. The wiki just uses a sql fulltext search with the minimum word size of 4 and I don't have control over the minimum word size. Also, the search terms only act on the raw wakka (wiki) script, so the rendered text isn't getting indexed.
Adding proper page titles to wiki pages that list pages is easy. I just need to watch I don't break any of our external tools. The actual page name keys like 'KeyPgIfThen' are meaningful to our tools that convert the wiki to offline formats.
----
I ran a maintenance function on the database that should extract the title from the wakka script and cache it in it's own field in the database. It's possible there are a couple of pages that didn't get updated. (i.e. the cache didn't get updated). I noticed this on the main page FBWiki. However, editing the page will also update the cached title.
I updated fbdoc action to allow visible property for titles: {{fbdoc item="title" value="text" [visible="1"]}} . This allows setting the <title> tag and the top level title without actually displaying in the page's content. There may be a couple of special pages (like FBWiki) where we want to set a page title but display some image or something else on the actual page content.
Re: Wiki improvements
@Jeff,
Some titles at the top got weird.
Examples in Programmer's Guide pages:
- ProPgCtorsAssignDtors2
- ProPgMtCriticalSectionsFAQ
- ProPgFileIO
It seems that other header tags encountered, even in the code examples, affect the top title.
Some titles at the top got weird.
Examples in Programmer's Guide pages:
- ProPgCtorsAssignDtors2
- ProPgMtCriticalSectionsFAQ
- ProPgFileIO
It seems that other header tags encountered, even in the code examples, affect the top title.
Re: Wiki improvements
@fxm, I see. Should be OK now. There were about 20 pages titles I missed on the update that were caching an old title.
Re: Wiki improvements
Thanks Jeff.
Re: Wiki improvements
@coderJeff Just wanted to say--it's really cool to see these reflected in google result pages already. Way to go, that's awesome.
I'm sure this will be appreciated by users as well as Google and other crawlers of all kinds.
Sharing some random thoughts as I look over the uh, competition...
- Google tends to reward sites that users prefer to navigate. So my thoughts go to making the Wiki really simple to navigate, and I wonder if some kind of regular navigation menu up top, between title and wikicrumbs menu, might be appropriate for both new users and Google. This taxonomy/layout is terrific and maybe a short form of that in a menu or just some basic links in that style in the header could be helpful.
- Along those lines, it seems to make some intuitive sense to place a link back to freebasic.net somewhere. It's the top level of the site and I wanted to be able to reach it as I was browsing around today, but it wasn't obvious how.
- A subheading like "The most up-to-date FreeBasic help documentation on the web" could really be worth adding, in order to pick up users who want to understand the broader context and fit into it as best they can, for learning purposes. And where users go, Google wants to follow.
- Does the DB give you an idea of things like most popular pages? I am thinking that could yield some really quick wins for users who are just learning, or for repeat visitors, and Google would probably notice the results in a variety of ways.
Re: Wiki improvements
2 days ago an FBC's user reported that num pad key 5 (&h4C) was not listed in the scancode list.
Following this report I was playing with scancodes and
I found a bug in multikey function : num pad key 5 was not correctly responding whatever the driver used.
All of that have been quickly fixed by Jeff.
Now my suggestion, the 'inkey' page in the documentation could be completed :
- a note explaining that "L", "H" etc , used in the example, are the equivalent string values of the scancodes. It's not very obvious.
eg asc("L") = 76 = &h4C --> num pad key 5.
- a link to keyboard scancodes, like the one in multikey page.
edit 76 not 75....
Following this report I was playing with scancodes and
I found a bug in multikey function : num pad key 5 was not correctly responding whatever the driver used.
All of that have been quickly fixed by Jeff.
Now my suggestion, the 'inkey' page in the documentation could be completed :
- a note explaining that "L", "H" etc , used in the example, are the equivalent string values of the scancodes. It's not very obvious.
eg asc("L") = 76 = &h4C --> num pad key 5.
- a link to keyboard scancodes, like the one in multikey page.
edit 76 not 75....
Last edited by SARG on Jun 07, 2022 16:13, edited 2 times in total.
Re: Wiki improvements
(1)SARG wrote: ↑Jun 07, 2022 14:59 Now my suggestion, the 'inkey' page in the documentation could be completed :
(1)
- a note explaining that "L", "H" etc , used in the example, are the equivalent string values of the scancodes. It's not very obvious.
eg asc("L") = 75 = &h4C --> num pad key 5.
(2)
- a link to keyboard scancodes, like the one in multikey page.
This concerns the 4 keywords INKEY, GETKEY, MULTIKEY and SCREENEVENT.
The principle is explained in a page of the Developer's Guide: Keyboard Input ('Basics' paragraph)
I propose to refer to this in the 4 keyword pages concerned (in 'Description' and 'See also' paragraphs).
(2)
Agree also in the 4 keyword pages concerned (in 'See also' paragraph).
Re: Wiki improvements
I didn't know this page and not easy to find
Your proposals sound good.
Your proposals sound good.