• View
• Edit
• History
• Attach
• Print
• Backlinks

WikiCalendar-Talk

Comments

(:wikilog Calendar:) in another group than Calendar, e.g. Main, fails to visually display the current month and the next whereas Calendar.Calendar displays them properly. Also the possible alternative (:include Calendar.GroupHeader basepage=Calendar.Calendar:) do display the month view with the tables but the links point to Main.YYYYMMDD instead of Calendar.YYYYMMDD. Any solution?

Utopiah December 05, 2011, at 01:36 PM

WikiCal seems to have an unfortunate habit of changing dates in a certain format (ISO 8601) to another format, eg

becomes

simon August 19, 2010, at 04:46 PM

• (2009-19-06) the english version is different to the other version. I tried to translate the spanish version, please review if this is correct.

wikilog-i18n-en-draft.phpΔ

• Apparent bug. Should add rel="nofollow" tags for links to create pages or for adjacent months/dates. AriEpstein
  • added in version 0.3.42 jr
• Found a bug. Try to add a link like this one [(approve links) edit diff] inside a page on a wikicalendar. It will substitute 2003-06-06 and mess up with the link. ThomasGirod?
  • should be fixed in version 0.3.40 and above jr
• (:wikilognav:) is a really good idea, but I don't see the point of it in it's present implementation. It doesn't seem to accept the Group.Page parameter. Therefore, adding this markup outside of the actual group makes it useless. Pretty boring if you want to add it to Site.SideBar rather than $Group.SideBar ...
  • added in version 0.3.41 -- to use the default calendar home page, write (:wikilognav Group:); to point to a specific page, write (:wikilognav Group.Page:) jr
