Re: [pmwiki-users] A decade
Happy birthday Petko! Keep up the great work! On 7/19/2019 10:26 PM, Simon wrote: It's a bit belated, but is been a decade since Petko, in Jan 2009, took over the day to day work of maintaining PmWiki Thanks Petko for keeping PmWiki alive, and more than that updating it for newer versions of PHP, fixing security issues, and even updating recipes written by others. It's because of your hard work that I've been able to keep the websites I maintain going and current and haven't suffered the pain of having to change platforms thanks again Simon PS also thanks for Thumblist2, for me this is the "killer add-on" that makes PmWiki the best and easiests platform to handle the photos on all my websites http://kiwiwiki.nz ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Blogit (:includesection:) problem after upgrade
> if you replace your sidebar inclusion text with (:if equal
> {$bi_BlogIt_Enabled} 1:)XXX(:include Site.BlogIt-SideBar:) so you see
> the XXX? If not, then very likely the BlogIt code isn't loading (and
> bi_BlogIt_Enabled hasn't been set to true).
As Peter suggests, from a quick look at your site, it doesn't look like
BlogIt is actually being activated, which explains why you just see the
untranslated BlogIt markup. So first, work out why it's not being activated.
Also, depending what version of bBlogIt you're upgrading from, make sure
you take a look at the upgrade steps. Might be a few things you have to do.
~ ~ Dave
On 5/12/2017 12:17 PM, Peter Kay wrote:
if you replace your sidebar inclusion text with (:if equal
{$bi_BlogIt_Enabled} 1:)XXX(:include Site.BlogIt-SideBar:) so you see
the XXX? If not, then very likely the BlogIt code isn't loading (and
bi_BlogIt_Enabled hasn't been set to true).
Do you have access to the php/web server error logs? They might tell you more.
Hopefully someone else will have better ideas!
--Peter
On Fri, May 12, 2017 at 8:17 AM, Caissa wrote:
Hi PmWiki users,
after a php server upgrade and a following PMwiki and BlogIt upgrade I
suspect, that (:includesection:) is broken.
The Startpage is "Main" and most other pages are in the main-group.
The blog has its own group "Blog" and the Blog-entries shall be shown in
Blog.Main.
now after the pmwiki and blogit upgrade Blog.Main shows:
(:includesection "#blog-summary-pagelist blogid=blog1 status=sticky":)
(:includesection "#blog-summary-pagelist count=12 blogid=blog1
status=publish":)
instead of including the section.
The same goes for the Startpage, where (:includesection:) is used to inform
about new blog-entries as well as the sidebar, where
(:if equal {$bi_BlogIt_Enabled} 1:)(:include Site.BlogIt-SideBar:)
(:else:)
(:if:)
displays nothing.
I suspect PMwiki doesn't know where the blog is!?
It might be a basic question, but after 2 hours searching and trying I am
still unseccessful.
thx guys and girls
Caissa
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Blogit Tags
On 10/26/2016 11:45 PM, michael paulukonis wrote: After I've upgraded from 1.7.0 to the Blogit 1.9.5 (running on pmwiki-2.2.91 and PHP 5.6), my Tags stop displaying in the posts. I haven't tested this with a default theme yet - I'm using a custom one, but tags displayed prior to update. There were a lot of changes between 1.7 and 1.9.5, particularly to BlogIt-CoreTemplate in 1.9.0, so this is where you should probably start (ref http://www.pmwiki.org/wiki/BlogIt/ReleaseHistory). There were also a bunch of tag related fixes as well. Use a default theme, and see what you get. Compare CoreTemplate against your theme specific changes. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt demo links
On 4/20/2016 9:15 AM, michael paulukonis wrote: The main BlogIt page (http://www.pmwiki.org/wiki/Cookbook/BlogIt) links to a demo sandbox that is not available: http://wiki.solidgone.org/BlogIt/Main Thanks for letting me know. Should now be up and running. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PHP Version
On 4/8/2016 11:17 AM, Kevin Hayes wrote: One of my servers was recently upgraded to PHP 5.5, with the resulting preg_replace errors. I can troubleshoot it and fix it, but will want to relocate temporarily to a server running an earlier version. Will 5.4 work? Any other suggestions? 5.5 should work. If you're using cookbooks they may need to be updated, or may not support 5.5. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] ANN: BlogIt 1.9.1
Finally got around to updating BlogIt! Recent releases include PHP 5.5 compatibility, lots of bug fixes, and a few new features for bulk administration of comments. Plus a few new things: * Add mechanism to bulk administer comments (delete, block, un/approve). * Turn off comments after defined period from initial post (ie, '2 weeks ago', '-1 months'). Ref $bi_CommentsAutoClose. * Using print link now works. * Groups can now contain spaces/hyphens. * Updated all dependent libraries. Detailed release info can be found on http://www.pmwiki.org/wiki/Cookbook/BlogIt ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Page Updated Blocked
I'm trying to update the Cookbook.BlogIt page, and receive an error: "Text blocked from posting: /antivirus.*help.*desk|0nline.*tech.*desk|Customer.*Care|Support.*Number/i" To my knowledge these string are not present in the page. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Alphabetize by Title Without Leading Articles or Special Characters
Also, as reference, this website http://regexr.com/ is really helpful in
explaining what a regex is going to do. Over over each element and it'll
explain what that element means. Click the Explain tab at the bottom for
a written explanation of the whole expression.
~ ~ David
On 3/20/2016 6:00 PM, Petko Yotov wrote:
You can use a search pattern like this:
'/^ *"?(The|An?) +/i'
This assumes that the quote always comes before the rest of the title.
The question mark after the quote means that there can be zero or one
quote, like the question mark after the An means that there can be a
single "n" or none (both artcles A and An will be found).
In some languages (French) typographical rules may require to have a
space between the quote and the text, in that case you could have
'/^ *"? *(The|An?) +/i'
the asterisk after the space means that there can be zero or more spaces.
The plus after the last space means that there can be one or more spaces
after A, An, The.
In most cases, several regular expressions can be written to match the
exact same strings.
The pattern on the cookbook has a tiny optimization but is harder to
understand for a beginner. In most cases, several regular expressions
can be written to match the exact same strings, you can have fun. :-)
Petko
On 2016-03-20 21:21, Jake Wartenberg wrote:
I suspect this is a pretty basic regex question. I have quotation
marks at
the beginning of some of my titles, so I modified the TitleNoArticle
function from the CustomPagelistSortOrderFunctions Cookbook page:
'preg_replace("/^ *((?:The|An?) |\")/i", "", (@$page["title"] ?
$page["title"] : $AsSpacedFunction($name)), 1)';
This works great for discarding the leading quotation marks, but I run
into
a problem when I have *both* a leading quotation mark and an article
(the/a/an) at the beginning of my title, in which case the page gets
alphabetized under the article. I would be really grateful to anyone who
could show me how to modify the function to account for this.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] IP Address
NB: Looks like devel list is down -- this is a cc to user list. Is there an existing function which would return the IP address of the initial creator of a page? Perhaps some sort of pagelist function? It seems like this would be the lowest 'host:' in a pmwiki page file. Is it safe to assume this would always be the last thing in the file, or is that just due to my setup? ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Link Markup with Classes
On 3/7/2016 12:37 AM, Petko Yotov wrote: Yes, unfortunately, %apply=link% will apply the styles to all links on the same line. You need a line break, for example: * %apply=link class="A B"%[[url | A]]%% - %apply=link class="C D"%[[url | B]]%% Unfortunately this doesn't work well with $HTMLPNewline = ''; enabled. Is there perhaps some markup to temporarily disable the HTMLPNewLine within the markup? Something like: * >>ignoreBR<<%apply=link class="A B"%[[url | A]]%% - %apply=link class="C D"%[[url | B]]%% ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Link Markup with Classes
I'm trying to apply classes to separate links on a single line. %apply=link class=A%[[url | A]]%% - %apply=link class=B%[[url | B]]%% Expected is class A on the first link, and class B on the second link. What actually happens is class B on both links. What is the correct markup to use? Note, that my actual use case is much more complex, more along the lines of: * %apply=link class="A B"%[[url | A]]%% - %apply=link class="C D"%[[url | B]]%% Thanks, ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Custom PageVariables from request strings: critical vulnerability
On 2/28/2016 4:28 AM, Petko Yotov wrote:
No, htmlspecialchars() is not vulnerable per se, what is vulnerable is
that the string you store in a $FmtPV variable will be evaluated and run
by PmWiki as PHP code. So it is a bad idea to store in that variable
things that other people wrote on the wiki or in the web forms, or in
the URL address -- $FmtPV was never intended to be used this way.
Instead of {$PageVar} you can use in your forms {$$RequestVars} for
example in pagelists: these are not vulnerable, you don't need to do
anything. Or, for needs other than pagelists/searches, the recipe
"HttpVariables" provides access to request strings without evaliating them.
Even if you sanitize the stings, a future PHP upgrade may include a new
way to compromize the site. So, don't evaluate random strings. :-)
Ah, so it's the act of storing user input into $FmtPV which is the
problem. This helps clarify the problem. Initially it appeared that
assigning $_REQUEST to any variable was the issue.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Just found out that my wiki title is enormous
On 2/6/2015 10:15 AM, erik burggraaf wrote:
Thank you, This is super helpful. For the logo height and width, can I change
those to per sentages if I use $SkinWidthUnits='%' in config.php? I would go
ahead and try this but I won't be able to see the result and I'd like some
reassurance. :)
As a general rule unless you are making more significant modifications
you can make most changes from config.php. In this case, set:
$HTMLStylesFmt['enlighten'] .=
'#header #logo-box { width: 100%; } ';
Untested, but that should prevent the title wrapping.
~ ~ David
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] photo galleries examples
On 12/17/2014 2:29 AM, jdd wrote: this one is over http://www.pmwiki.org/wiki/Cookbook/PmGallery#demo this one broken (is it the same?) http://wiki.solidgone.org/Galleria/Main from http://www.pmwiki.org/wiki/Cookbook/Galleria They are not the same, but both related. Looks like a config on the server got changed. I'll look into it. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki-based site is broken
On 12/16/2014 5:59 PM, Petko Yotov wrote: I believe this was fixed in recent BlogIt versions; the part [_-\w] should probably be written [-_\w] So try with the latest BlogIt version. Actually, I haven't released the fixed to a production release yet. Should be soon. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] preg_replace (RFC)
On 12/4/2014 3:55 AM, Hans Bracker wrote: I vote for option 3. It is easy to understand and troubleshoot the problem. I think you are right. It should not be expected for a site admin to fix the problems introduced by the update to PHP 5.5, which was most likely not done by her/him anyway. To be able to identify which recipe scripts or skins are generating these error messages would be nice. Partly PHP does this and points to the script and code line involved. An admin should hopefully be able to see by this what recipe is involved, and check if there is an updated PHP 5.5 compatible version available. Otherwise contact the recipe author or mention the problem here on the user list, where someone else may be able to help to fix the recipe. I have been relying on such error feedback from users about scripts I authored or co-authored. But there are many PHP error messages pointing to pmwiki.php, which are not caused by pmwiki code directly, but by use of the Markup() function in recipes and skins using the /e modifier in the regular expression. I think Petko did a good job adding a PmWiki error message in such cases, which identifies the offending regular expression. But how can a site admin work out in which recipe or skin script this regular expression pattern is? Because that is not clear from the error message. A Markup() call with /e modifier could be anywhere, and an admin would not know, unless s/he has a good idea about the scripts involved and the regular expressions. One could make a text search on all cookbook and skin scripts for the offending regular expression pattern, I guess. So this is not an easy way to identify offending code and scripts. Still Petko provided a handle and I am grateful for that! Could PmWiki be more specific to identify in which function call and script offending regular expressions reside? I don't see how. Agree with this sentiment, and option 3. If we could somehow guide admins in tracking down exactly where errors are occurring, beyond the pmwiki.php end point I think that would help a great deal. Perhaps an option to provide more of a stack trace -- although like Hans, not sure how that could be done. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] EnableDrafts and PmForm
On 11/12/2014 3:23 PM, michael paulukonis wrote: I look forward to the distinct recipe to be written some day as this would allow previews for BlogIt. I recall looking at implementing a Preview feature to BlogIt, and deciding it was going to be tough. At least on the surface, it would seem that a draft capability to PmForm would be a major step in being able to implement a preview feature. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fix blogit for use with PHP 5.5
On 11/1/2014 3:07 PM, Petko Yotov wrote:
I went
ahead and used anon functions with Markup, just to make things
internally consistent.
This is fine as long as your recipe is intended to only work with PHP
5.3 and more recent:
http://php.net/manual/en/functions.anonymous.php
Ah, I was not aware of that. I'll update the wiki to make that clearer.
In which case, I'll take the same approach as PmForm, and test for
Markup_e, and use that, otherwise use the original behavior.
3. All: Any suggestions for this:
$bodyTags = (preg_match_all('/\[\[\!(.*?)\]\]/e', $body, $match)
?$match[1] :array());
To be honest I'm not entirely sure why the e modifier is used
there, but assuming it's needed, do we have Pm helper functions for
preg_match_all?
The e part should not be needed - it is ignored by preg_match_all().
Thanks.
Also, thanks to John, and Tiger!P -- your input is appreciated.
~ ~ David
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fix blogit for use with PHP 5.5
I'm looking into PHP5 compatibility right now. Not progressing far, as I
need to research exactly what I'm remediating, but hopefully have some
progress soonish.
~ ~ David
On 10/30/2014 1:58 PM, Tiger!P wrote:
On Thu, Oct 30, 2014 at 02:17:58PM +1300, John Rankin wrote:
On Mon, Oct 27, 2014 at 10:22:17AM +1300, John Rankin wrote:
Hello John,
[cut how to fix the Markup('blogit' line]
This does not result in the error message, but when I go to the new blog
page (/Site/BlogIt-Admin?action=bi_ne ) some blogit codes are displayed
on the page. I don't know if this was the case before PHP5.5, but don't
think so.
Blog Title: (:blogit list $:entrytype:)bi_PageType/Type:
(:blogitend:)(:blogit list $:blogid:)bi_BlogList/BlogID: (:blogitend:)
Tags: (:blogit list $:entrystatus:)bi_StatusType/Status:
(:blogitend:)(:blogit list $:entrycomments:)bi_CommentType/Comments:
(:blogitend:)
This problem still exists.
And now the /Blog/Main page does not have any blog posts anymore. Also
the list of recently written is empty.
But the Categories contains a list of tags and when I select a tag, I
see a link to the blogpost which has that tag.
So I think something is not quite right yet.
Hopefully DaveG can give some advice.
When I save the new blog entry, I get still some deprecated messages:
PHP Deprecated: preg_replace(): The /e modifier is deprecated, use
preg_replace_callback instead in
/home/tigerp/www/pmwiki-2.2.62/pmwiki.php on line 471
So I think a little bit more needs to be done.
It looks like there are a number of instances of the /e modifier which
need to be changed.
In $bi_MakePageNamePatterns, it needs to remove the e, then use and
PCCF(return utf8toupper(\$m[1]);) and PCCF(return strtoupper(\$m[1]);)
This solved the issue of the deprecated warnings in the log :-)
Thank you for that.
Then all 3 calls to Markup need to be updated, in the same way as the
'blogit' rule.
I already did that before.
Attached is a patch for blogit.php with the changes I made sofar.
Tiger!P
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fix blogit for use with PHP 5.5
On 10/30/2014 1:58 PM, Tiger!P wrote:
This does not result in the error message, but when I go to the new blog
page (/Site/BlogIt-Admin?action=bi_ne ) some blogit codes are displayed
on the page. I don't know if this was the case before PHP5.5, but don't
think so.
Blog Title: (:blogit list $:entrytype:)bi_PageType/Type:
(:blogitend:)(:blogit list $:blogid:)bi_BlogList/BlogID: (:blogitend:)
Tags: (:blogit list $:entrystatus:)bi_StatusType/Status:
(:blogitend:)(:blogit list $:entrycomments:)bi_CommentType/Comments:
(:blogitend:)
This problem still exists.
And now the /Blog/Main page does not have any blog posts anymore. Also
the list of recently written is empty.
But the Categories contains a list of tags and when I select a tag, I
see a link to the blogpost which has that tag.
So I think something is not quite right yet.
Hopefully DaveG can give some advice.
I suspect this error is not related to PHP5. I've applied your patches,
and the test site seems to work (ref http://wiki.solidgone.org/BlogIt/Main).
For others testing this out, ensure you have updated to the latest
version of PMWiki, load the new version of PmForms, ensure your skin is
PHP5 compatible, and ensure other cookbooks you include are also compatible.
Quick questions:
1. Tiger!P: With your patch file, why are you making the change to
$PageTextVarPatterns, from #blogit_(\w[_-\w]*) to #blogit_(\w[_\w-]*)?
2. All: Is there a preference to using Markup_e over Markup? I went
ahead and used anon functions with Markup, just to make things
internally consistent.
3. All: Any suggestions for this:
$bodyTags = (preg_match_all('/\[\[\!(.*?)\]\]/e', $body, $match)
?$match[1] :array());
To be honest I'm not entirely sure why the e modifier is used there,
but assuming it's needed, do we have Pm helper functions for preg_match_all?
~ ~ David
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Fix blogit for use with PHP 5.5
On 10/23/2014 3:24 PM, Tiger!P wrote:
The original code line is (line 239):
Markup('blogit', 'fulltext', '/\(:blogit
(list|cleantext)\s?(.*?):\)(.*?)\(:blogitend:\)/esi',
blogitMU_$1(PSS('$2'), PSS('$3')));
I replaced it with the following:
Markup_e('blogit', 'fulltext', '/\(:blogit
(list|cleantext)\s?(.*?):\)(.*?)\(:blogitend:\)/si',
blogitMU_\$m[1](PSS(\$m[2]), PSS(\$m[3])));
But this results in the following message in apache's error.log:
PHP Parse error: syntax error, unexpected '$m' (T_VARIABLE) in
/home/tigerp/www/pmwiki-2.2.62/pmwiki.php(458) : runtime-created
function on line 1
I have not yet looked into updating blogit to work with php5.5, but
purely based on reading ref [1], and purely based on syntax, you may
need to simply quote the $m parameters in the $replace part of the markup:
Markup_e('blogit', 'fulltext', '/\(:blogit
(list|cleantext)\s?(.*?):\)(.*?)\(:blogitend:\)/si',
blogitMU_\$m[1](PSS('\$m[2]'), PSS('\$m[3]')));
Let me know how that works. If you could send me the changes you made,
I'll update BlogIt.
~ ~ David
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt questions
On 6/24/2014 9:49 AM, michael paulukonis wrote: Is there a way to redefine the accesskey for ajax-edit? Other than modifying the core BlogIt code? I'll try take a look over the weekend. In the meantime, check the talk and issues log, as I suspect this has come up before. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Installation problem with skittish skin
On 3/22/2014 4:00 PM, Wilco Troost wrote: Dear reader, I am a newbie mediawiki user and I like the Skittlish skin very much. So I tried to install this skin on my mediawiki webserver. Are you using the right software? This version of Skittlish is designed for PmWiki not mediawiki. Could it be that the download and the instruction • Add the following to your local configuration file: $Skin = 'skittlish'; is not fitting to the newer versions of the mediawiki software? Again, PmWiki requires a change to config.php -- if you're using MediaWiki you need to find a MediaWiki version of the Skittlish skin. If I examin my skins folder I find different folders holding different skin files (like the one I succesfully installed). For every skin there is a skin.php file in the skins folder. I couldn't find a skittlish.php file in the download. This skin uses skin.php, not skittlish.php ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New Cookbook category for recipes that don't require server access
On 2/15/2014 12:54 PM, StefCT wrote: On 02/15/2014 03:24 PM, li...@basel-inside.ch wrote: It's not a bad idee to mark reciepes which don't need any server sided installation. I like MarkupOnly, PmwikiUsage, CoreFeatures How about some sort or ranking for the cookbooks relating to the amount of admin effort required. simple - no admin effort medium - upload scripts, basic config.php changes complex - upload scripts, complex config.php changes where positioning the change is key, and possible conditional or coded configs required. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] ads in PMWiki
On 8/23/2013 9:30 PM, Timothy Yoo wrote: I'm using the CleanSimple skin for PMWiki. Do you guys know how I can integrate ads with that? I'm using Bidvertizer, and I have this block of code to integrate: Check out $HTMLHeaderFmt, http://www.pmwiki.org/wiki/PmWiki/LayoutVariables#HTMLHeaderFmt. So: $HTMLHeaderFmt['bidvertiser'] = '!-- Begin BidVertiser code -- SCRIPT LANGUAGE=JavaScript1.1 SRC=http://bdv.bidvertiser.com/BidVertiser.dbm?pid=XXXbid=XX; type=text/javascript/SCRIPT noscripta href=http://www.bidvertiser.com/bdv/BidVertiser/bdv_xml_feed.dbm;xml feed/a/noscript !-- End BidVertiser code -- '; ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] CleanSimple Skin VERY slow
On 6/15/2013 11:32 AM, w_user wrote:
when switching to the 'CleanSimple' skin, the whole pmwiki installation
gets remarkably slow! Can I improve that?
Interesting. That skin appears to be a copy of my Choice skin, with the
addition of some custom fonts. From a very quick look, it seems likely
that the custom fonts are what is slowing things down. You could try
removing these lines from style.css.
@import url('fonts/Nobile-fontfacekit/stylesheet.css');
@import url('fonts/dreamorphanage_regular_macroman/stylesheet.css');
I haven't tried it, but start there. You might also try just loading the
Choice skin, and see what happens. That would tell us if it's changes to
the CleanSimple skin which might be causing the problem.
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] noleft query in skin.php for CSS change
On 11/13/2012 3:14 AM, Simon wrote: Thanks to Petko and PM for some feedback here http://www.pmwiki.org/wiki/PITS/01298 I'm trying to develop a wiki skin[1 http://ttc.org.nz/pmwiki/pmwiki.php/TTC/HomePage] where the header and footer (wikifooter http://www.pmwiki.org/wiki/Cookbook/WikiFooterrecipe) are wiki pages like the SideBar, and yet trying to maintain and support the directives I refer to below. Check out skins like Marine, Blix, Choice, etc. They all do exactly what you describe. You might be able to use them as a guide. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Invalid Page name when editing Site.SideBar
On 10/29/2012 12:25 PM, Sandy wrote: I was afraid of that. I'm writing a draft for the host support ticket now, complete with temp accounts on the site. Don't know if it will help them or not. I'll also take them off the PmWiki friendly host page on pmwiki.org, or at least mention the problem. Would Clean URLs make a difference? I don't remember which method I used for them. I have another account with the same host that's still fine, but doesn't use Clean URLs or farms or subdomains. At this point you might want to just do a quick clean install in a new directory, and see what happens. That will at least tell you if it's PmWiki or some cookbooks, etc. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New WikiGroups on pmwiki.org [Was: Volunteering for a PITS issue]
On 10/6/2012 4:20 PM, Petko Yotov wrote: I'd like to have some arguments from the community why we should or shouldn't have a dedicated Skins/ group. In favor of a separate Skins group. Possibly either Skins, or maybe PmSkins. In general Skins are different to Cookbooks. Skins affect UI, cookbooks provide functionality. I can see some lengthy arguments that skins also provide functionality, but across the web, we've settled on separate skins and some sort of cookbook/module terminology. Thinking more globally, should we do something for the other languages, especially, should we have a SkinsFr/ and a CookbookFr/ WikiGroups for the French language pages (among 20 languages)? Not in favor of this. Why not handle languages with categories? If so, should we have separate *-Talk and *-Users pages for the other language versions? Or we could have a global Talk/ and Users/ wikigroups automatically related to all CookbookBg/ and CookbookDe/ pages which are just versions of the Cookbook/ page in English. (Moving existing *-Users pages to a different group will be done automatically, not manually.) Also not in favor. Number of groups is just going to get exponentially large, and likely psychologically confusing to users... to what benefit, over categories? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Solved: How do you creating one, wiki-wide, Upload Directory on Local Site, not remote site?
On 5/18/2012 4:46 PM, Al Louis Ripskis wrote: Many thanks to Josh, Gilles, Tamouse and JDD for helping me resolve this conundrum. Since PmWiki architecture apparently doesn't permit to automate this process, here is how I'm dealing with it: I manually (via FileZilla) transfer all the files From the PmWiki-wide uploads directory to my local C:\public_html\UnTestedUploads directory, where I can use my AVG anti-virus program to check out and delete the infected files, then process the uninfected files as necessary. It would be nice to be able to do this automatically, but c'est la vie! You could setup a batch job on your windows machine to periodically copy your remote uploads directory to your PC. Setup your virus checker to make sure it scans all new files, and auto-deletes/moves infected files. Then the job can simply copy the remaining files back over to the remote uploads directory, removing the existing files. You could probably automate all this with a backup tool. I'm familiar with SyncBack, and it seems to me that could be setup to perform the copy/sync process, and the virus scanner will process all new files for you. There are no doubt other ways of doing this. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Tracking number of page views statistics
On 3/26/2012 7:37 PM, wri...@creativevirtuosity.com wrote: I would like to track the number of times some of the pages in my Wiki are viewed. Is there a recipe that will allow me to do this? I can't find any specifically targeted to display reader stats in the cookbook. I use Cookbook/TotalCounter, and have been for a few years. Others have had some issues with it, documented on the cookbook page, so be aware of that if you choose to use it. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] $Group, $Name in Markup definition
On 2/13/2012 4:05 AM, Anton Shevtsov wrote:
Hi
How i can access to $Group, $Name variable from custom Markup?
example:
Markup(get_content, directives,
'/\(:get_content\s+\((.+?)\):\)/e',_get_content($1));
.
.
function _get_content($filename)
{
$foo=file_get_contents($mypath.$Group.'/'.$Name.'/'.$filename);
return $foo;
}
Using global:
function _get_content($filename)
{
global $Name;
$foo=file_get_contents($mypath.$Group.'/'.$Name.'/'.$filename);
return $foo;
}
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] adjusting the sublist indentation
On 2/12/2012 9:32 PM, Michael Benjamin wrote:
Hi -
I have two questions:
(1) Does anyone know how to ajust the distance indented in a sublist,
Controlled by ul ul:
ul ul {margin-left:30px;}
and the padding between the bullets and the text in a sublist?
li {padding-left: 30px;}
(2) Does anyone know how to adjust the left/right padding in the sidebar?
This may be particular to the skin I'm using (notsosimple). I seem to
have a lot of padding to the right in the sidebar.
In pmwiki/pub/skins/notsosimple/notsosimple.css, I already changed the
padding-right from 10px to 0pix (which helped a bit) as below, but there
is still a alot of padding. What else is affecting this?
#sidebar {
float: left;
width: 195px;
margin: 0px;
/* padding-right: 10px; */
padding-right: 0px;
border-right: 1px solid #ccc;
}
Is it really padding, or is the width just too large?
As a tip you might want to download firefox, and firebug extension. That
will let you change css properties visually on the fly. It'll also show
you the padding/margins so you can see which is causing the effects you
actually see on the page.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PMform
On 1/23/2012 5:09 PM, Jeroen de Vries wrote: Hello, I have difficulty installing the PMform on my website. I just was wandering is this line like seen on the installation manual not missing something? $PmForm['reference'] = 'subject=Email from '.$WikiTitle.' mailto=yourn...@example.com form=#yourform fmt=#yourformpost from=myn...@myexample.com; Is there a ' missing? When I'll add this line of code in config.php the website doesn`t run anymore. I can't comment on whether the line is correct, but you do need a single quote at the end, before the semi-colon: $PmForm['reference'] = 'subject=Email from '.$WikiTitle.' mailto=yourn...@example.com form=#yourform fmt=#yourformpost from=myn...@myexample.com'; ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Some of the links to articles do not appear on the Mainpage
On 1/3/2012 8:47 PM, Simon wrote: Surely that should be a link to http://www.pmwiki.org/wiki/PmWiki/PageLists we should be keeping our documentation up to date, and using it, and referring people to it, and in any case the page is just a copy. (nice though it is that that website uses PmWiki). Each installation of pmwiki comes with a full set of documentation. So I think the point here was to refer the original poster to the copy of the documentation on the OPs server http://eli5pedia.com/, which is a copy of the documentation available on pmwiki. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt
On 1/2/2012 9:26 PM, Wade Lee Hudson wrote: I'm setting up a new site with pmwiki and the Blix skin and am interested in adding BlogIt. But I can't find the new entry link on the demo at http://wiki.solidgone.org/BlogIt/Main, which I'd like to do. Any thoughts? Security permissions are now fixed on the demo site. Login as blogadmin or blogedit (has comment approval permissions). ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Problem with trashing deleted files from a folder
On 10/20/2011 9:08 AM, ki...@kirpi.it wrote: Thus... I'll probably kill Blog-It out of my system, trash all folders, and just place a link at the bottom of pages, the traditional way: if you have something to say, please send me an email :-) Interesting that you ended up with so much spam. Did you implement the captcha system, and set comments to require approval? I've done this on blogs, and had very little spam. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] It's time to change pmwiki default skin!
On 9/21/2011 5:08 PM, Forgeot Eric wrote: http://paulgiacherio.kodingen.com/pmwiki/pmwiki-2.2.30/pmwiki.php?n=PmWiki.DocumentationIndex it just looks simple and gorgeous at the same time. I think something like that (or even this one) could be a good candidate for the default skin on pmwiki.org Agreed -- also like this one. Would be easy to add a splash of color, without upsetting the simplicity. What I like on this one: - the content is written with darker letters than the menu so when we see the page, we don't feel overwhelmed by the secondary informations. It's **very** important in my opinion, because as explained before, the pmwiki menu is quite huge - the content font is easily readable and nice for the eyes - the links color is still blue (but nicer than color:blue) so Jakob Nielsen won't feel too shocked. The visited and hover links are not in a different tone, but this could be easily improved/activated. I also like the modernish Edit/History buttons. Very much in the feel of http://github.com/ ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] It's time to change pmwiki default skin!
On 9/18/2011 7:17 PM, Rogutės Sparnuotos wrote: Though I think that using the same skin for the home page and installations is a good thing: less to maintain; stays familiar to newcomers after installation. If pmwiki.org adopts a skin too complex for distribution, I think that the two skins should at least share layout and colors. It's important to have a simple(ish) skin for newcomers to use in the distribution. I don't think it needs to be the same as the one used on pmwiki.org. What we could do is include two skins with the distribution. One is the simple version which is active by default from the standard config.php. The other we include could be a *slightly* more sophisticated skin which would be used on pmwiki.org. This provides a way to improve the pmwiki.org look and show some pmwiki capabilities, as well as providing a simple launch point from a first install. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] It's time to change pmwiki default skin!
On 9/18/2011 7:57 PM, Rogutės Sparnuotos wrote: ki...@kirpi.it (2011-09-13 00:48): I'm not sure Pmwiki would/should/could enter the race with things like Wordpress (I like Textpattern a lot more) or any other CMS up to TYPO3. .. Do others really like the presentation trend of textpattern.com, wordpress.org, contao.org? This trend: 1. Homepage for Symfony 1: http://www.symfony-project.org/ (a bit like PmWiki?). Way too busy in terms of sections on the screen. Also too many and non-complimentary colors. 2. Homepage for symfony 2: http://symfony.com/ (did I just visit wordpress.org?). Much nicer, and good use of whitespace. Although I dislike the black bar on the top. The other thing I like about this homepage is the WHY WOULD YOU WANT TO CHOOSE SYMFONY? -- exactly the information a first-time visitor is likely to want to see. 1. is not perfect, but 2. is everywhere nowadays... With regards to [2] I don't view high usage as a negative. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] it's time to change pmwiki default skin!
On 9/12/2011 7:21 AM, Laatz, Erek wrote: As PM wrote, the actual default skin is a good starting point for personal customizations. But what about an image gallery with some screenshots of the several skins offered in the skin section of the pmwiki-site. The images could be linked to the skin section, where all relevant informations are documentated. Skins gallery: http://www.pmwiki.org/wiki/Cookbook/SkinsGallery ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Sending emails when a calendar is updated
On 9/9/2011 5:14 PM, John Bowling wrote: What is sends is a link to the list of changes on the site. That link is the full link to the hosting's primary domain, which is masked when browsing to the site. That would be fine if I were the only person to get emails, but not to the site visitors. That's why it is masked. The email text can be changed. Refer to http://www.pmwiki.org/wiki/PmWiki/Notify#NotifyBodyFmt This will require that I get the email, massage it to eliminate that link, for the potential dozens per day, and then forward the results to the appropriate people, expected somewhere between 40 and 75. It also sends the message as: * Calendar.20110910 . . . September 09, 2011, at 11:53 AM MST by Again, refer to http://www.pmwiki.org/wiki/PmWiki/Notify#NotifyItemFmt ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Need help against Wiki Spam
You could also try Captcha. Until recently that stopped 100% of spam. In the last few days I've started get one or two through the captcha though. ~ ~ Dave On 7/15/2011 12:05 PM, ABClf wrote: I would try http://www.pmwiki.org/wiki/Cookbook/OpenPass if you can ask your users one more (easy) step. No spam for me and nothing to param. Functional and easy to set up. Gilles. 2011/7/15 Laurent Meister meis...@apfelwiki.de mailto:meis...@apfelwiki.de Hi, Unfortunately my last question here regarding the non functional blocklist remained unanswered. Our wiki apfelwiki.de http://apfelwiki.de is the target of massive wikispam. What is the best way to prevent it? Thx for helping Laurent (kt007) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com mailto:pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users -- --- | A | de la langue française | B | http://www.languefrancaise.net/ | C | languefranca...@gmail.com mailto:languefranca...@gmail.com --- ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] [pmwiki-devel] BlogIt Vulnerability
Working with Petko, BlogIt version 1.7.0 has been released. Please upgrade immediately. This is a critical bug fix, correcting the vulnerability identified. ~ ~ DaveG On 7/3/2011 5:16 PM, DaveG wrote: A vulnerability in BlogIt (http://www.pmwiki.org/wiki/PITS/01258) was identified which could allow a an attacker access to the account hosting PmWiki. A fix will be posted as soon as possible. In the meantime please '''disable''' BlogIt entirely by commenting out the BlogIt include statement. Apologies for the inconvenience this will cause. ~ ~ DaveG ___ pmwiki-devel mailing list pmwiki-de...@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] BlogIt Vulnerability
A vulnerability in BlogIt (http://www.pmwiki.org/wiki/PITS/01258) was identified which could allow a an attacker access to the account hosting PmWiki. A fix will be posted as soon as possible. In the meantime please '''disable''' BlogIt entirely by commenting out the BlogIt include statement. Apologies for the inconvenience this will cause. ~ ~ DaveG ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/14/2011 12:58 PM, DaveG wrote: But now it is the same for allGalleria Correct. That is because getDataConfig not only sets preferences, but also actually creates the gallery. This basically means you need to either use markup, OR use the getDataConfig method for a given gallery(ies) -- you can't do both. Okay, what I wrote is incorrect -- I didn't mean getDataConfig, I meant dataConfig. The point I was trying to make is that setting description and title parameters will also cause the creation of the gallery. From a quick look at the docs, you can't set global options to apply to all galleries outside of the creation of a gallery. That means you either use the pmwiki markup, or use a method like Petko described in javascript. The galleria markup does allow you to pass in the same parameters as getDataConfig though, so this shouldn't be a show-stopper. It would be nice to be able to set some global parameters though, like the description/tag preference for example. I'll try to take a look at that over the weekend. This still holds true ;) ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/11/2011 3:04 AM, Petko Yotov wrote: 3] Allow for some form of styling to be put around image and table captions. The | Caption part after an image can already be styled: Attach:im.jpg | ''Some %green%styled%% caption.'' Very good point, and makes the selector much easier and more reliable, thanks. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/10/2011 5:48 AM, Peter Gragert wrote: Hallo, Galleria is indeed nicely adjusted. Two remarks : 1.Images with Captions does not show the captions? Check that be CSS coloring style on text/links is not the same color as the background and thus hiding the text. Also make sure you set the config appropriately: http://galleria.aino.se/docs/1.2/options/dataConfig/ 2.How to start autoplay again, after a click on a thumbnail? (I mean not ‘reload’, which starts again but at image 1) I may be wrong, but I'm not sure this capability exists yet. I see pauseOnInteraction defaults to true, but don't see an oppoosite action. You'd probably have to add a custom control to resume play. I'll look at it over the weekend, to make sure I'm not missing anything. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/10/2011 11:34 AM, Peter Gragert wrote: Thanks Dave, Discovered the small (white) I (letter i) at the left top of an image ... THAT has to be activated! But the text occurs twice, fat white, and grey italic ??? A little bit of work? That's actually correct behavior for the way Galleria works, and is because the markup: * Attach:P5123230.jpgThis is image 1 -- very nice Adds the text to both the alt and title tags, which galleria uses for different purposes. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
http://www.pmwiki.org/wiki/PmWiki/Images On 6/10/2011 11:41 AM, Peter Gragert wrote: Oh, the dubbel text is a behavior missing 'alt=the italic line' That means, how doe I add a HTML alt to an Attach:pic.jptTitle alt = According to http://www.pmwiki.org/wiki/PmWiki/Images, alt text is identified by double quotes immediately following the image url; a caption can follow separated by a vertical bar (|). However, in a quick test (ref Test/Images-Draft), I think the docs are a little misleading, as further down it's noted that the pipe is to identify a Caption more than affecting the TITLE attribute. So, end result is I'm not sure how to identify a TITLE attribute for an image tag. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/10/2011 4:18 PM, Petko Yotov wrote: PmWiki adds the string in quotes in both alt= and title= attributes of the image tag. You can see the HTML source code of the page. Agreed, as I also noted. Browsers should display the alt text when the image cannot be displayed, and the title text in a tooltip box/bubble when the mouse cursor is positioned over the image. (In the past, Internet Explorer used the alt text for both, but this behavior is not standard.) Agreed, but is there no reason why the two *have* to be the same. Is there a way to provide different text for the ALT and TITLE? ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/10/2011 8:52 PM, Petko Yotov wrote: Agreed, but is there no reason why the two *have* to be the same. They don't have to, but when we convert from simplified wiki-markup to HTML, what PmWiki does is simple, quick and probably most convenient for most people in most cases. Is there a way to provide different text for the ALT and TITLE? Not with the default PmWiki installation. Looking at your demo page, the easiest fix for the double caption may be to just disable one of the attributes, by adding such a line to config.php: $ImgTagFmt = img src='\$LinkUrl' title='\$LinkAlt' /; # no alt Another approach based on that idea might be something like: $ImgTagFmt=img src='\$LinkUrl' alt='\$LinkAlt' title='\$LinkText' /; However, the caption isn't passed into the image handler function. Which is reasonable given it's not part of the image tag. Looking at the Galleria documentation, I see that it is possible to get the description from a text element after the image, eg. from the | caption part generated by PmWiki. The method is shown here: http://galleria.aino.se/docs/1.2/references/data/#using-html-with-dataconfig The example will not work in PmWiki without some tweaking, but it shouldn't be hard. Thanks, that seems like a workable solution, although I've not yet been able to find a selector that can get text after the BR. Options for a more rigorous solution might be: 1] Since the caption is not currently part of the image it makes sense the caption is not passed as a parameter into the image parsing function. Is there a possibility to change this? 2] Or, allow for a separate definition of ALT and TITLE within markup. Possibly separate the title from alt with another pipe delimiter. 3] Allow for some form of styling to be put around image and table captions. Option [3] is probably the more generally usable, with the creation of some form of $CationFmt variable. If this seems a reasonable approach, I'll add a PITS entry. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria
On 6/10/2011 11:18 PM, DaveG wrote:
The example will not work in PmWiki without some tweaking, but it
shouldn't be
hard.
Thanks, that seems like a workable solution, although I've not yet been
able to find a selector that can get text after the BR.
I have the selector:
$(img).parent('div').contents().filter(function(){ return this.nodeType
== 3 }).text()
Unfortunately I can't yet get it to work in the context:
$('#demo').galleria({
dataConfig: function(img) {
return {
description:
$(img).parent('div').contents().filter(function(){ return this.nodeType
== 3 }).text()
}
}
});
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] New recipe: LocalTimes
On 6/6/2011 1:17 PM, ABClf wrote: works with IE 8 *but* the tooltip doesn't show the original date : just show the word « undefined » Same behavior in IE9. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Group name based $XLLangs (multilanguage Wiki)?
On 5/22/2011 3:07 PM, Peter Bowers wrote: ResolvePageName calls MakePageName which calls FmtPagename which calls PageVar which (a) calls PCache() (first problem) and (b) also calls PageTextVar which calls RetrieveAuthPage which normally calls PmWikiAuth (second problem). My recollection (I can search thru archives to confirm -- I may be remembering it wrong) is that the static $acache in PmWikiAuth as well as the general $PCache can both cause problems if they are called/cached early in config.php... You are correct. Any calls to PageVar or PageTextVar cause issues with caching. This in turn can cause issues with cookbook include sequencing when they both need access to page and group names. Thus if I need $group or $name early on in my config.php I can either take a chance with $pagename without calling ResolvePageName or else take a chance that I will open the door to later difficulties with cached values (which are notoriously difficult to debug)... Agreed. Had a lot of issues with this when creating blogit. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Petko's E2100/US$2, 963 bid for WYSIWYG capability
On 5/18/2011 8:38 AM, Al Louis Ripskis wrote: Sent: May 17, 2011 9:57 PM; DaveG wrote: I added a page Cookbook/WYSIWYG-donations, and included the pledges made in this thread. For those who pledged, please check I have your information correct. Hey, Dave, I'm real glad to see that you set up our Score Card, even reflecting the changes in the euro/USD exchange rates. Are you going to be updating it regularly? The page is there. Contributors can either edit the page direct, or as I see pledges via the list, I'll add them to the page. If you mean will I be updating the USD/EU exchange rate -- probably not. Unless there is a real tectonic shift in rates the variation is too small to be concerned with. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Petko's E2100/US$2, 963 bid for WYSIWYG capability
Perhaps something like pledgie http://pledgie.com/site/faq (used within Github for project support) would be useful to track commitments to the goal. I'd set it up, but the recipient needs to enter a Paypal address to facilitate funds transfer. ~ ~ Dave On 5/14/2011 5:25 PM, Al Louis Ripskis wrote: Petko Yotov5...@5ko.frSent: May 14, 2011 3:36 PM The cost of this work is estimated to be 2100 euros. My company doesn't collect VAT. A receipt or a number of receipts will be available. Guys, I'm relatively new to this list, so I have no idea how this type of contract has been handled in the past. My first instinct would be to consult Pm on this. Also how would the collection be handled? As to the cost, it of course would depend on how many of would contribute. Today the euro to $US dollar rate is 1 to 1.411. So 2100 euros translate to $US2,963.10. So if a 100 of us contributed, it would be $29.63 each. If 50 then it would be $59.26. If thirty, then it would be $98.77, or round off to $100. Now could we have a show of hands--or in this case e-mails--as to how many of you and how much you would be willing to contribute. I'll start of with $100, if necessary. Cheers, Al To: Al Louis Ripskisrips...@sprynet.com Cc: pmwiki-userspmwiki-users@pmichaud.com Subject: Re: Fw: Re: [pmwiki-users] Follow-Up:Whither WYSIWYG? Contract/Contribution On Saturday 14 May 2011 14:30:30 Al Louis Ripskis wrote: Did my email slip through the cracks? Or is there some other reason why you haven't responded? It is not easy to estimate this kind of work. Such a module can be done fairly quickly (2-3 days) but without a good integration with PmWiki and with potential security holes, as a couple of users expressed their concerns. PmWiki has lots of features and different configurations. Such a module has to work in many different environments, like different settings for passwords, diffrent uploads directories, different servers, and different browsers. Additional modules need to be written - file picker (with thumbnails?), asynchronous uploader (upload a file while you edit a page), internal link picker (autocomplete?). The most difficult decision is how to store and differenciate the feature-limited RichText input from wiki-code which can have unlimited features and local customizations. Last but not least, it is not possible to write such a complex program at once - there will certainly be bugs to be fixed as they are uncovered, features added or changed, and the module has to be supported in the future. What do you estimate it would take to do it, and how long would it take? What cost? Here is a Quote: 2 weeks of work for a working beta prototype, including: * integration with PmWiki pages, passwords and upload directories * modules file picker/uploader, link picker * full documentation * 1 year bugfixing/support on the Cookbook Talk page or in the PITS * free software under the GNU GPL, MIT-style license or WTFPL/PD (the best things in life are free) The cost of this work is estimated to be 2100 euros. My company doesn't collect VAT. A receipt or a number of receipts will be available. Note that the features of the rich-text editor will be limited - not all existing HTML tags or attributes can be available, and not all PmWiki markups can have a rich-text button. The rich-text editor will be in addition to the normal wiki-text editor. Thanks, Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Petko's E2100/US$2, 963 bid for WYSIWYG capability
I added a page Cookbook/WYSIWYG-donations, and included the pledges made in this thread. For those who pledged, please check I have your information correct. ~ ~ Dave On 5/17/2011 9:10 PM, Patrick R. Michaud wrote: I'm willing to set up whatever accounts etc. are needed to sure the funds all make it to the right places, whether that's through pledgie, kickstarter, etc. (I have plenty of paypal, amazon associate, etc. accounts that I can use for this.) But I don't want to start setting things up until we have at least 60% of the pledges needed to reach the goal. So, until then it might be worthwhile to just create a page on PmWiki.org describing the campaign, the target, what will be delivered, and how close we are to the final goal. When the number reaches around 60% of the total, I'll start making the official transfer channels open. Pm On Tue, May 17, 2011 at 05:56:31PM -0400, DaveG wrote: Perhaps something like pledgie http://pledgie.com/site/faq (used within Github for project support) would be useful to track commitments to the goal. I'd set it up, but the recipient needs to enter a Paypal address to facilitate funds transfer. ~ ~ Dave On 5/14/2011 5:25 PM, Al Louis Ripskis wrote: Petko Yotov5...@5ko.frSent: May 14, 2011 3:36 PM The cost of this work is estimated to be 2100 euros. My company doesn't collect VAT. A receipt or a number of receipts will be available. Guys, I'm relatively new to this list, so I have no idea how this type of contract has been handled in the past. My first instinct would be to consult Pm on this. Also how would the collection be handled? As to the cost, it of course would depend on how many of would contribute. Today the euro to $US dollar rate is 1 to 1.411. So 2100 euros translate to $US2,963.10. So if a 100 of us contributed, it would be $29.63 each. If 50 then it would be $59.26. If thirty, then it would be $98.77, or round off to $100. Now could we have a show of hands--or in this case e-mails--as to how many of you and how much you would be willing to contribute. I'll start of with $100, if necessary. Cheers, Al To: Al Louis Ripskisrips...@sprynet.com Cc: pmwiki-userspmwiki-users@pmichaud.com Subject: Re: Fw: Re: [pmwiki-users] Follow-Up:Whither WYSIWYG? Contract/Contribution On Saturday 14 May 2011 14:30:30 Al Louis Ripskis wrote: Did my email slip through the cracks? Or is there some other reason why you haven't responded? It is not easy to estimate this kind of work. Such a module can be done fairly quickly (2-3 days) but without a good integration with PmWiki and with potential security holes, as a couple of users expressed their concerns. PmWiki has lots of features and different configurations. Such a module has to work in many different environments, like different settings for passwords, diffrent uploads directories, different servers, and different browsers. Additional modules need to be written - file picker (with thumbnails?), asynchronous uploader (upload a file while you edit a page), internal link picker (autocomplete?). The most difficult decision is how to store and differenciate the feature-limited RichText input from wiki-code which can have unlimited features and local customizations. Last but not least, it is not possible to write such a complex program at once - there will certainly be bugs to be fixed as they are uncovered, features added or changed, and the module has to be supported in the future. What do you estimate it would take to do it, and how long would it take? What cost? Here is a Quote: 2 weeks of work for a working beta prototype, including: * integration with PmWiki pages, passwords and upload directories * modules file picker/uploader, link picker * full documentation * 1 year bugfixing/support on the Cookbook Talk page or in the PITS * free software under the GNU GPL, MIT-style license or WTFPL/PD (the best things in life are free) The cost of this work is estimated to be 2100 euros. My company doesn't collect VAT. A receipt or a number of receipts will be available. Note that the features of the rich-text editor will be limited - not all existing HTML tags or attributes can be available, and not all PmWiki markups can have a rich-text button. The rich-text editor will be in addition to the normal wiki-text editor. Thanks, Petko ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Can Gallery work without Internet ?
On 5/5/2011 3:55 PM, edwin marte wrote: downloaded a copy of jqery on /pub and changed the code on about line 25 of galleria.php to be /pub and not from Internet. $HTMLHeaderFmt['jquery'] = 'script src='. $PubDirUrl. '/galleria/jquery.min.js/script'; Rather than changing the galleria code, you can simply add the line to your config.php before including the galleria cookbook: ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Can Gallery work without Internet ?
Actually, it turns out that you could not override HTMLHeader from config.php. The latest version 0.4.1 now allows the override to occur. ~ ~ Dave On 5/5/2011 7:54 PM, DaveG wrote: On 5/5/2011 3:55 PM, edwin marte wrote: downloaded a copy of jqery on /pub and changed the code on about line 25 of galleria.php to be /pub and not from Internet. $HTMLHeaderFmt['jquery'] = 'script src='. $PubDirUrl. '/galleria/jquery.min.js/script'; Rather than changing the galleria code, you can simply add the line to your config.php before including the galleria cookbook: ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmForm - change summary and cancel button
Check out BlogIt, which uses PmForms, that might help (or might be too
complex to easily grab info quickly).
On 3/1/2011 4:54 PM, Randy Brown wrote:
I am successfully using a PmForm to change page text variables, but I have two
problems that I've been unable to solve:
1) Upon save, I want the page's change summary updated too (either
automatically, or with user-entered information from the form).
Setup some form of event handler. From BlogIt:
SDV($HandleActions['bi_be'], 'bi_HandleEdit'); SDV($HandleAuth['bi_be'],
'admin');
In your case that might be:
SDV($HandleActions['my_edit'], 'my_HandleEdit');
SDV($HandleAuth['my_edit'], 'edit');
in my_HandleEdit() something like (make sure you declare $ChangeSummary,
$_POST, etc, as global in your function):
if ($_POST['target']=='savedata' @$_POST['save']{
$ChangeSummary = $_POST['ptv_MyPTV'];
}
2) I would also like a cancel button. (It seems whatever I do, my buttons save
the data, regardless of their name or value.)
Search for 'cancel' in BlogIt for actual use. Basically:
if ($_POST['cancel'] in_array($_REQUEST['target'],$bi_Forms))
This is checking for the Cancel button being clicked, and then checking
that the form being submitted is one being managed by PmForms.
Simplified for your case that might be:
if ($_POST['cancel'] $_REQUEST['target']=='savedata')
Hope that gets you in a direction to move forward a step.
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PmWiki on Window XP Home?
On 3/1/2011 8:42 AM, Al Louis Ripskis wrote: Guys, Has anyone actually installed PmWiki on Windows XP Home? The trick seems to be installing the IIS first. I ran across a description of a torturous process at http://www.xfutureblog.com/2006/07/30/install-iis-for-windows-xp-home-edition/ But apparently it is questionable that it really works, judging from the responses of some who tried. Would you know a way around this conundrum? I run PmWiki on XP, with no issues, but not under IIS. For light install I use Abyss web server http://www.pmwiki.org/wiki/Cookbook/WikiOnAStick#abyss For a more comprehensive install I run Apache, and a PHP install. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] href=a group's last edited page, or pagelist results in template files
On 1/16/2011 7:57 AM, viki.ve...@gmail.com wrote:
I hope this makes clearer what I mean with: ``in a template, is it
possible to retrieve the address of a group's last edited page?''
Yes. You include a PmWiki page, which contains a pagelist as Kathyrn
described. For an example, specifically of finding the last edited page
in a group, take a look at the Skidoo skin, which displays this type of
information in tabs on the skin.
The Site.Skidoo-Tabs, which has a section which contains:
(:pagelist group=-{$SiteGroup},-PmWiki
trail={$SiteGroup}.AllRecentChanges count=40 list=normal
fmt=#Skidoo_MRU_Group_List group={$Group}:)
Which you could adapt, something like this in a file Site.LatestEditedPage:
(:pagelist group=-{$SiteGroup},-PmWiki
trail={$SiteGroup}.AllRecentChanges count=1 list=normal group={$Group}:)
You can then include from the.tmpl file:
!--wiki:{$SiteGroup}.LatestEditedPage--
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Static 'site maps'?
I use sitemap.php by http://www.brambring.nl to generate Google sitemaps. Works great. Unfortunately I can't find which cookbook page this cookbook is on. Let me know if you'd like the cookbook and I'll send it. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt Installation Problems
On 12/8/2010 4:10 PM, Olga Lositsky wrote: Dear PmWiki Users, I'm having a problem installing BlogIt on my Wiki, and I think I must have missed some step of the installation, but can't quite figure out what it is. When I followed the steps in the recipe (unzipped the cookbook and pub files, added the necessary code to my local/config.php file, created Main.Blog and added the Blog code to my SideBar), three headers appeared in my Sidebar : Recently Written, Recent Comments and Categories (with a login underneath). This is my current test Wiki: http://compmem.princeton.edu/tests/test1/ Unfortunately, there is no New Entry link in the SideBar Ensure you have setup the authorizations for read and edit. Then login, and you should see the New Entry link. Specifically make sure you're declaring the security elements before including BlogIt. and the Site.BlogIt-NewEntry page does not exist. Correct, templates for new blog entries are in Site.BlogIt-CoreTemplate. The only problem I can think of is that I may have installed PmForm incorrectly. I read on the BlogIt page that PmForm is a prerequisite, so I downloaded it into the cookbook and wikilib.d directories, included the code in config.php and created the Site.LocalTemplates (though I didn't modify it.) Downloading PmForm separately is not necessary. Use the version included in the BlogIt zip/tar. Simply put pmform.php into the \cookbook directory. Can anyone think of a step in the installation I may have missed? If you still have problems feel free to send me the blogit related items from your config. ~ ~ David ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PageLogoURL as Link
On 12/4/2010 4:12 PM, George Laverick wrote:
The image defined by $PageLogoURL is also a link. By default, it
points to the home page of the wiki. I would like it to point to a
URL that is outside of the wiki, but I have been unable to find
where that is defined.
I found the Site.Pageheader page and it contained a string that looked
like this:
[[{$ScriptUrl}|{$PageLogoUrl}]]
I went into config.php and defined a variable $MotherUrl (also tried
defining it in pmwiki.php) and changing the above string to:
[[{$MotherUrl}|{$PageLogoUrl}]]
In order to make a variable available to a PmWiki page you need to use
$FmtPV (ref http://www.pmwiki.org/wiki/PmWiki/PageVariables#custompv).
Notice the variable needs to be a PHP expression, and so in this case is
a quoted string inside a double quoted string:
$FmtPV['$MotherUrl'] = 'MY_URL';
Also, always add your own settings to config.php, don't change pmwiki.php.
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] something wrong with pmwiki.org?
On 12/1/2010 2:42 PM, Vince Administration wrote: It is not just you. On Dec 1, 2010, at 8:37 AM, Peter Bowers wrote: Is it just my connection or is something wrong with pmwiki.org? I can't connect to it at all... I was unable to access it most of today -- it now seems to be up and running. ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] GroupFooter question
On 11/30/2010 11:31 AM, Stéphane wrote:
I don't know how to put both twitter and I like buttons on the same
line in a GroupFooter :
ie
http://stephaneheckel.com/NoteIt/2010-07-11-ListeningtoYourCustomers
This is what I have in the GroupFooter :
(:html:)a href=http://twitter.com/share; class=twitter-share-button
data-count=none data-via=ACMETweet/ascript
type=text/javascript
src=http://platform.twitter.com/widgets.js;/script(:htmlend:)
(:html:)iframe
src=http://www.facebook.com/plugins/like.php?href=http%3A%2F%2FACME.com%2Famp;layout=standardamp;show_faces=trueamp;width=450amp;action=likeamp;colorscheme=lightamp;height=80;
scrolling=no frameborder=0 style=border:none; overflow:hidden;
width:450px; height:80px; allowTransparency=true/iframe
(:htmlend:)
The *easiest* way is to make all iframe elements float left.
iframe {float:left}
Of course this assumes the only two iframes are those around the twitter
and facebook plugins. To target those iframes specifically add classes:
iframe class=fb_iframe
And then:
fb_iframe {float: left}
Note, you also have a BR tag between the twitter and facebook elements,
probably caused by using separate (:html:) directives for each of the
elements.
Also, not sure why I should keep iframe, ...
You should keep it. The FB url contains a complete HTML document, plus a
bunch of javascript.
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.org server migration
On 11/20/2010 7:30 AM, Dominique Faure wrote: Aren't the git people condemning Windows users? I remember MSysGitHerald9 and other opportunities. There seems to be some solutions: * http://code.google.com/p/msysgit/ * http://code.google.com/p/tortoisegit/ I've been using this mix of GIT/Tortoise on Windows for the past year, and find it to be an almost direct replacement for SVN/Tortoise. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.org server migration
On 11/19/2010 4:12 PM, Patrick R. Michaud wrote: I'm also considering migrating PmWiki's subversion repository to GitHub -- any comments? (If you don't understand what this means, it likely doesn't affect you. :-) I'd personally prefer Git, and I like GitHub, so a plus from me. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] RFC: Localization InterMap
On 9/4/2010 11:19 AM, Petko Yotov wrote: There are different propositions for a prefix - the one I currently like the most is Localization:, even if there is a risk that an existing wiki could have a legitimate use of such a prefix, much like the Cookbook: prefix, pointing to a different location. (The default intermap links are not overridden by [[Site.InterMap]] entries, it is slightly more complex to change them.) How about prefixing PmWiki groups/maps with Pm to reduce potential conflicts. So we could have PmLocal:. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How can I setup a skin for ?action=edit only?
On 8/25/2010 6:38 AM, Steve Glover wrote: I thought for a short while that this would solve a problem I'm currently looking at: I have an instance of PmWiki on one machine that will be mirrored on others: naturally, I want to prevent editing on the mirrors, but I still need to let people log in to access particular content areas. I think you're over complicating this. Why not simply set the edit password on the mirrored sites through the mirrored site config.php? You can then prevent the edit links from displaying by altering PageActions as described here: PmWiki/SitePageActions ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How can I setup a skin for ?action=edit only?
On 8/23/2010 11:09 PM, redisthe...@lavabit.com wrote: I'm impressed by how customizable this wiki software is. I would like to make a separate skin for when editing wikipages on my site, ye know, without any distracting elements such as sidebars, banners, headlines etc. Is it possible to configure it so that it will only be displayed when ?action=edit (including when previewing editions)? An abbreviated, high level description of making a skinny skin: * Copy the pub/pmwiki/ directory to pub/myskin/ * Remove all the parts you don't want from pmwiki.tmpl * Add this to config: if ($action == 'edit') $Skin = 'myskin'; ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Authentication timeout
On 8/22/2010 11:07 PM, David Kramer wrote: I've been using PMWiki for a few years, though I'm far from an expert in it. I use it for coordinating some user groups and non-profit orgs. I just upgraded my server from Ubuntu 9.10 to 10.04LTS. Everything seems to be pretty much working, but I'm finding for pages with passwords in PMWiki, I have to enter the password each time. The authentication doesn't last even for seconds. I have tried multiple browsers and multiple client OSes and machines to ensure this is not a client-side issue. I've scanned the list and here's the relevant settings that might be affecting it in /etc/php5/apache2/php.ini: session.cache_expire = 180 session.gc_divisor = 1000 session.gc_maxlifetime = 1440 Obviously a lot changed when I upgraded, so I'm not positive whether the problem is with PHP, PMWiki, or Apache. I can say that HTTP auth works as usual for other things I have on the same server. What can I look at next? Possibly this: Ubuntu 10.04 comes with PHP 5.3. For this version of PHP you should use PmWiki 2.2.8 or later (if you are running a much older PmWiki version, look at the release notes [1] before upgrading). [1] http://pmwiki.org/wiki/PmWiki/ReleaseNotes; ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] PTV including directive : (:text: this is my long text, with pictures. (:thumlist:):)
On 8/13/2010 6:42 PM, ABClf wrote:
In some PTV, (:text: this is my long [[link|text]]:) I see I got trouble
when I want to include a directive as (:thumblist:) - because of the :)
Real example here :
http://www.languefrancaise.net/Info/2008-10-27-Simonin-dans-les-collections-de-la-BNF
:
part of the text is duplicated ; cause in (:text: my long text:) I
insert a {$:images} where images:(:thumblist:)
Is there any trick to solve this (nested ptv?) ?
I guess I could put the (:thumblist:) directive elsewhere in my
template, out of the long text PTV, so it isn't very crucial in this
case, but if there were any easy solution, I would like using it.
If I understand correctly, you could create an additional markup to
define PTVs. Sample from blogit:
$PageTextVarPatterns['[[#anchor]]'] = '/(\[\[#blogit_(\w[_-\w]*)\]\](?:
*\n)?)(.*?)(\[\[#blogit_\2end\]\])/s'; #[1]
That way, it doesn't get mixed up with the embedded markup.
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Hide side bar in choice skin
On 8/12/2010 3:31 AM, Litows wrote:
I thought this may be interesting to a few.
Has anyone tried to hide the side bar when viewing a choice skin on an
iphone.
Nope -- unless you want to send me an iphone.
I have started looking into bits to do this.
I am thinking I could combine bits from the iPMWiki Skin with choice.
Any leads on options to hide the sidebar in choice. I have not found a
good solution so far.
Depends on what you mean by 'hide'. You can remove the sidebar text, and
the search bar:
SetTmplDisplay('PageRightFmt',0);
SetTmplDisplay('PageSearchFmt',0);
However, the action bar also lives on the sidebar area in Choice, so,
you'd need to remove/relocate that as well. Relocating depends on where
you want it to go, so that's up to you; remove it with:
SetTmplDisplay('PageActionFmt',0);
Now you're only left with the border above the sidebar area, and the
actual space taken by the sidebar area. You can hide the border:
$HTMLStylesFmt['choice'] .= '#right { display: none;} ';
And, finally you remove the space taken by the sidebar, by expanding the
content area:
$HTMLStylesFmt['choice'] .= '#content { width: 100%;} ';
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] ANN: BlogIt 1.6.0
This release adds some new features for administrators and fixes a few bugs noted by users. Thanks to SteP, OtherMichael, and Ricardo who helped test and debug. http://www.pmwiki.org/wiki/Cookbook/BlogIt * $bi_DateZone has been removed, and replaced with $bi_DateStyle. If you changed the date entry format, then make sure you also set $bi_DateStyle. * moves javascript files to the end of the page, loaded at [@!--HTMLFooter--@] rather than the [@!--HTMLHeader--@]. Make sure this markup exists in the skin .tmpl file. * $bi_Hooks allows code to run before and after BlogIt processing, allowing things like page names and titles to be formatted differently to the BlogIt default, and allowing default field values to be altered. * incorporates RSS feed config to make setup easier. * generates a new captcha code after ajax comment submit to prevent spam after first successful captcha entry. * ...and finally fixes pretty rare, but very annoying cases where dates would randomly change. Thank PHP strtotime for that. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] How to force-update the pageindex
On 8/11/2010 9:46 PM, Randy Brown wrote: I now believe I've managed to delete the old pageindex, but until it's rebuilt my pagelists are returning incorrect results. Is there any recipe that traverses all pages and updates each or otherwise rebuilds the pageindex? I was under the impression (and going back to some mail archives confirms) that simply deleting the index and then editing a page would subsequently cause it to be recreated, and that pageindex is not an authoritative source, more used for optimization. So it's possible some things you might expect to see there are not yet/ever populated. And a quote from Pm: We don't want to rebuild the entire .pageindex every time a page is edited or saved -- it takes way too long (which is why PmWiki does it incrementally over a number of searches and/or edits). ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt configuration -- entries only visible if logged in
On 8/8/2010 4:43 PM, michael paulukonis wrote:
I have replicated the behavior on a clean install @
http://www.xradiograph.com/projects/test/wiki/pmwiki.php
I attempted to set up blogit with nothing else installed.
Although AuthUser is said to be an optional component, if it is NOT
included, the wiki fails to load with at error in BlogIt @ line 581 (a
call to AuthUser)
I've logged this as a bug. AuthUser is meant to be optional.
I have set up a sample blog using the sample info @
http://www.pmwiki.org/wiki/Cookbook/BlogIt
with the daveg and step users, in the same roles
The complete text of my config.php is below
snip
Config looks fine, although I would remove the $bi_DefaultGroup line --
I suspect it's this which is causing your Recently Written list to be
empty. This line instructs BlogIt to only look in Main group for blog
entries. If you created entries in another group they will not be
listed. If you exclude the definition of $bi_DefaultGroup, all blog
entries across all groups will be listed.
If it's only you administering the blog, then you can simplify things:
# [1] Define BlogIt roles, and associated actions
# Actions: 'comment-edit', 'comment-approve', 'blog-edit',
'blog-new','sidebar', 'blogit-admin'
$bi_Auth['blogit'] = array('comment-edit', 'comment-approve',
'blog-edit', 'blog-new', 'sidebar', 'blogit-admin');
# [2] Define users passwords
$AuthUser['daveg'] = crypt('daveg'); #set daveg password
# [3] Add users to the roles
$AuthUser['@blogit'] = array('daveg');
# [4] Assign roles to security groups
$DefaultPasswords['blogit'] = array('@blogit');
# [5] Assign roles to pmwiki actions
$DefaultPasswords['edit'] = '@blogit';
# if not included, blogit fails @ line 581
include_once($FarmD/scripts/authuser.php);
$HandleAuth['source'] = 'edit'; #Prevents non authorized users from
viewing comment source email address
$HandleAuth['diff'] = 'edit'; #Prevents non authorized users from
viewing comment source email address
$MaxIncludes=500; #BlogIt makes heavy use of includes, so this needs to
be increased.
include_once($FarmD/cookbook/blogit/blogit.php);
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt configuration -- entries only visible if logged in
On 8/8/2010 12:52 PM, michael paulukonis wrote:
I'm trying to set up a BlogIt blog, and while I can get it to work for
myself as the admin, the posts are not visible to anybody else (or
myself, when logged-out).
Additionally, the RecentlyWritten section is always blank, whether
logged-in, or not
I think this is because you specified $bi_DefaultGroup, and created blog
entries in another group. (Ref response to your other email)
The BlogIt admin-panel for published entries allows me to see my two
published [hopefully, see note below on status confusion] entries, and
I can navigate there to view the entries. But once I log-out, the
entry is invisible.
If you are not logged in as an admin, then the admin-panel will not be
visible. Blog entries should be visible to non-authenticated users from
the main blog list - the page where you put the
(:includesection #blog-summary-pagelist blogid=blog1 status=publish:)
I'm a little confused by the authorizations and terminology on the
BlogIt cookbook page... the default AuthUser example is for two users,
I want only one (myself).
I've provided a sample as a response to the other email.
Additionally, I'm confused by the differing terminology... at some
points, blog appears to refer to an individual post/page... at other
times, it refers to a group of posts belonging to a person.
I try to use blog-entry to mean a single post, and a blog to mean the
list of all posts. I may not be consistent, so if you can improve it,
your help would be welcome.
Although blogid is required for the main blog page, I can't find
this defined anywhere; I'm assuming that blog1 is the default id for
a single blog.
Correct, blog1 is the default if you only have a single blog. If you
want more than one blog, define:
$bi_BlogList = array('blog1','blog2')
Does a non-logged in reader need to have view permissions created?
No. The norm is for non-authenticated users to view blog-entries.
This is confusing, since the recipe page says Most blogs are not
public. I do want my blog to be public; but restrict administration
to myself.
The behavior you want is the norm. Blog-entries are public;
administration requires authentication. Again, if you have an alternate
phrasing, feel free to propose or change it.
Publish and Published are used at different times to refer to an
post status. Since Publish is a verb, I would think this is the
action required to move a post from Draft to Published (and not a
status itself). So I'm not entirely sure I've actually changed the
entry from draft to published.
The term Published simply refers to blog-entries of status Publish. You
can view the blog-entry status from a number of places -- probably
easiest is from the edit screen.
However, I do have distinct entires appearing under the Published
and Draft pages. Also slightly confused by the word Publish
appearing under Action on the Published page... this suggests to
me that they are NOT published
The bold Draft/Publish on the admin-list is meant to be a sub-header.
the Action header refers to the action-links under that (edit/delete, etc).
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Another approach to section editing
This looks like it might be a good starting point: http://www.pmwiki.org/wiki/Cookbook/Qnotes On 8/7/2010 1:33 AM, Randy Brown wrote: I posted a question a while back, but only got one response. Let me try again with more detail. Could someone who knows PmWiki, PHP, and javascript please give me some guidance before I embark on what for me would be a several week project that might end in total failure? I want to make section editing easy and correct. By section I mean anchored section, title, or page text variable. I've looked at the Sectionedit and Fox recipes. Unfortunately Sectionedit requires links on the browsed page, while Fox doesn't yet handle simultaneous edits. Fox also changes unedited text slightly, which disrupts page revision comparisons. I think the simultaneous edit problems that Fox has might be avoided by taking a simpler approach. Basically, I want my edit form to allow the user to select a section of markup to view and edit. For example the form would show (below Editing MyPage) the following line: Section: All Title MyPTV MyAnchoredSection etc. These section names would be links. I already have markup that shows me these section names - so that's not an issue. I'd like the following behavior: action=edit would, as usual, show the user all the markup on the page in the edit form's text area. However, while editing, the user would be able to click on a link to another section to view and edit just that section. The links on the edit form that offer section editing could also be placed on the browsed page (or any other page) - they just don't have to be. A server-based approach could have the edit form contain links that end like action=editsection=MyAnchoredSection. The server would read the URL's parameters and show the user only the section to be edited. (What comes before and after would be hidden on the form.) A client-based approach would be to have the edit form simply read the URL parameters to determine the *initial* section to display. Javascript would then allow the user to change to another section. The advantage of this approach is that each edited section doesn't have to be saved before another section can be edited. Save simply reassembles the parts (hidden-prefix, visible-text-to-edit, and hidden-suffix) before returning the whole to the server, reversing the splitting it did when the form was loaded. The server doesn't have to know the difference. I'm completely ignorant about Javascript, and naive enough about PHP and PmWiki that I'm afraid I'll spend weeks trying to learn Javascript etc. and then discover it can't be done, or that I've done everything the wrong way. But I know that javascript is successfully used for spell check and guiedit buttons - so it seems like it might be possible. Would anyone be willing to mentor me or work with me on this? Does anyone have any suggestions about which approach is more likely to work: server-based or client-based? Should I start studying Javascript, or is that the wrong direction? Randy ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users Internal Virus Database is out of date. Checked by AVG - www.avg.com Version: 9.0.839 / Virus Database: 271.1.1/3012 - Release Date: 07/17/10 14:35:00 ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Page update being blocked by administrator
I keep getting the message This post has been blocked by the administrator. I'm trying to add some links to Cookbook/BlogIt, specifically: * [[http://jqueryui.com/ | jQueryUI 1.8.4]]: Responsible for the dialog boxes, and a few of the visual effects. Also used on the Tag field to suggest values. * [[http://validity.thatscaptaintoyou.com/ | Validity 1.1.0]]: Form validation, cheking dates, emails, and required fields. * [[http://showMessage.dingobytes.com/ | showMessage 2.1]]: The slide down ajax message effect. When I had this before it was due to the update containing too many links. In this case, I can't post the page, even if I do the updates one at a time. What limit am I hitting now? ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Page update being blocked by administrator
On 8/7/2010 8:37 PM, DaveG wrote: I keep getting the message This post has been blocked by the administrator. I'm trying to add some links to Cookbook/BlogIt, specifically: * [[http://jqueryui.com/ | jQueryUI 1.8.4]]: Responsible for the dialog boxes, and a few of the visual effects. Also used on the Tag field to suggest values. * [[http://validity.thatscaptaintoyou.com/ | Validity 1.1.0]]: Form validation, cheking dates, emails, and required fields. * [[http://showMessage.dingobytes.com/ | showMessage 2.1]]: The slide down ajax message effect. When I had this before it was due to the update containing too many links. In this case, I can't post the page, even if I do the updates one at a time. What limit am I hitting now? Turns out it was the *total* number of unapproved links on the page. Once I approved some of the links, I was able to add the text above. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] html title
On 7/18/2010 3:01 PM, jdd-gmane wrote: I would change the title of my main page (the html titler, the one that is displayed on the browser top) how can I do this, I don't find the solution in the pmwiki web site ## $WikiTitle is the name that appears in the browser's title bar. $WikiTitle = 'PmWiki'; Is the primary way to change the title. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Recipe's for Facebook Like buttons and OpenID userauth
On 7/12/2010 6:00 AM, Ville Takanen wrote: Is the recipe at http://www.pmwiki.org/wiki/Cookbook/AuthUserOpenId still actively maintained? The last page update by the author *seems* to be back in 2006/7 (page history has been truncated due to inactivity). The authors domain name is also expired. A quick search through the mail archive didn't turn up anything that appeared to be from the author. These *suggest* that the recipe is no longer actively maintained. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Error Message
On 7/8/2010 11:38 PM, Franklin S Werren wrote: I moved a site from one server to another and I am getting this error message at the bottom of the page and cannot log in. Is there an easy fix PmWiki can't process your request Cannot acquire lockfile The lock file is located in wiki.d, so make sure the permissions on wiki.d are set to allow write access by the server, 744 typically. Given that the permissions on that directory are incorrect, you might want to verify that other permissions are the same as they were on the original server. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Error Message
On 7/8/2010 11:38 PM, Franklin S Werren wrote: Hi All; I moved a site from one server to another and I am getting this error message at the bottom of the page and cannot log in. Is there an easy fix Thanks Frank PmWiki can't process your request Cannot acquire lockfile Just thought, it might be the permissions on the lock file itself wiki.d/.flock, you can either change the permissions, or it's pretty safe to simply delete the file -- it will get recreated by PmWiki. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] BlogIt tags/categories
On 6/14/2010 9:20 AM, Amos Satterlee wrote: I'm new to PmWiki. I installed it locally on my Windows 7 box very easily, and installed the BlogIt recipe, also very easily. Now I'm testing and learning. I want to have both blogging capabilities and traditional wiki capabilities in one site. By that I mean I want to be able to create blog entries through the BlogIt form interface and to write longer articles as new pages in the traditional way. I have noticed that when BlogIt is enabled, it seems to override the PmWiki category engine. I am finding that if I put a category link on a traditional page [[!category]], the category is not picked up by either the PmWiki category engine or the BlogIt tag engine. Am I missing something in my set up, or is this an issue? You should be able to do exactly what you're describing, but looks like something is preventing the category markup from working correctly on traditional pages when BlogIt is enabled. I'll take a look. Thanks for letting me know. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria problem
On 6/8/2010 10:24 AM, pmw...@911networks.com wrote: On Tue, 08 Jun 2010 08:39:17 -0400 DaveGpmw...@solidgone.com wrote: 2. Is there a way of displaying text next to the image as an explanation? Meaning that the text will change with each image? * Attach:photo1.jpg|'''Display text for photo1''' * Attach:photo2.jpg|'''Display text for photo2''' doesn't work. That is not yet implemented. I had plans to do it, but never made time to actually work on it. I have found that I can display some text by using the alternate: * Attach:photo1.jpgAlternate text for photo1 will display|'''This text will not display''' I don't know either php or javascript. But I took a look at galleria.php . Where do you process the image list? Can you point me in the direction and see if I can do something? The image list is processed from jquery.galleria.js (note though that by default jquery.galleria.pack.js is used, so if you plan to make changes, point HTMLHeaderFmt to the non-packed version). The to jquery.galleria.js is made galleria.php. Basically you'll primarily be changing jquery.galleria.js. Documentation for the is here: http://monc.se/kitchen/146/galleria-a-javascript-image-gallery Also note that there seems to be some activity for a new release of galleria.js, which appears to have support for a description. At some point I'll take a look at upgrading Galleria to the new release of galleris.js. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] alternate edit form using Fox
On 6/11/2010 9:14 PM, adam overton wrote: Hi there! i'm thinking about spending some time this summer using fox to create an alternate edit-form for my wikis. the point would be to display a simplified/prettified edit-page-interace when an editor calls something like ?action=editsimple. I imagine it would probably do some of the following: 1. detect and extract any PTVs from the current page and present them as 1-line text inputs 2. detect and extract any PTV sections from the current page, and present them as a multi-line text area 3. present the text for the page in a large text area (like usual), but minus all the PTV PTV section markup 3. automatically add any common/necessary explanations next to or above some of these fields In essence, this is what BlogIt does, using PTVs formatted with PmForm. The key functions are bi_HandleBrowse() which handles the 'viewing' of the form (with no action specified, but that's easy to implement), and then bi_HandleProcessForm() which handles the action when the user submits new values from the page form. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria problem
On 6/8/2010 1:58 AM, pmw...@911networks.com wrote: On Mon, 07 Jun 2010 18:08:32 -0400 DaveGpmw...@solidgone.com wrote: On 6/7/2010 2:57 AM, pmw...@911networks.com wrote: Hi, I'm trying to get galleria to work without any success: ... I just used your markup and everything worked. My guess is that the script is not included correctly, back in 2. Thanks 1. You were right. I've fixed it. It had to do with a wrong scripturl. 2. Is there a way of displaying text next to the image as an explanation? Meaning that the text will change with each image? * Attach:photo1.jpg|'''Display text for photo1''' * Attach:photo2.jpg|'''Display text for photo2''' doesn't work. That is not yet implemented. I had plans to do it, but never made time to actually work on it. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Galleria problem
On 6/7/2010 2:57 AM, pmw...@911networks.com wrote: Hi, I'm trying to get galleria to work without any success: 1. Extracted galleria to cookbook and pub like it show on the galleria page 2. config.php: include_once($FarmD/cookbook/galleria/galleria.php); 3. (:div id=demo1:) * Attach:gallery/bella.jpg * Attach:gallery/blue.jpg * Attach:gallery/booby_lou.jpg * Attach:gallery/buddy.jpg * Attach:gallery/chaos.jpg * Attach:gallery/fizz.jpg * Attach:gallery/hadden.jpg * Attach:gallery/hadden_park.jpg * Attach:gallery/harley.jpg * Attach:gallery/lance.jpg * Attach:gallery/lovey.jpg * Attach:gallery/marble.jpg (:divend:) (:galleria list=#demo1 ul carousel=true:) It only shows the photos as one after the other. No carousel, no switching between photos. I must be missing something, but I don't know what. It sounds like the cookbook script is not getting included, or perhaps there is a conflict with another recipe? Are you loading another recipe which uses jquery -- there may be a version issue. I just used your markup and everything worked. My guess is that the script is not included correctly, back in 2. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] problem with internet explorer
Xueli, We need more information in order to help you. Are you able to provide a URL so we can take a look at the page? If not, take a screenshot under Firefox and IE so we can see the problem. At the very least describe the differences you're seeing. ~ ~ David On 6/3/2010 3:03 AM, Xueli Wang wrote: Hi All, Who knows why my html page can be displayed nicely by Mozilla but not by internet explorer? I also have some text files which can be nicely shown by Mozilla but internet explorer makes a big mass of it, WHY? Thanks in advance for your tips! Xueli wang KNMI The Netherlands ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users Internal Virus Database is out of date. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2703 - Release Date: 02/22/10 03:34:00 ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] password must be entered everytime
On 5/31/2010 3:54 PM, Walter Keller wrote:
Hello
Since I upgrade to Ubuntu Lucid Lynx, 10.04 LTS, I have to enter the
edit password twice for every edit. I use the wiki locally with apache.
PhpInfo says
session.save_path /var/lib/php5 /var/lib/php5
I did a chmod 777 var/lib/php5 and restarted apache still the same
I remove all session files on the directory, new session file were
create, but the problem persists.
Has anyone an idea how to fix or debug this?
Same question came up earlier:
http://www.mail-archive.com/pmwiki-users@pmichaud.com/msg19911.html
Basically, this is either related to PHP 5.3, in which case you'll need
to upgrade to the latest PmWiki.
Or, I've also seen seen similar behavior when the tmp directory that
session files are stored in is not defined. This could very well have
changed with an OS/server upgrade.
This in config.php works for me:
session_save_path('/path/to/tmp/sessions');
~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users
[pmwiki-users] Category Links
Is there a way to include a category link on a page, and have that link display any title markup that might be on the category page? So: [[!MyCategory]] With Category.MyCategory containing: (:title override:) And the link should display: override Refer to this page, where the category link does not display the override title: Test/CategoryTitles-Draft I could do something below, but that doesn't create a category link: [[Category.MyCategory | +]] ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Category Links
On 5/30/2010 3:34 PM, Peter Bowers wrote: On Sun, May 30, 2010 at 8:31 PM, DaveGpmw...@solidgone.com wrote: Is there a way to include a category link on a page, and have that link display any title markup that might be on the category page? So: [[!MyCategory]] With Category.MyCategory containing: (:title override:) And the link should display: override Refer to this page, where the category link does not display the override title: Test/CategoryTitles-Draft I could do something below, but that doesn't create a category link: [[Category.MyCategory | +]] I believe that Petko's solution to Pits:00447 made [[!MyCategory | +]] work, but unfortunately there was never a clear consensus on the pagelist markup and so the fix was never released. Ah. So now the problem is that I could use the [[!MyCategory | +]] format, but the link is displayed with the page doesn't exist style link formatting, and as far as I can see there is no way to selectively apply this to certain links on a page, so that category links have the page exists styles, and other links are handled with normal processing. BTW, what do you mean when you say [[Category.MyCategory | +]] doesn't create a category link? I know there was discussion about differentiating between [[Category.MyCategory]] and [[!MyCategory]] (see same PITS entry) but my understanding was that no actual changes occurred and those 2 markups are functionally interchangeable as things stand... I based this statement only on the fact that one form displays with the page doesn't exist style link formatting, and the other displays with the page exists style formatting. As you say, they both get treated the same in terms of being displayed on a (:pagelist link=...:) markup. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] Category Links
On 5/30/2010 3:49 PM, DaveG wrote: I believe that Petko's solution to Pits:00447 made [[!MyCategory | +]] work, but unfortunately there was never a clear consensus on the pagelist markup and so the fix was never released. Ah. So now the problem is that I could use the [[!MyCategory | +]] format, but the link is displayed with the page doesn't exist style link formatting, and as far as I can see there is no way to selectively apply this to certain links on a page, so that category links have the page exists styles, and other links are handled with normal processing. Is there a way to call MakeLink() and have the link display the title-spaced LinkTxt, through the $txt parameter? ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.org web server instability
Same -- large number of timeouts, usually lasting around 5-10 minutes. Several per day, over the last 10 days or so. On 5/28/2010 6:43 AM, Eemeli Aro wrote: For the last week or so (hard to say exactly) I've seen brief periods when pmwiki.org and pmichaud.com have been refusing connections on port 80. SVN has still worked, mind. Anyone else experienced the same, or is it just me? eemeli ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users Internal Virus Database is out of date. Checked by AVG - www.avg.com Version: 9.0.733 / Virus Database: 271.1.1/2703 - Release Date: 02/22/10 03:34:00 ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] A robust user registration module
On 5/28/2010 6:35 AM, Eemeli Aro wrote: On 27 May 2010 17:16, Wordit Ltdwordi...@googlemail.com wrote: - The data does not have to be stored *before* verification because the data will be sent back when the user clicks the email link, and the key tells us if it's correct. The way I see it, storing the new user data on first submission is a relatively easy task, no matter what background storage system is used. We'd need some way to manage the likely spam signups. Perhaps placing the 'pending verification' data in a separate page would suffice. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
Re: [pmwiki-users] pmwiki.org web server instability
On 5/28/2010 5:09 PM, Chris Cox wrote: I've been running into the same thing. Cursory look at the server... I'm not seeing anything right now. Same problem, right now. ~ ~ Dave ___ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
