Description
Here's a half-baked solution for discussion thread “TOC's from many pages displayed on one?”
Although this allows you to pull in the TOC's, they aren't linking to their respective pages (but to the current page instead) and fold/unfold only works for the first TOC.
Code
[[module ListPages category="code" limit="9" order="pageEditedDesc"]]
[[table]][[row]]
[[cell]][[[%%page_unix_name%%]]][[/cell]][[/row]]
[[row]]
[[cell]]
[[div style="display : none"]]
[[include %%page_unix_name%%]]
[[/div]]
[[toc]]
[[/cell]][[/row]][[/table]]
[[/module]]
In action
| hide-tags | |||||||||||||||||
DescriptionThe Tag Cloud module does not allow for the hiding of specific tags. This CSI allows you to specify which tag names you want hidden up to 99. The CSI works with the 2D tagcloud only. Syntax
Code[[include :snippets:hide-tags Note: You do not need to explicitly define all 99 tag options; only list the ones you need. If you need additional tag slots, simply place a second copy of this CSI on the same page with the additional tags, starting at 1. In action |
| custom-html | |
DescriptionSince the introduction of [[html]] blocks, users have been able to easily embed external web content easily. The following Javascript code captures HTML blocks' ability to automatically resize itself, allowing any iframed code blocks to be resized automatically too! CodeThe following code goes into the code block: <!-- Insecure Version --> <script type="text/javascript" src="http://snippets.wdfiles.com/local--code/code:custom-html/1"></script> <!-- HTTPS Version --> <script type="text/javascript" src="https://snippets.wdfiles.com/local--code/code:custom-html/1"></script> The following code is required to embed the code block:
Please note, the following are required:
In actionComing soon… |
| per-user-css | |
DescriptionThe basic purpose for this technique is so we can apply CSS rules that override some default CSS settings on a per-user basis. For the purposes of this article, we'll create a couple of CSS classes that will hide data for all users by default. We'll create 2 classes — one for hiding block elements and one for hiding inline elements. Then, we add the CSS for our default state to the nav:side page (would also work with nav:top)). We'll also add a ListUsers module that will render the CSS to override the default for individual users that we specify. BackgroundThere is a great snippet written by James Kanjo called Specific Users Only Include. I have used that snippet many times since he created it in April of 2010. There are 2 issues with the SUO Include. The first is due to restrictions and limitations of Wikidot: The use of Modules inside the SUO code is prohibited. The second is a minor complaint: If you have a lot of pages that use the SUO code, it can be hard to maintain. This is especially true if you have to frequently edit the list of specific users. Another idea by James (Per-category CSS), where he made use of the fact that our sites navigation pages are almost always "present" (but not necessarily visible), got me thinking about a different way to control the display of data to specific users. What I like about this technique is that you can use it inside modules and maintenance is much easier. A note about securityThis technique does not securely hide data from those who know where to look. Anyone viewing the HTML source of your pages will be able to see the content that is hidden using this technique. Set up nav:side to hide data by defaultAdd this code to your nav:side or nav:top page:
Create the override CSS "master" pageCreate a page called css:admin-css with this code:
Create individual user pagesFor each user that you want to apply the per-user CSS code to, create a page called css:user-name where user-name is the Wikidot unix name of the user. For example:
How it worksThis technique takes advantage of the ListUsers module by replacing %%name%% above with the Wikidot unix name of the user who is currently logged in. If the page name created inside the ListUsers module code matches the per-user page name you created, the page to be included exists and the CSS on that user's page will become active, overriding the default CSS. If there is no match, the page to be included does not exist and the default CSS for our two classes is not overridden. We wrap the ListUsers module in a display: none div block so that the normal error message generated by the include syntax when a page doesn't exist is not visible. But, visible or not, the code in a CSS module will always be active. Example for block elementsYou'd like to have an admin menu that is visible to only authorized users of your site. You can add something like this to the bottom of your side navigation page (nav:side):
Example for inline elementsYou'd like to display a list of recipes you've collected on your site with links to the pages for all users. You'd also like to display an option where admins or other authorized users can go directly to edit the recipe pages.
Maintaining usersThe thing I like about this technique is that it's very easy to add and remove users who are "authorized" to view certain content on my sites. To add a user, I just create a new css:user-name page. To remove a user, I simply delete the css:user-name page. Other possibilitiesIt would be possible to create multiple levels of visibility by creating multiple pages to be included. For example. you might expand on this idea by creating these pages: Then you would just have to add a new set of CSS classes for each group:
Then on the css:user-name page, just include the appropriate css page for that user. Using the recipe list example from above, you might change it to look like this to allow editors and admins to see the edit link:
The admin user's page would look like this:
The editor user's page would look like this:
I'm sure you can come up with other uses as you explore this technique. Have fun! In ActionI have set up a small demo on the community playground: |
| 404-redirect | |||||||||||
DescriptionNote: as of the 19th November 2012, Wikidot has implemented a full solution which no longer requires this snippet. View their solution here. While Wikidot is a wiki platform, some users might wish to show users a more useful message when a page doesn't exist. With this snippet, you can redirect users to a custom 404 page and still get access to create the page using the standard /edit/true URL tags. Following the tradition of James' JS-based snippets, I too will show the "framework". Attributes
CodeYou will need to copy the code into the side bar (usually nav:side):
Link to editYou can also include a link to create the page that wasn't found. Simply add the following line to your 404 page:
In actionIt's currently in action on the Community site as well as in my personal sandbox: Wikidot Community: My Sandbox: Changelog
|
| genuinely-random-link-generator | |
DescriptionUp until now, there were two ways to create random links:
Based on the second method, I've figured out a way to combine ListPages and Javascript to provide genuine randomness without having to wait for the ListPages module to re-shuffle. There are two versions of this method. The first is easy to implement, but requires two page redirections. The second is harder to implement and involves the use of i-frames, but cuts the process down to only one redirection. InstructionsSimple Version (2 page redirects)1. Create a link in the Sidebar to the page 'nav:random'. 2. Follow the link, and create the page 'nav:random' with this code:
Note: After saving the page above, you'll be redirected to 'nav:random-redirect'. 3. After being redirected, create the page 'nav:random-redirect' with this code:
Now you've got a random-page link on your sidebar that can clicked as frequently as you like without caching its results. (Note: If you need to edit or delete the pages, add '/norender/true' to the end of the page address.) Complex Version (1 page redirect)1. In the Sidebar, add the line below: (replacing "<WEBSITE ADDRESS>" with the address of your website, e.g. "http://venryx.wikidot.com", and replacing "17px" with an appropriate height for the link we're about to put on your sidebar.)
2. Create the page 'nav:random' with this code: (replacing the CSS between the "<style>" tags with whatever gets the link to look like the others on your website's sidebar. (you may need to "Save & Continue" the page and view the sidebar on another tab to get the link to look right, and you may need to look through your website's CSS file as well.))
Now you've got a random-page link on your sidebar that can clicked as frequently as you like without caching its results. (Note: If you need to edit or delete the pages, add '/norender/true' to the end of the page address.) In actionThe complex version: http://gustrength.com |
| per-category-css | |
DescriptionSomething that's slightly annoying about Wikidot is that when it comes to creating new pages that previously didn't exist, the Live Template isn't taken into account. That is, if you use the CSS module in the Live Template, then that isn't applied to the page until after you save the page. All proceeding edits work fine, but the initial edit doesn't look how it's supposed to. But of course, they don't call me a Wikidot Super-Guru for nothing! Read on to see how it's done properly. CodeNavigate to your sidebar navigator page and place the following code at the bottom:
This Wikidot code will extract the source from the :_css page on a per-category basis. If no such page exists, nothing happens! If you happen to have no sidebar navigator on your Wikidot site, click here for further instructions. Now simply create your per-category CSS page. Let's assume the category "survey". We are going to create a hidden page called /survey:_css for us to store our CSS module on. Place your CSS module on this page like so:
This line of CSS code will ensure all links appear in the colour "white". SourceAs taken from my blog post Wikidot: CSS Per Category No SidebarIf you don't have a sidebar on your Wikidot site, I suggest that you:
|
| advanced-search | ||
DescriptionThere is a CSI Function available from Keneth
CodeHello Fellow Wikidotians,
"Now, that's all good", you may say. "So, how do you do it?" Installing the new Advanced Search module is not advanced at all! I'll provide you with a couple of snippet examples for you to copy and edit to suit your needs. For each of these, simply copy the code displayed here and replace the Search Module in your wiki's search:site and vola! Let's begin: "Simple" Advanced Search"Simple" Advanced Search simply replaces the current search module with one with three extra filter fields for title, author and category. [[include :csi:include:adv-search]] Renders this: NOTE THIS IS A DUMMY Change the labelThis is similar to the "Simple" Advanced Search - except you are able to define the search button text. This example changes the default "Search!" text with "Find me!". [[include :csi:include:adv-search text=Find me!]] Renders this: NOTE THIS IS A DUMMY Hiding filtersThis is similar to the "Simple" Advanced Search - except you are able hide certain filter fields. This example hides the title filter field. [[include :csi:include:adv-search showTitle=none]] Renders this: NOTE THIS IS A DUMMY Setting default valuesThis is similar to the "Simple" Advanced Search - except the filter fields can have a default value. This example shows the default title value as being "community". [[include :csi:include:adv-search defaultTitle=community]] Renders this: NOTE THIS IS A DUMMY Enforcing default valuesThis is the most powerful option of all. It is able to define a default filter criteria and enforce it. In this example, you may set the default search filter to be only searching pages from the _default and doc categories. You are then able to enforce this be not allowing the user to change this option. Even if changed, the final search result will end up displaying the results with the default filter applied. Finally, the category filter is hidden to prevent users from wanting to change it. [[include :csi:include:adv-search Renders this: NOTE THIS IS A DUMMY Wasn't that easy!? Copy and paste :) ~ Kenneth Tsang |
| custom-permissions-error-message | |
DescriptionThe standard permissions error message that pops up has messages preset by Wikidot. Using a bit of CSS you can customize this message in a way that might better fit the needs of your site. For example, you have a site that is exposed to the public, but is only edited and maintained by you or a small group of users. The default permissions error message includes a rather generic message that says, "Only site administrators and perhaps selected moderators are allowed to do it." Well, there's no "perhaps" about it in this example! We don't want anyone else editing our page! Similarly, if an unauthorized user tries to create a new page, the default error message says, "Sorry, you can not create a new page in this category. Only site administrators and perhaps selected moderators are allowed to do it. Sign in as Wikidot user" and contains a link to sign into Wikidot. Again, it would be nice to have a simpler message that relates to our site and removes any references to Wikidot or signing in. Here is an example of a couple of standard error messages: ![]() ![]() With some simple CSS edits, we can customize the look of these messages: ![]() CodeAdd this to your site's custom CSS. Note that some of the colors and margins may need to be edited to match the current theme of your site. /* Permission Errors ============================== */ /* Title bar of the error window */ #ohandle-1.title { color: #F5F5F5; /* set the color to match the background color to hide the default text*/ } #ohandle-1.title:before { content: "Administrative Use Only"; /* display this content before the title text */ color: darkred; /* change font color if you wish */ font-size: 18px; /* change font size if you wish */ } /* completely hide the paragraph text with the default Wikidot messages */ #owindow-1.owindow p { display: none; } /* Hide "Please Note:" text*/ #owindow-1.owindow h1 { color: white; } #owindow-1.owindow h1:before { content: "Sorry, that option is for administrative use only."; /* display this before the "Please Note" text */ color: black; /* change font color if you wish */ font-size: 18px; /* change font size if you wish */ } In actionThis technique was implemented on this site: mascot-golf (try pressing CTRL-E on the home page to see the customized error block) |
| display-random-video | |
DescriptionThanks to ListPages, having a random video display on your site is easy. You would start by creating a category in which to display each video by pasting the embed code from each youtube video within an [[html]] block, one video per page. For example: video:1, video:2, video:3, etc… Then use listpages (code seen below) to randomly display 1 video and place the listpage code where ever you wish for your random video to be seen. The Random order option will refresh every 60 seconds. I like to put videos in the side bar and using this method helps to keep new videos appearing for visitors that like fresh content. Code
In actionYou can see this in action on my Wikidot Random Video page.. Refresh the page about a minute after you arrive and you should see the video in the sidebar change. There is a slight chance that the same video will appear twice in a row. The more videos you have in the rotation, the least likely this is to happen. reSourcesWikidot Categories |
Thanks to tsangk for this great snippet: conditional-blocks
text above inserted with:
[[include :snippets:if START |unique=1|type=equal|var1=%%name%%|var2=conditional-blocks]]
**##red|Thanks to tsangk for this great snippet:##** [[[code:conditional-blocks]]]
[[include :snippets:if END]]
Other snippets posted by ErichSteinboeck
Redirect: To - 16 Feb 2012 01:37
Module Listpages Tags - 16 Feb 2012 01:24
Module Feed Drilldown: Details Page - 16 Feb 2012 01:24
Module Feed Drilldown - 16 Feb 2012 01:24
Module Feed: Collapsible - 16 Feb 2012 01:23
Module Categories - 16 Feb 2012 01:23
MiniRecentPosts With Limit - 16 Feb 2012 01:23
ListPages: Horizontal? - 16 Feb 2012 01:20
Choose A Page! - 15 Feb 2012 00:32
Redirect: From (1st) - 01 Mar 2009 18:18
Redirect: From (2nd) - 01 Mar 2009 18:17
Rate this solution
If you think this solution is useful — rate it up!









I put two rows, instead of one, it is neater, and all tocs are aligned…. Hope you don't mind, Erich!
Vir bonus miser vocari, at esse non potest miser.