• I had a problem with a url on page not in the calendar being rewritten to long date format. This patch fixes that problem. I had to move the code to after the includes to make it aware of current calendar name for the current locale. This might be useful for others. I really like this calendar!
  • I also had a problem with the dates being rewritten in a blog-like group. I couldn't get the patch to work, so instead added the include_once line to Calendar.php in my /local file. It wasn't vital to be able to list items from WikiCalendar in other groups (though it would be nice in the future with another solution), and it keeps WikiCalendar from converting the blog dates. If there is another way to override the date rewriting, please let me know! RussJackman
    • this should be fixed in version 0.3.40 -- I assume this refers to use of a link like [[http://www.example.com/2006-05-20]] jr
• Is there any way to discard past events from listing in wikilog ? Thanks a bunch forceflow
• The author box should pick up the author from the PmWiki cookie and automagically insert it. Otherwise, this is pretty nifty. --RobinS
  Done. jr
• Any chance for to make available some screenshots of the calendar?+
  Done. RussFink
• Attempting to view the Calendar/Calendar page via Printable View does not show the calendar (for me; my version is pmwiki-2.0.beta26). RussFink
  This is probably because the calendar markup is in the GroupHeader page, which is omitted from printable views. To solve this, add the (:wikilog:) markup to the GroupPrintHeader page. I don't think I have ever tested this! jr
• How can I use this to make a Blog on my site? The Thom's hacked wikicalendarforblog a fair amount but his code is not available for pmwiki 2. See the discussion at PITS.00028. I'm very interested in using PmWiki as a more flexible Blog engine. --deelar
• I installed the Calendar add-on with the hope that I could modify it to fit my needs:
  • I'd like to have one page for each day of the year (like Calendar/July12 or Calendar/December23), and have the specific date pages automatically include the contents of the appropriate day-of-the-year page (e.g. Calendar/20050712 would include Calendar/July12 at the top of it)
  • I installed the (:edited ...:) add-on, hoping to use it to auto-include day-of-the-year pages, but it kind of breaks if I try to include its output in the output generated by (:wikilog:). Here's the code I wrote in wikilog.php:
  function month_day_link($title) {

        global $monthnames, $pagename;
        $month = substr($title, 4, 2);
        $day   = substr($title, 6, 2);
        if ($day[0] == "0") { $day = $day[1]; } // no leading '0' on days
        $monthname = $monthnames[$month - 1];
        $monthday = $monthname.$day;

        $monthday_include =
          MarkupToHTML($pagename, "(:included $monthday:)").
          "<br />";

        return $monthday_include;
        }

• I also modified the function view_calendar() :

  function view_calendar($pagename,$homepage) {
          global $calendar_months_start, 
          ...
          ...

        // check to see whether to display a summary only
        if (IsDate($title) && ($summary_only==true)) {
                $r = "<p class='datetrail'>".adjacent_entries($group,$title)."</p>\n";
                // new link to the general month-day page
                $general_day = month_day_link($title);

                return $general_day.$r.set_page_title($title)."<h3>".longdate($title)."</h3>";
        }
        ...
        ...
        }

• So ... this is a big hack, and it's not working quite correctly -- it looks like the content generated by (:included $monthday:) is interpreted 1-1/2 times. I first tried it without the call to MarkuptoHTML(), but then the wikimarkup on the included page was not rendered (except for squarebracket links -- those came out okay). Help?

• I'd like to have a template for the day content entries (to prompt me to record a bunch of different things everyday). Any suggestions on how to do this? - efm
• The (:pagelist fmt=#title:) displays + as the title, even if a page has a title defined. Is there a way to fix this so it displays the title? (See example here ). I'm in the process of transferring Performances to this new Calendar format, but before I do, I want to have a way of listing all entries. Previously, I used the pagelist directive as mentioned, but if there is an alternative way to list all entries, that would work, too.

New Features

I have downloaded the Calendar component of PmWiki and have got it up and running on my local test wiki. It adds valuable functionality to PmWiki, but I have some suggestions that I believe would make it simpler to use, more versatile, and applicable in more situations. Here goes:

• Why are the markups of WikiCalendar so picky about leading/trailing characters? It is unintuitive for users that are trying to set up a wiki calendar, and the (:searchbox:) markup does not have this problem.
  Can you clarify this point, please? If you mean, why does (:wikilog:) have to be on a line by itself, it's to try to ensure it generates valid xhtml.

  OK, that was actually my question. I understand the xhtml concerns, but for someone who is trying to get wikilog up and running, I still think that layout errors would be preferrable to just the markup just not working. I, for one, did quite a bit of fiddling before I found that the trailing space was the problem.

  Very true! It now allows trailing spaces.
• There seems to be no special reason why (:wikilog:) and (:wikilognews:) should have a different syntax. (:wikilognews:) requires a group parameter and does not work without it, but (:wikilog:) can not use it and can therefore not be used to reference a log in another group than the calendar should be displayed in. Ideally, the group parameter should be optional for both these markups.
  I like the idea of simplifying the markup. The reason for separate markups currently is that the following are all allowed:

  1 (:wikilog:), which makes Group.Group the home page of the calendar

  2 (:wikilog XYZ:), which makes Group.XYZ the home page of the calendar

  3 (:wikilognews XYZ:). which generates a list of the latest calendar entries from the calendar on page XYZ.XYZ

  4 (:wikilognews XYZ.HomePage:), which generates a list of the latest calendar entries from the calendar on page XYZ.HomePage
  If we merge the 2 directives, how do we distinguish between examples 2 and 3? I need to think on this some more.

  I was not suggesting that the directives be merged, just that the parameter handling is the same. It is good to have the two directives. The problem is that it is impossible to display a calendar for another group than the current group (if I understand correctly), and that wikilognews does not work without a parameter. However, there is clearly something about the "home page of the calendar" that I am not getting. My intuitive feeling of how this should work is like this:

  1 (:wikilog:) displays a calendar for the current group

  2 (:wikilog XYZ:) displays a calendar for the XYZ group

  3 (:wikilognews:) displays a list of the latest calendar entries from current group

  4 (:wikilognews XYZ:) displays a list of the latest calendar entries from current group

  Note that there is nothing here about a home page for the calendar since I do not fully understand how that works.

  Suppose there is an entry for yesterday, today and tomorrow and we are looking at today's entry. There will be a navigation bar like this assuming that today is 27.02.2005):

  << 26.02.2005 | Calendar | 28.02.2005 >>

  The middle 'Calendar' link points to the home page of the calendar group. By default, this will be 'Calendar.Calendar'. The (:wikilog:) directive displays a calendar and the first paragraphs of recent pages on pages that aren't dates, and the navigation bar on pages that are dates. The inconsistency you observe is historical: first there was just (:wikilog:) which put everything about the calendar in one group; then somebody asked to display calendar entries from another group, which led to (:wikilognews:). Your suggestion is excellent -- I'll see if I can make it work, without breaking existing sites...
• I would think that it was easy to add a new markup, (:wikiloglist:), which works in the same way as (:wikilognews:), except that instead of just the first line, it lists the complete contents of each log in the month. This would be a great addition to the WikiCalendar component, and ideally it should accept a group as an optional parameter.
  If we place the markup evaluation early enough in the sequence, we should be able to achieve this by generating a series of (:include Name:) directives.

  Yes, that would be a really neat solution. Again, my intuitive feeling would be that:

  6 (:wikiloglist:) displays the latest calendar entries in full, from current group

  7 (:wikiloglist XYZ:) displays the latest calendar entries in full, from XYZ group

Sorry about just making requests, without any solutions. To my defence, I tried to do the mentioned modifications myself, but I found that changing the markup was a bit more complicated than I first thought. I am putting up these requests in the hope that this is a problem with me, and not with the markup funktionality of PmWiki :-). If this is the wrong place to make such a request, I'm also sorry about that. --Magnus

• It would be great to have a command for "display all entries of the current day" (like: include the page here that has the current date)
• ever thought of adding a namespace to the calendar pages? Imagine a team wiki with many project plans, each one needs a dedicated calendar. Something like (:wikilog namespace=cal1:) would display a calendar with all entries that start with cal1 and also create pages with this name Uli
  You can do this using WikiGroups. Create the following pages, each containing a (:wikilog HomePage:) directive: Cal1.GroupHeader, Cal2.GroupHeader, Cal3.GroupHeader and so on. Next, create all the Cali.HomePage pages. Finally, you can set up a news view across all the calendars as follows... In some other group, such as Main, create a Main.CalendarNews page with the following directives:

  (:wikilog Cal1:)

  (:wikilog Cal2:)

  (:wikilog Cal3:)

  and so on
  Before you set up the news page, make sure the pages Cali.HomePage all exist. Because the directive (:wikilog Thing:) is evaluated in the following order:
  1. if CurrentGroup.Thing exists, treat the directive as a calendar for the current group
  2. if Thing.Thing or Thing.HomePage exist, treat the directive as a reference to a calendar in the Thing group
  3. otherwise, treat the directive as a calendar for the current group, with a 'create page' link on CurrentGroup.Thing
• How about a feature to show just the calendar entries falling this week (Monday to Sunday rather than for the next 7 days) - this would be ideal for a club news / forthcoming events quick reference. I might have a go myself at this but I can't spare the time now to learn PHP until my C code is working and released, paying the bills to enable me to improve my PHP! James

Date Formats

Because I have been struggling a bit to work out how Wikilog formats dates and which of its various formats it uses when, I thought I'd write up what (I think) I've discovered. Correct me if I'm wrong.

There are four (4) separate date formats. Actually five if you count what wdate markup matches.

• Internal date format
  • All calendar date pages must be named in the format yyyymmdd. This is a hard-coded requirement referenced in multiple places. You can't, eg, just change a mask to have them suddenly become 'yyyy-mm-dd'. (I think PmWiki doesn't like hyphens in page names anyway - it seems to mess up the SpacedWikiNames display).
  • The function IsDate() is used in varous places to check if the current page name is in date format, ie, yyyymmdd and that those combination of digits make a valid date.
• $SpaceDateString format
  • If the current page is a date (by IsDate), then $SpacedName is set to the date string with its last two sets of two digits separated by $SpaceDateString (either '-' or '.'). IE, yyyy-mm-dd or yyyy.mm.dd. This will always generate a short date in International year-month-date order, regardless of the US or European format setting.
  • (Is $SpacedName used internally by PmWiki? It's not used by Wikilog otherwise).
  • a (:title:) directive is also generated on each date page to set the page title to the equivalent of $SpacedName, using the same formula (but not using $SpacedName itself)
• shortdate() format
  • When displaying the list of calendar entries for a month, Wikilog uses the shortdate() function which formats in American (mm/dd/yyyy), European (dd.mm.yyyy) or International (yyyy-mm-dd) format based on $calendar_datestyle
  • shortdate() is also used when showing the WikiTrail markup at the top of each date page
• longdate() format
  • a long date (function longdate()) is added as a subtitle to each date page
  • the 'wdate' markup is added which automatically replaces any string in the form 'yyyy ( . or / ) mm (. or / ) dd' with its longdate() equivalent. Essentially that matches any variant of $SpacedName (but not shortname())
  • longdate() seems also to be used for the 'publish' action but I have not tested this
  • longdate() is also used by the (:wikilogtitle:) markup which apparently displays the current page's title as a long date (but I have not got this to work either)
• I'm trying to edit wikilog.php so on the list of pages, the Year doesn't appear (it's quite redundant in this situation). Can anyone help me out? kev?

Nate

Quick patch to the calender_month() function -- eliminates leading 0 in calendar days under the 10th of the month, replaces with ($dayn = "day name") & non-breaking space, to keep right (numeric) alignment:

		if ($i<10) { $day="0".$i; $dayn = "&nbsp;" . $i; } else { $day=$dayn=$i; }
		$entryname= $prefix . $day;
		$r.="<td class='calendar-";
		if (abs($todays_time - mktime(0,0,0,$month,$i,$year)) < 86400) {
			$r.="today-";
		}
		if (PageExists($entryname)) {
			$r.="entry'><b>[[". $entryname . "|" . $dayn . "]]</b>";
		} else {
			$r.="noentry'>[[". $entryname . "|" . $dayn . "]]";
		}

XES December 09, 2006, at 07:41 PM

I have created a Dutch translation for the WikiCalendar. Should I just attach it? DJ -> mailto:pmwiki [snail] nldj [period] com 2007-aug-02

Is it possible to mark/show only calendar dates that actually contain some text or markup?

This might be useful for users who use the $AutoCreate function for calendar entries, and it's quite easy. Just open the file wikilog.php and replace every occurance of

  PageExists(

with

  wikilog_page_exists(

Then you only need to add the following lines to wikilog.php:

// Whether to display all pages in calendars, disregarding whether they
// actually include text.
// Enter 'false' to display only pages that include text.
SDV($calendar_display_empty_pages,false);

function wikilog_page_exists($pagename)
{
  global $calendar_display_empty_pages;

  if (PageExists($pagename))
  {
    $page = RetrieveAuthPage($pagename, 'read');

    return $calendar_display_empty_pages or
        isset($page['text']) and $page['text'] != '';
  }
  else
    return false;
}

That's it. Enjoy, mzuther March 02 2009

Recipe author's error!

The following removed comments arose because jr must have inadvertently uploaded the i18n file from WikiForms instead of WikiCalendar. He sends his profuse apologies. The latest wikilog-i18n-en.phpΔ file should be correct. Thanks to Conrad Edwards for drawing this to my attention.

The new i18n file should fix all these problems. jr March 08 2006, at 02:39 PM

Is there a way to move the date under the calendar above it, or totally remove it? Is there a way to edit navigation links above the calendar - to get the year showed with two numbers like 08 or showing thew year not at all? Is there possibility to get a variable like $PmCalDName in PmCalendar - I'd like to use something like

$PmCalDName: %Y%m%d%W%a 

to save the information I need. And is it possible to get the pages opened from calendar not to open in editpage?
Thanks, Teukka

The files wikilog-i18n-en.php, wikilog-i18n-fr.php and wikilog.css on this page are not linked anymore, but produce an underlying .htaccess file instead. I also think that putting recipe and the optional translations into one small archive would be nice. And the translation files should be encoded in UTF-8, maybe in additional files. At least the current German translation produces the wrong output when used on a UTF-8 encoded site.
Thanks, mzuther January 27 2009

March 15, 2009, wikilog-i18n-en.php gives the underlying .htaccess file. wikilog.css appears to give garbage.

Show multiple entries per day in summary

Our users who submit appointments through the form expect that multiple entries for a given date will all show up with their title in the summary below the calendar. My modified version (wikilog_fs.phpΔ, based on version 0.3.43) states every 4th order (!!!!) heading from a date page in its respective summary line, separated by " +++ ". This is a only a hack that works for us, and it seems to be against the original design, so it will break other features of the summary. As of Nov 2009, in the official version of wikilog.php, only the first paragraph of every date page is taken in to account. Since I have not the time to study this more carefully and to make a responsible contribution to the official version, I will leave you with my fork where I have marked my changes with "#fsmod". To John(jr) & al.: Please consider this as yet another suggestion for a useful, maybe optional feature. Frank November 28, 2009, at 10:12 AM

Regular expression replace with /e switch deprecated

Hallo John R.

Using your Calendar, works nice, behalves of one deprecated /e switch. PPRE solved it half. Would you please have a look (trying with rather new XAMPP e.g.)? in wikilog.php

		 $firstpara = PPRE("/\\[\\=(.*?)\\=\\]/s", 'Keep($m[1])', $firstpara);

1. forgoing line replaced the two following ones

		#$firstpara = preg_replace("/\\[\\=(.*?)\\=\\]/se",
		#    "Keep(PSS('$1'))",$firstpara);

PKHG