Print print print… The bane of my life recently. And all it takes to fix my beef with the dot is for print buttons to use the browsers' print function, bypassing this, now irritating "printer friendly" page. AAHHHHHH. Rant over.
Print print print… The bane of my life recently. And all it takes to fix my beef with the dot is for print buttons to use the browsers' print function, bypassing this, now irritating "printer friendly" page. AAHHHHHH. Rant over.
I'm curious. Why do you find the "printer friendly" function so irritating? I like that I can easily print just the page content and strip out the "wrapper" of the site (although I do wish I could turn off the option section at the top sometimes). If I need to print the full view of what's in my browser window, I can choose File > Print - I don't need a button on the web page I'm viewing to do that for me. Sure, it might be a bit more convenient, but I get 2 options this way. Am I missing something?
-Ed
I am working on this site: http://www.havemycv.com/
Where you can find my CV here: http://www.havemycv.com/will-stone
Now, as you can see, there is a print button on the right-hand side for employers to print-off the CVs.
If you push it, you'll see (because of the way the CSS on the site works) that it does not take away the background image. There is also the page revision, license and other various bits. People (especially employers who look through hundreds of CVs) will find this two-step print method irritating.
Browsers have had their own print function since, well, ever! So why add to the process?
Now, as you can see, there is a print button on the right-hand side for employers to print-off the CVs.
I already told you to put this print button outside the main-content of the page, i.e. in the nav:top.
Insert the following into the Divs that contain your print buttons and the contact form
class="noprint" "
@media print {
.noprint {
display: none; }
}
Now, I have another solution, that actually works : in action at
http://default-gerdami.wikidot.com/
Add some custom CSS to remove things not to be printed:
@media print { ... #license-area { display:none; } }
<A HREF="javascript:window.print()"><IMG src="/local--files/system:icons/print.png" width="46" height="42" BORDER="0"></A>
Nice solution, gerdami!
*****
5 Stars!
Follow the discussion about this:
http://community.wikidot.com/forum/t-181807/print-button-that-uses-the-browsers-print-function-not-wikidot-s
The first solution cannot get rid of everything required.
Your second solution would work fine if…
The forum topic explains all of the problems found so far.
because I inserted the following…
You've just pointed out a security hole in Wikidot that we're going to have to close… allowing raw HTML into pages opens the door for cross-site scripting attacks.
You've just pointed out a security hole in Wikidot that we're going to have to close… allowing raw HTML into pages opens the door for cross-site scripting attacks.
Damn you gerdami, why did you have to open your big mouth?
XD
@pieterh : So I deserve a Thanks !
@James: Boooh !
Whenever you go to a page that hasn't been created:
This content is the same across every wiki, every category, every page.
There should be a category:_create page, where you can choose the content that should appear on a non-existing page. This way, you can even choose if you want a “create page” link to exist or not (with [[button edit text="create page"]]).
Good idea! This would certainly be useful in personalising wikis.
GREAT idea! I'd start using this for sure! :)
Wouldn't have even thought to mention it…
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
I love the ListPages module, and use it all over my site as a way to generate news feeds and easy menus. But I'm having a problem finding the perfect balance for the preview options. Right now, I use this code:
[[module ListPages order="dateCreatedDesc" limit="5"]]
%%linked_title%%
[[size 80%]]%%content%%[[/size]]
[[/module]]
Using the "Content" variable shows the complete content of the page. Generally, the news updates are short and this is ok. But sometimes people post really long things and I don't want all of the content clogging up the feed.
I now have three, equally problematic options:
1. I can use the "first_paragraph" variable. But usually the first para is given over to dates and times, and I want the second paragraph's short descriptions to be visible.
2. I can use the "description" variable. But now I have the same problem as above, or I require people to know that they need to use the ==== separator every time. And I am trying to create a site in which even novices will feel comfortable using the tools.
3. I can use the "preview(n)" variable. In fact, this is my ideal. But! Alas, I have templates formatting these pages behind the scenes, and the preview variable weirdly picks up all this stuff instead of delivering direct content.
Is there any way to have a variable like the "preview(n)" variable but only for actual content?
You can see the problem in action here
I've been teaching my Dad to use Wikidot to build a site for his Association. Here's a couple of things that came up while I was watching him go through the steps of creating some new pages and using the page link wizard to add links between them:
1. Clicking on the Page Link Wizard does not move focus into the Page Name box in the dialog but instead leaves it in the Edit box on the lower layer. This is really annoying, since Dad tends to start typing the page name straight away and then gets really confused when no text appears anywhere that he can see! I'm sure this is fixable in about 10 minutes by going through the various Wizards and adding some focus() calls.
2. My Dad is 73 years old so his eyesight is not that great anymore. The font in the Edit box is a bit on the small side, especially if you want to keep track of the spellchecker while typing. This could be hacked around by some custom CSS in the site theme, but that'd change it for all the site's users. I'd suggest making this a preference in the user's account options.
A friend just asked to be added as a member of one of my sites. He already has a Wikidot login, but he only sent me his email address. In the site manager Invite Members box you can only invite users by their screen name, not by their email address. So now I have to ask him to tell me what his screen name is, assuming he knows it!
Teach your dad to use Ctrl +/- to zoom the text size of his browser in and out. Ctrl - zero restores the size to default.
-Ed
I could do that, but it's one more thing to teach him, which means one more thing to remember, which is not easy when you're 73. I'll see if I can do something magic in his Firefox user.css to increase the font size.
Creating a userContent.css with the following works nicely:
@-moz-document domain(wikidot.com) { textarea#edit-page-textarea { font-size: 130% !important; } }
More useful examples are found at coreygilmore's per-site-custom-css-in-firefox.
Very cool! With tips like this, I hope you won't be a stranger around here.
Thanks for sharing that!
-Ed
Ctrl +/- to zoom
Unfortunately, Ctrl +/- only works well with Firefox.
With IE7, the whole page is zoomed In/out just like a picture and it becomes unreadable. Hooo IE !
Hey Mato, nice to see you here!
I've raised an issue for the Wizard focus() calls. For the font size, I tend to just use Ctrl-Mouse wheel to expand the font size. Not perfect but works on any site.
It is true that inviting users by email address would be a lot easier. Am also raising an issue on that.
My rant is how the weneed section has 27 votes for easier registration, that has been suggested for years, and is the fundamental problem that users have, and why they leave. So why has this not been changed?
My other rant is that we don't have a XWL or a eXtensable Wikidot Language, to do advanced tasks with. That is a rant to be solved another day though…
EDIT: BTW, We want autosave!!!
Alright, see ya next tuesday…
I think I've come up with a way to emulate auto-save for the NewPage module. I got really excited actually, until I realised that the Redirect module doesn't accept wiki syntax!
Adding this to a page named thispage
[[module NewPage category="cat" parent="thispage"]]
Adding this to a page called cat:_template
[[module Redirect destination="/%%parent_fullname%%"]]
This assumes that the cat category will always require autosaving, and that pages in that category will always be given a parent using the NewPage module.
Problem: This doesn't work as the Redirect module doesn't accept the %%parent_fullname%% variable.
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Fix this, as in give you a solution to the problem? Or fix this, as in, make variables work within the redirect module?
Meh, I'll give you a solution anyway: iframe Redirect
Well, I was asking for variables to be supported… didn't know there was another way to do it.
Looking at that… it needs a URL. Sounds like %%parent_fullname%% might work — time to give it a shot =)
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
[[module Categories]]
please?
Thanks to Erich:
http://snippets.wikidot.com/code:module-categories
http://steinboeck.wikidot.com/test:module-categories
Still not officially documented, but he made an effort to cover it by (I assume) reading through the WDOS source code.
-Ed
I've added a documentation page here: http://doc.wikidot.com/module:categories
As this is where the official documentation will be in future, it's probably best to add it there directly and not worry about adding it to www.wikidot.com/doc ?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
thank you gentlemen.
As this is where the official documentation will be in future, it's probably best to add it there directly and not worry about adding it to www.wikidot.com/doc ?
I disagree. We should add documentation to the current advertised resource as a priority and keep that up-to-date, until such time as it is superceded. As far as I am aware, the new resource is still under development, so it is not yet the place to look when one needs a reference. However, there is no harm in updating that also.
I fully agree with Sue (and her nice dog).
I've created the documentation page for the Categories module.
The current documentation site will be the primary reference until the new site is properly working and all content migrated. That is some time away.