Recent activity
Subscribe to this feed
Seanmac replied on August 20, 2008 08:47 to the problem "Insert Link Painful for large WIKIs" in PBwiki:
Emily Hummel replied on August 19, 2008 19:03 to the question "Consolidation of "Insert Link" list?" in PBwiki:
jac2 replied on August 19, 2008 17:48 to the question "Consolidation of "Insert Link" list?" in PBwiki:
jac2 started following the question "Consolidation of "Insert Link" list?" in PBwiki.
jac2 reported a problem in PBwiki on August 19, 2008 17:45:
Insert Link Painful for large WIKIsIncremental search / Better locate on insert WIKI Link dialogue.
Our WIKI is has 250 pages and I expect it to top 1000 when it is complete, well, when it heads toward maintenance mode. When you click "link" and select "wiki", you get a drop down of all the pages. This is really painful to find the correct page. Being able to do an incremental - match anywhere in the page name, would speed this up and make it a lot less hassle to add links to existing pages.
AFAIK you don't get a well maintained link if you just paste the URL into the edited page.
Shayne replied on August 14, 2008 16:10 to the idea "external links open in new window" in PBwiki:
Shayne replied on August 07, 2008 19:01 to the idea "external links open in new window" in PBwiki:
Rachel Pennig replied on June 26, 2008 15:02 to the problem ""edit link broken, for everyone, for me" or "My memory is going"" in PBwiki:
jac2 reported a problem in PBwiki on June 26, 2008 13:35:
"edit link broken, for everyone, for me" or "My memory is going"When I right click | Edit Link on a pbwiki link, I am sure it used to show the link dialogue as "wiki link" and the name of the page that the link pointed to, i.e. in the drop down.
Today it appears:
IE7 - like an external URL
Firefox 3- Like a new WIKI page.
Has something changed, was it never like I think it should be, can someone check their V1 WIKI?
mowyn replied on June 24, 2008 16:36 to the question "CSS Editor Changes" in PBwiki:
I had this same problem too. When I looked at the CSS in Firefox Web Developer, I saw that the PBWiki stylesheet had a number of declarations that were not in the stylesheet for the Minimalist skin.
They all start with: #displaycontent div.sidebar_v2. When I added them to my custom css with my settings I was successful in styling my sidebar.
Vu Nguyen replied on June 21, 2008 16:45 to the question "CSS Editor Changes" in PBwiki:
I am remember that bit of CSS now. With !important, if two identical selectors are used, then the last !important gets priority.
http://vupublictest.pbwiki.com/CSSExa...
And you're right, as a skin-designer and web-developer, Firebug has saved my life many times. Too bad IE doesn't have anything as useful.
jac2 replied on June 21, 2008 09:25 to the question "CSS Editor Changes" in PBwiki:
Vu,
As I should have said, I am not an CSS expert, in fact trying to debug the issue on mine was my 3rd foray into CSS.
See https://vs1.pbwiki.com/common_both-v0...
which I am pretty sure is before my CSS. Notice the "important" overriders. I am right in saying the first one it hits sticks aren't I?
Also see thread: http://getsatisfaction.com/pbwiki/top... toward the bottom.
My advice would be to use firefox + firebug and see what css attributes are being enforced and by which CSS.
Vu Nguyen replied on June 21, 2008 04:19 to the question "CSS Editor Changes" in PBwiki:
Actually jac2, I don't think I've seen !important being used in our built-in CSS very often. It's more likely that a complex order of cascades is going on and the most simple version of a declaration won't work. For example, let's say PBwiki defines h1's like this (I actually don't remember, and it's different for each skin anyway):
#wrapper-root #root div#displaycontent h1 { color:green; }
For you to get the header changed to red, you'd have to be AS specific, or MORE specific. Otherwise, this declaration would get precedence. For example, even the following would fail:
#wrapper-root #root #displaycontent h1 { color:red; }
You would have all the same steps, but since you did not define the element type for #displaycontent, it's not as good.
Furthermore, a problem where the blame is with us a little more is when we link our CSS after the user CSS, allowing our's to have the last say. For example, if we did something like:
<link href="/f/wiki.css" rel="stylesheet" />
<link href="sidebar.css" rel="stylesheet" />
Even if you DID get the declaration with the right priority/specificity, we would still be overriding it. So that's why with any user skinning, if you are having trouble, the best bet to try first is to use the !important keyword yourself, since we use it sparingly if at all and you can then override the built in styles.
Sorry for the longwindedness!
Vu Nguyen replied on June 21, 2008 04:07 to the idea "Hover over link to get a hint would be really useful." in PBwiki:
Most sites use the link tag's "title" field as a hover tip, such as:
<a href="http://pbwiki.com" title="Create a wiki!" >PBwiki</a>
Example: http://vupublictest.pbwiki.com/LinkHover
jac2 replied on June 20, 2008 09:54 to the question "CSS Editor Changes" in PBwiki:
This sounds like a problem I reported ages ago. It was that somewhere in the nested CSS's used by the developers of PBWIKI they had used an "important" tag, which AFAICS stops the property from being modified by later CSS's. My problem was that I couldn't change "Header1" font size and weight. It worked fine in the CSS editor, but ignored in the live WIKI.
After a lot of digging around and using firebug to work out what effective CSS was actually effecting properties I got to the bottom of it. Reported, but still a problem on our V1 wiki.
Not sure it if is the same, but sounds similiar.
jac2 shared an idea in PBwiki on June 20, 2008 09:48:
Hover over link to get a hint would be really useful.I want Hints on links.
Our WIKI has three distinct sections, IT techincal, one page per screen, Procedural and Background information. At the top of each page we cross reference, so in a Technical page I will link to relevant Procedure and Background information. Currently we have the text of the link and the link itself.
Wouldn't it be good if we could have a popup hint for the link?
A comment on the question "Seaching multiple words are EXACT matches" in PBwiki:
Tim- this is great! Thanks for pointing this out :) – Rachel Pennig, on June 10, 2008 17:58
Tim replied on June 10, 2008 17:51 to the question "Seaching multiple words are EXACT matches" in PBwiki:
jac2, since you said that you have a private wiki so can't let google in.. what you can do is use the google search appliance.
http://www.google.com/enterprise/gsa/
I've worked at a few places where we've used the google search tech to crawl our intranet (not data that's on the internet) and get good search results back from that.
Perhaps that would help you out?
Rachel Pennig replied on June 10, 2008 17:44 to the question "Seaching multiple words are EXACT matches" in PBwiki:
We're looking at ways to improve our search engine. Currently, wiki searches are exact word searches.
If you have a public wiki, you can install a Google Search bar for your wiki, instructions here: http://newfaq20.pbwiki.com/How+do+I#a...
So stay tuned, we're going to be improving this soon!
jac2 asked a question in PBwiki on June 06, 2008 09:53:
Seaching multiple words are EXACT matchesSearch is like doing a search in quotes on Google?
Unless I am wrong, then this is a hindrance to take up of our business wiki by users. I have just tested v1 & v2. Our problem is that generally we want search results to be weighted:
Exact match (excluding case) (i.e. words appear together and in the same order)
All words appear in title
All words appear in title or text
We can't let Google in as it is a private business wiki and so needs credentials. So am I right, if so, are there any plans to "improve" the search?
The business case is that the WIKI is getting large and users are not finding things quickly, which is reducing the effectiveness and adoption of the WIKI. I had just assumed the search would be Googlesque.
JAC.
| next » « previous |
Loading Profile...




