Hi,

I'm using PEAR Wiki Filter for a few months, and for me it became one of the most important extensions for Drupal, after Quicktags wasn't ported to Drupal 5.x. At first I tried to combine the PEAR WIki Filter with the "Freelinking" module, which permanently produced broken links, links to nonexisting nodes, etc. When this became unbearable, I disabled "Freelinking" and switched to using the "external links" syntax in combination with full Pathauto generated paths (like http://www.example.com/category/node-title). As my sites grow, this becomes unstable again, since e.g. changes in taxonomy alter the node's path etc. When using pathauto and browsing the site, you won't ever see the internal node IDs generated by Drupal, they only appear when editing a node.

The question is now, how I could accomplish stable links using MediaWiki syntax and PEAR WIki Filter. Even if my users could see Drupal's NIDs, a seemingly logical syntax like [[node/958]] wouldn't work.

What is the recommended hy to create internal hyperlinks when using PEAR Wiki filter?

Thanks for the PEAR Wiki Filter & Greetings,
-asb

Comments

Anonymous’s picture

When using [[page]] pearwiki expects the page title. Spaces are replaced with underlines, so this does not work for me. Another way to get internal links is using the syntax [[path:path_to_page|title]] e.g. [[path:node/10|My Node]].

asbdpl’s picture

> Another way to get internal links is using the syntax [[path:path_to_page|title]] e.g. [[path:node/10|My Node]].

Thank you for pointing this out, I didn't know the [[path:node/10|My Node]] syntax. However, nothing of this works for me, not even technically, left alone that my users won't be able to use this syntax.

I assume, in the filter's configuration, "Use wiki links?" has to be enabled; I *disabled* this a long time ago since there is no non-changing "Base path for wikilinks" that would work (I'm not using "/wiki" either, and not all node types point to "/node" on my sites).

If I enable "Use wiki links?" and leave "Base path for wikilinks" blank, a working link is created, indeed. However, this would only work for my users if the'd know the NID - which they usually don't since I'm using the Pathauto module; the only way (as fas as I know) to identify the NID is to *edit* the node. Even if my users would try to do that, they wouldn't succeed in some cases since not every user can edit every node created by other users. And even if I'd loosen the access permissions again, this method would be time consuming, and error prone - exactly that's why I tried to prevent with the faster and easyier MediaWiki input format. The NID syntax would - at least for my site - only work, if the node itself and functions like Search and Related nodes could show the NID. How are you solving this?

> When using [[page]] pearwiki expects the page title. Spaces are replaced with underlines, so this does not work for me.

The "Replacement for Spaces" can be configured in the filter's settings, also, but this is circumvented by the MediaWiki filter ("This option is ignored for the Mediawiki format since the parser alredy replaces spaces with underscores"). However, the original MediaWiki parser doesn't care if you link to [[my node]] oder [[my_node]], so this seems to be simply a bug in PEAR Wiki filter.

Thanks & Greetings, -asb

Anonymous’s picture

At least for me it works to specify either [path:node/10|title] and [path:path/to/node|title] e.g. [path:projects/pearwiki_filter|PEARWiki filter]. I'm also using pathauto. Just try it out.

asbdpl’s picture

> I'm also using pathauto. Just try it out.

The main problem remains the NID that my users won't see until they edit the taget node (e.g. www.example.com/node/21190/edit), and that they can't do in all cases. When simply browsing the sites, they will only see paths like www.example.com/path_to/my_node, and to those they can't link with the mentioned syntax, only with full URLs like [http://www.example.com/path_to/my_node].

If you're using Pathauto module, I still don't understand how you are donoting the NID of your target nodes to someone who wants to link to them. I was quickly browsing your blog (glanznig.com, btw. very nice design ;) and haven't seen any internal references there. Let's say, for example, if I want to write a comment and want to link to http://glanznig.com/europa_auf_schuahbandln, how would I identify the NID required by the syntax [[path:node/10|My Node]]?

Greetings, -asb

Anonymous’s picture

What I was trying to say in my last post was that you don't need the NID. It worked for me - not on my blog but on another site - to specifiy the actual path that was generated by pathauto. To use your example that would be then [path:europa_auf_schuahbandln|some title].

> btw. very nice design ;)
Thanks, but that is the modified Barron template. I hadn't much time and I will create a new template myself sometimes in the future. :)

asbdpl’s picture

> What I was trying to say in my last post was that you don't need the NID. It worked for me - not on my blog but
> on another site - to specifiy the actual path that was generated by pathauto. To use your example that would
> be then [path:europa_auf_schuahbandln|some title].

And that leads back to the original problem: Links generated by pathauto are *not* stable and *will* break (unless you *never* touch the configuration, and *never* update, and *never* override it with manual aliases).

Opposed to that, NIDs are stupid (no semantic meaning to the user), but stable and will never break, as long as Drupal is not critically damaged. Regarding the stability of the links, there is no major difference if I link to [path:europa_auf_schuahbandln|some title] or [http://www.example.com/path/europa_auf_schuahbandln some title].

Greetings, -asb

Anonymous’s picture

Ok, point taken. :) You're right.

flunardelli’s picture

wikitools module can solve troubles with path names and provide integration with freelinking module.
Try out.
I recommend mediawiki module filter instead of PEAR Wiki Filter.

mrded’s picture

Issue summary: View changes
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.