Discussion forum for the AliasPlugin

feel free to post some comments on the plugin here

-- OthelloMaurer - 09 Oct 2003

Othello, you used too many variables in this topic: every user read his/her own name as author and in the signature. I replaced the variable USERNAME by the true author name.

-- NilsBluemer - 09 Oct 2003

I did some minor editing on the Plugin topic.

FYI, there is a known issue with tables and <noautolink> tag: There must be at least one line between the end of the table and the closing noautolink tag, or the WikiWords in the table will be rendered as WikiWords

The Plugin assumes topics to be files (which is currently the case). You can make it more robust by using an official function to get the Plugin topic text, TWiki::Func::readTopicText( $web, $topic ). See TWikiFuncModule.

You could speed up the rendering if you build one regex search string in init like $aliasPattern = "(AlPlug|FooBar|MooMeow)"; and search for that string only once instead of looping through the hash, like
$_[0] =~ s/(\s|\()$aliasPattern\b/$1\[\[$topic\]\[$alias{$2}\]\]/g;

-- PeterThoeny - 10 Oct 2003

I am trying to use "forced" aliases (i.e., aliases in non-capitalized format, like in TWiki.wiki words by using [[TWiki.wiki words]]). It doesn't seem to work. Is there a way?

-- BalazsKegl - 16 Oct 2003

Thanks for your tips, I made the changes suggested by you, Peter. I don't really know how to measure the speedup, but obviously there must be one

Balazs: sorry it is only working for aliases in wiki-style. thus it is quite simple to have in mind, that if you type a wiki-style word, it will change later. if it is an already existing topic, or if there is a registered alias, it will become a link, otherwise it will be marked as 'unknown' by the wiki. it is possible to change the plugin source to allow non - WikiWord - aliases. maybe i'll implement it, triggered by a config flag soon (if you like it).

-- OthelloMaurer - 16 Oct 2003

Yes, Othello --

Please do see if you can implement the modifications to allow Aliases from non WikiWords. Especially useful would be all capitals. For example, it would be great if TLA could be used as an alias for ThreeLetterAnacronym .. you get the idea.

Thanks.
-- KeithHelfrich - 29 Oct 2003

Added support for non WikiWords as an option.

I am going to use it as a simple way to render initials as links in meeting minutes etc.

-- NielsKoldso - 30 Nov 2003

I like this plugin, but unfortunately it seems to be a little too aggressive about deciding what to replace. It mangled the names of my appended files, for instance, and broke links.

-- VaciKoblizek - 08 Jan 200

One suggestion that I have would be to provide replacement templates so that they don't change. For instance, I have some one word topics, and the ability to have an alias to automatically assign links is a godsend. However, on the actual topic page, the top and bottom banners now link the topic name, and the editing links (edit, attach, etc) are broken. Perhaps having the <noautolink> in there? I'm fairly new to this, but I think that it's supposed to go in the templates/view.tmpl file.

Keep up the good work!

-- NathanBarhorst - 31 Jan 2004

AliasPlugin is broken with TWiki20040730beta... this little patch should fix it:

--- /u1/tmp/lib/TWiki/Plugins/AliasPlugin.pm    2003-11-30 14:58:36.000000000 -0800
+++ AliasPlugin.pm      2004-08-19 16:35:01.000000000 -0700
@@ -57,7 +57,7 @@
     # create alias hash
     foreach my $line ( @prefLines ) {
       if(($acceptNonTWikiWord && $line =~ /\|\s*(?:\)?(\w+)\s*\|\s*(?:\)?(\S*)\s*\|/) ||
-         ($line =~ /\|\s*(?:\)?($TWiki::wikiWordRegex)\s*\|\s*(?:\)?(\S*)\s*\|/)) 
+         ($line =~ /\|\s*(?:\)?($TWiki::regex{wikiWordRegex})\s*\|\s*(?:\)?(\S*)\s*\|/))
       {
           TWiki::Func::writeDebug("AliasPlugin (detail): Config match: key=$1, value=$2") if($debug>1); #heavy debug
           $aliasHash{"$1"} = "$2";       

I just tried AliasPlugin v1.011 (dated 11 Nov 2003) with the Twiki beta release of "07 May 2004" and it doesn't seem to work. I think there's a blank alias being expanded to a blank link. I get web pages like this:

[[][]]This [[][]]plugin [[][]]allows [[][]]you [[][]]to [[][]]create [[][]]Aliases [[][]]for [[][]]already

-- TroyGoodson - 02 Sep 2004

I will propose this patch for the Cairo release (because it uses a TWiki::Func function instead of TWiki.pm internal).

• The old AliasPlugin.pm used non-official TWiki.pm variable $TWiki::wikiWordRegex which is refactored in the Cairo release
• Now use official &TWiki::Func::getRegularExpression('wikiWordRegex') function to fetch the needed value.

--- lib/TWiki/Plugins/AliasPlugin.pm    2004-09-27 14:14:42.000000000 +0200
+++ lib0/TWiki/Plugins/AliasPlugin.pm   2004-10-11 23:49:30.000000000 +0200
@@ -22,7 +22,7 @@
         $debug $acceptNonTWikiWord
     );
 
-$VERSION = '1.011';
+$VERSION = '1.1';
 
 # =========================
 sub initPlugin
@@ -56,9 +56,11 @@
 
 
     # create alias hash
+    my $wikiWordRegex = &TWiki::Func::getRegularExpression('wikiWordRegex');
+    TWiki::Func::writeDebug("AliasPlugin (detail): Found wikiWordRegex='$wikiWordRegex'") if($debug);
     foreach my $line ( @prefLines ) {
       if(($acceptNonTWikiWord && $line =~ /\|\s*(?:\)?(\w+)\s*\|\s*(?:\)?(\S*)\s*\|/) ||
-         ($line =~ /\|\s*(?:\)?($TWiki::wikiWordRegex)\s*\|\s*(?:\)?(\S*)\s*\|/)) 
+         ($line =~ /\|\s*(?:\)?($wikiWordRegex)\s*\|\s*(?:\)?(\S*)\s*\|/)) 
       {
           TWiki::Func::writeDebug("AliasPlugin (detail): Config match: key=$1, value=$2") if($debug>1); #heavy debug
           $aliasHash{"$1"} = "$2";       

checked .zip into CVSplugins:AliasPlugin

-- WillNorris - 23 Nov 2004

Using, the all versions of AliasPlugin.pm (including the latest CVS checkin) on Cairo with perl 5.6.0, I get many messages like this in my apache error_log for every page view :

[Wed Jan 26 12:12:57 2005] view: Use of uninitialized value in concatenation (.) at /design/TWiki/twiki/lib/TWiki/Plugins/AliasPlugin.pm line 59.

Line 59 of the AliasPlugin.pm is here :

      if(($acceptNonTWikiWord && $line =~ /\|\s*(?:\<nop\>)?(\w+)\s*\|\s*(?:\<nop\>)?(\S*)\s*\|/) ||

The context is :

    # create alias hash
    foreach my $line ( @prefLines ) {
       if(($acceptNonTWikiWord && $line =~ /\|\s*(?:\<nop\>)?(\w+)\s*\|\s*(?:\<nop\>)?(\S*)\s*\|/) ||
         ($line =~ /\|\s*(?:\<nop\>)?($TWiki::wikiWordRegex)\s*\|\s*(?:\<nop\>)?(\S*)\s*\|/))
      {
          TWiki::Func::writeDebug("AliasPlugin (detail): Config match: key=$1, value=$2") if($debug>1); #heavy debug
          $aliasHash{"$1"} = "$2"; 
      }
    }

Can anyone advise how to rid myself of these messages ?

When I installed this plugin, it broke the wiki as described in the TroyGoodson - 02 Sep 2004 post above. To fix the problem, I removed the blank line from the alias configuration table on the AliasPlugin page that was installed. It now appears to work correctly. Should I update this in the zip attached to this topic?

-- RickMach - 09 Mar 2005

After using this, I was wondering if there is a way to control linking so that these links look different than standard wiki word links. I tried to do this by putting explicit html ("") instead of a WikiWord in the 2nd column but the macro doesn't accept that even though it is a valid link to the page I want.

-- RickMach - 09 Mar 2005

OK, first thing's first: TroyGoodson - 02 Sep 2004 post above about having the blank line in the table is correct, I understand that it is designed to imply the space where more macros can be placed however I think this should be done another way, it breaks the twiki with [[]][[]][[]][[]][][][[][[[][[[][[] stuff like that. He is also correct that removing the empty table row from the topic solves the problem.

NOW, with that said, I would like to thank each and every person who has had anything to do with the development of this plugin whatsoever from the bottom of my heart. I have been SCREAMING for this functionality to be implemented since my second day of registering on twiki.org . especially the extension to allow non wiki words to link without any sort of special prefix (ie: whitespace is good enough) At this moment I don't know who in particular is responsible for the implementation of that particular feature but I would like to find out so that I may personally thank them. Again, much thanks to all.

cheers! (travis does the happy dance)

-- TravisBarker - 19 Mar 2005

Othello was a student of mine doing the AliasPlugin on my advice. I dunno know if he's still checking back on TWiki.org. So I'll take over maintainership. Will merge in all patches into the official release soon.

-- MichaelDaum - 19 Mar 2005

Thanks Michael for the info (and quick response too). I did a modification to this plugin today to try out a different feature that I asked for almost a year ago. a feature that i described near the top of this topic. you can see it in action at ThetaBase:TWiki.MacroPlugin for now. I think I will be moving it to twiki.org in the days to follow.

-- TravisBarker - 20 Mar 2005

Hi Travis. I like your extensions very much and will backport them into AliasPlugin. Would you like to keep the MacroPlugin fork then? BTW, I've got the need to restrict aliases/macros a little more by the notion of alias-groups that get applied to complete webs or just one topic. We've got independent projects in their own web and having site-wide aliases will pollute each other's namespaces. I'm currently making up my mind on how to make customization easiest ...

-- MichaelDaum - 20 Mar 2005

Very good! If you are going to do a backport, there will be no need to use MacroPlugin namespace especially considering there is already a MacrosPlugin and it might be confused. its intersting that You and I have been thinking about similar issues (per web and per topic alias). I don't know how to approach the per topic thing, but we might be able to do them per web by having a separate table of aliases for each table and then modifying the regex in AliasPlugin.pm to match aliases depending on the current Web being called? I don't know, there might be a better solution, and I will browse the code in a few other plugins to see how that has been handled in the past. but I must warn you, my knowledge of perl is quite limited, so I don't know how useful I will be. Another thing that would be useful is throwing in a html parser to eliminate the problem we get in cases where an alias looks like stuff inside of html or javascript. ie: 'href', if aliased breaks a href= tags (you might be asking yourself why on earth i would ever want to create an alias for the word "href" but this is just an example. A better example might be if i wanted to create an alias for the word "register" that links back to TWikiRegistration.Due to code in that topic containing the term "register" the alias pointing to the topic breaks the topic itself, which might be rather unexpected: ( I learned this the hard way earlier today) and I would be interested to know if a parser might fix it.

Example From TWikiRegistration

<form action="%SCRIPTURL%/register%SCRIPTSUFFIX%/%MAINWEB%/%HOMETOPIC%" method="post">

also note: I have uploaded a second version of my MacroPlugin.pm to MacroPluginDev topic that allows aliases to be strings of arbitrary length (the origional version only allowed for word replacing word), (the diff will highlight one of these ... [^|]* ) so if you have not seen the latest, you might check it before you backport, and speaking of the backport, how will you do that? will you allow my changes as a user preference that can be set in AliasPlugin topic or will you use my version alone since the effect yours gives can be accomplished by it aswell

| *old way:* ||
| word    | SomeAliasLink                | 

| *new way:* ||
| word    | [[SomeAliasLink][word]] |
which of course also allows ...
| fooo   | new words here               |

Hi Travis, here's a pre-release. These are the things I changed (the alias-groups idea isn't in yet):

• aliases are configured using lists now instead of tables which is nicer I think and eases parsing in the alias definitions
• added support to define string aliases: rtfm -> read the **cking manual
• if an alias is defined
  • foo: <webName>.<topicName>
    then a nice TWiki link [[ <webName>.<topicName> ][ foo ]] is generated instead of straight text substitution
• the AliasPlugin now takes care not to substitute inside html tags (hopefully this works)
• I dropped the prefixRegExp idea, dunno if it is still needed with the new replacer

-- MichaelDaum - 21 Mar 2005

Ok, I have installed the AliasPlugin pre release and I will be testing it over the next few days at thetabase. The only change you have made that I don't think I like is how it handles TWiki Links;ie: (not requiring the [[ <webName>.<topicName> ][ foo ]] ) be explicitly stated in the list. The way you are doing it seemingly makes it easier to use internal links (which is indeed a good thing) but since it is inconsistent with the way external links must be set, I am not yet sure if the added confusion due to the inconsistency between the two is worth that added convenience. (but I will play with it and see if I might change my mind about it).

imho using the list rather than the table is a great improvement and your html solution seems to work rather well also. I will report any bugs I find over the next few days, thanks for the maintainership over this one, hats off to you for the work here.

btw, I understand the need to test and make stable the plugin for the upcoming Dakar release before we get too many features involved in the mix, but I can' help but be curious how you think we might handle the alias-groups issue in the future, I very much share your concern for context sensitivity in aliases per web and topic, and I hope we can address the issue asap. If you have (even a temporary) solution/patch in the works feel free to share

-- TravisBarker - 22 Mar 2005

Here's a second pre-release which fixes

Use of uninitialized value in string at ...AliasPlugin.pm line 99

-- MichaelDaum - 22 Mar 2005

(view this in raw or edit mode to see the example more clearly.) Im not sure if this is a bug or a feature...

try this:

AliasPlugin:

• • Slashdot: Slashdot

then in an arbitrary topic do:

"the Slashdot article is interesting"

in normal topic view you end up with...

"[[http://slashdot.org/some/story/][the Slashdot article]] is interesting." (which is broken imho) One wiki link tries to resolve inside the other because the a word was used in the URL that was aliased. I have a "working" demonstration of the problem at http://thetabase.net/twiki/bin/view/TWiki/AliasPlugin

other notes...

If the alias is HTML it breaks pattern skin. i tried to replace "a" with a .png file using a href = syntax; broke pattern skin in about 4 places (but otherwise worked fine)

you can change to a per-web context by putting a AliasPlugin topic in each web you wish to use Aliases within and changing line 62 to read as follows:

line 62:

-  my $prefText = TWiki::Func::readTopicText('TWiki', 'AliasPlugin');

+  my $prefText = TWiki::Func::readTopicText(($web), 'AliasPlugin');

i guess you could also extend this down to topic level by changing 'AliasPlugin' to ($topic) on that same line.

I've made some other minor changes that might be easier to just provide a copy of for diff comparison than to try and explain, I will attach it below

-- TravisBarker - 22 Mar 2005

Hi Travis, here's a third prerelease. I installed the current AliasPlugin on the NatsWiki with a bunch of aliases defined. The previous pre-release was seriously flawed as it didn't prevent substitutions within html tags. This one now hopefully does the trick and prevents substs inside twiki tags and twiki links also which fixes the above slashdot example.

... uh more fixes. Now using the outsidePREHandler() instead of the startRenderingHandler()

-- MichaelDaum - 22 Mar 2005

Good work, I am currently working to provide per web and global solutions as well as addressing prefix and postfixed alias issues by providing different types of aliases, my current test implementations are working fine however I need to work more on presentation and documentation so that others can easily understand and utilize the feature aswell, once I have it ready i will upload a .zip (but I suspect I should wait until you have released your final (or "stable") version before I do so.

cheers!

-- TravisBarker - 23 Mar 2005

I built a little example/test to demonstrate what will and will not resolve correctly, you might like to work it into the AliasPlugin topic.

<!--// begin test //-->

      * BROKEN: <font color="green">OK</font>

---++ Test and example of what will and will not resolve;
testing one alone:<font color="red">
BROKEN
</font>

testing two side by side:<font color="red"> 
BROKENBROKEN 

</font>
testing three side by side:<font color="red"> 
BROKENBROKENBROKEN 

</font>
testing one in a sentance: "this sentance is<font color="red"> BROKEN </font>or appears to be."

<!--// end of test //-->

-- TravisBarker - 23 Mar 2005

Here's the forth pre-release:

• added your testcases and some more to the plugin topic
• rewritten the substition algorithm again
• added extenended configurability

See the demo.

-- MichaelDaum - 23 Mar 2005

Here's the fifth pre-release. This candidate is final and will be official within another week. Changes:

• added fix to honor order of alias/unalias commands in a topic
• added alias area: only those parts of a topic are processed by the AliasPlugin that are between %STARTALIASAREA% and %STOPALIASAREA%.
• added a description on how to enable aliases site-wide (by embedding the %TEXT% in an alias area). This is different for beijing, cairo and dakar.

The effect of this is that only the topic content will ever be processed by the AliasPlugin but never the skin templates, and only during the view action.

-- MichaelDaum - 31 Mar 2005

A new version of the AliasPlugin has been released now.

-- MichaelDaum - 07 Apr 2005

This is in response to the statement "On TWiki/Cairo: either of both might work (can someone confirm?)" in the AliasPlugin install instructions. I am running the TWiki 04 Sep 2004 production release with the latest security patches. I think that is Cairo. I just installed the latest version of AliasPlugin ( v1.1, 27 Apr 2005). The Dakar notes about adding %STARTALIASAREA%/%STOPALIASAREA% to the skin did not work. I had to follow the Beijing notes and patch View.pm and Preview.pm to get things to work (I tweaked the patch notes to add line breaks between the words).

*** View.pm.dist        2005-10-03 11:09:56.000000000 -0700
--- View.pm     2005-10-03 11:09:40.000000000 -0700
***************
*** 101,106 ****
--- 101,108 ----
        $text = &TWiki::Store::readTopicRaw( $webName, $topic );
      } else {
        ( $meta, $text ) = &TWiki::Store::readTopic( $webName, $topic );
+       # Patch for AliasPlugin 1.1
+       $text = "%STARTALIASAREA%n$text\n%STOPALIASAREA%";
     }
      ( $revdate, $revuser, $maxrev ) = &TWiki::Store::getRevisionInfoFromMeta( $webName, $topic, $meta);
      $revdate = TWiki::formatTime( $revdate );

*** Preview.pm.dist     2005-10-03 11:11:06.000000000 -0700
--- Preview.pm  2005-10-03 11:10:36.000000000 -0700
***************
*** 93,98 ****
--- 93,100 ----
      #AS added hook for plugins that want to do heavy stuff
      TWiki::Plugins::afterEditHandler( $text, $topic, $webName );
      $ptext = $text;
+     # Patch for AliasPlugin 1.1
+     $ptext = "%STARTALIASAREA%\n$text\n%STOPALIASAREA%";

      if( $meta->count( "FORM" ) ) {
        $formFields = &TWiki::Form::getFieldParams( $meta );

-- GeoffreyLowney - 03 Oct 2005

Thank you all for this plugin, it is a very useful tool. I do have 1 question relating to the over aggressive replacement of strings embeded in other strings. For example an alias defined as:

• GPS: GeoLocation

Do I have something misconfigured? I have searched TWiki.org, google, the AliasPlugin and AliasPluginDev topics and found no way to only replace "whole words" instead of replacing any matched string. The above GPS alias makes ProjectGPS into ProjectGPS and GPSInfoPage into GPSInfoPage, instead of allowing the normal rendering of those WikiWords to happen.

-- BenBurnett - 08 Dec 2005

Oh, sorry, the last release was crap. Will ship a new one (see Bugs:Item1163).

Btw.: to anyone - use Bugs:AliasPlugin to file bugs. That's better.

-- MichaelDaum - 09 Dec 2005

Hi, found a typo in AliasPlugin.pm line 85:

TWiki::Func::getPreferencesFlag("ALIASPLUGIN_ALIAS_WIKIWORDS_ONYL");

should be:

TWiki::Func::getPreferencesFlag("ALIASPLUGIN_ALIAS_WIKIWORDS_ONLY");

-- EricCote - 14 Mar 2006

thanks eric. (fixed Bugs:1877 SVN:9301) and uploaded a new .zip file

-- WillNorris - 15 Mar 2006

I'm trying to find a macro facility for TWiki. E.g. I frequently find that I would like to do

   %BeginTopic{NewTopic}%
   ---+ NewTopic
   ...
   %End{NewTopic}%

and I get tired of all of the repetitive typing.

I cannot quite tell from the "documentation" if AliasPlugin is what I need. It looks like AliasPlugin is more oriented towards non-parameterized macros, whereas MacroPlugin may handle parameterized macros. But then I read above that AliasPlugin may be absorbing some of MacroPlugin's facilities... It is confusing.

No, I have installed neither yet. Unfortuanttely, my sysadmins will not give me a test wiki, and I am somewhat reluctant to install new plugins that I am so confused about on a live wiki that people depend on for real work.

Note: I am looking for both expand-once and expand-forever macros.

Expand-forever macros are what we usually all think off - you do something like Macro(param), and it gets expanded every time encountered, but remains in the original source code as Macro(param).

Whereas expand-once macros are more like editor shortcuts - the macro gets expanded the first time encountered, and the source code is modified. The example above probably needs to be an expand-once macro, because the %!BeginTopic{!NewTopic}% and the ---+ need to be in different files eventually.

-- AndyGlew - 02 May 2006

I have installed AliasPlugin in what (as I understand it) is Dakar. However, modifying the templates to enable aliases anywhere was unsuccessful so I modified AliasPlugin.pm to so that $insideAliasArea was initialised to 1 inside &initPlugin.

This seems to work with some elementary testing, but are there any known issues with this approach ?

If there are no issues, would using a Plugin Setting is used to initialise $insideAliasArea be a viable solution for inclusion ?

-- SimonMatthews - 31 Jul 2006

Well, basically you disabled the "areas" feature. There is no other way to have that using plugin settings or the like.

Which template mods did you try that have been unsuccessful?

-- MichaelDaum - 31 Jul 2006

Regarding initialising $insideAliasArea, I was thinking of something along the lines of

sub initPlugin (
   # ...
   $insideAliasArea = TWiki::Func::getPreferencesFlag("ALIASPLUGIN_GLOBAL_ALIAS_AREAS");
   # ...
}

GLOBAL_ALIAS_AREAS should be initialised to 0 by default, but would allow the flexibility to change it over the whole TWiki or just per Web.

Areas can still be used along the lines of:

Aliases here
%STOPALIASAREA%
No aliases here

I tried adding %STARTALIASAREA% / %STOPALIASAREA% around %TEXT in view.*.tmpl.

I looked at updating TWiki::UI::View and TWiki::UI::Preview to insert the tags, but since the code was significantly different to that in AliasPlugin I left it alone.

Essentially I want aliases to apply over the whole web by default - if the plugin has an option along the lines of that specified above, then the plugin installion is much simpler for all versions.

-- SimonMatthews - 31 Jul 2006

The problem with your idea is, that this plugin can really mess up the complete page given the "right" alias definitions. That's the main reason why the "area" feature was introduced. I've attached the file view.alias.tmpl, an alias template for PatternSkin. Download and save it in the directory ....../twiki/templates/view.alias.tmpl. Then set the SKIN for your site to

   * Set SKIN = alias,pattern

Here

this

Note, that this will only activate the view, not the preview. If you want to have alias substitution in preview too, then create a preview.alias.tmpl. Unfortunately, preview.pattern.tmpl is not as modular as view.pattern.tmpl so that you will have to add the alias area differently.

-- MichaelDaum - 31 Jul 2006

After some checking it turns out that I am running Cairo rather than Dakar. I tried the suggestions out but they did not work. KnownBugsOfTWiki01Sep2004 refers to several bugs related to templates and PatternSkin so I'm assuming that one of them is the issue.

I will continue run with my change in the short term but upgrading to a more recent version is probably the best solution in the long term.

Thanks for the help.

-- SimonMatthews - 03 Aug 2006

How to enable aliases within TWikiForms? Where do I have to put the START and STOPALIASAREA tags within my customized skin?

-- FranzJosefSilli - 18 Sep 2006

I posted this to HowToDebugAliasPluginNotWorking but I have not received any responses. Perhaps someone here knows something about this.

I have AliasPlugin installed, but it is only partly working. I am not sure how to debug this problem. The issue is that I can't get things setup so aliases are automatically applied to all the pages.

If I add %STARTALIASAREA% and %STOPALIASAREA% to a page then the aliases within that area are applied, and the %ALIAS{...}% tags are processed, so I know the plugin is working.

I have view.alias.tmpl installed with this default content:

%TMPL:INCLUDE{"view"}%
%TMPL:DEF{"contentheader"}%%STARTALIASAREA%<div class="twikiBeforeText"></div>%TMPL:END%
%TMPL:DEF{"contentfooter"}%%STOPALIASAREA%<div class="twikiAfterText"></div>%TMPL:END%

I have setup SKIN as alias,pattern in my preferences as described in the docs, but it doesn't seem to work. I have also tried adding ?skin=alias to a url but the aliases are still not replaced.

I tried editing view.pattern.tmpl and adding the %STARTALIASAREA%/%STOPALIASAREAD% to things like %TMPL:DEF{"contentheader"}% to no avail (I also added text which appeared on the page so I could tell the TMPL change was being applied).

So I guess I really have multiple questions.

1. Does anyone have this working on 4.2?
2. If you have it working, was anything extra done to make it work?
3. Can anyone tell me how to debug the TMPL definitions, the order they are applied, etc., so I can figure out if the problem is the %STARTALIASAREA%/%STOPALIASAREAD% not being included properly vs. their not being processed properly vs. something else?

-- GeoffreyLowney - 01 Apr 2008

This might be related to PatternSkin changes in 4.2. Not sure.

-- MichaelDaum - 01 Apr 2008

It would be great if the the original text would still be visible when pointing to an alias. So the plugin should not replace the text "a" with "b" but make it a a - WikiLink

-- Michael Werber - 2019-06-20