View Issue Details

IDProjectCategoryView StatusLast Update
0014146mantisbtwikipublic2012-09-28 11:56
Reporterahoros Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status confirmedResolutionopen 
PlatformlinuxOSubuntuOS Version12.04
Product Version1.2.8 
Summary0014146: integration with TWiki does not work out of the box
Description

I changed configuration settings to use TWiki
However the URL produced by Mantis were not compatible with TWiki

they were of the format:
http://127.0.0.1/twiki/bin/view/mantis/project

the latter part: "mantis/project" seems to incompatible with standard TWiki convention.

Is there any setting (either on TWiki side or mantis side) that I am not aware of?

Steps To Reproduce

1)
Use distribution packages
configure for the use with mysql
manually edit mantis configuration file
as wiki enter
twiki
also modify URL line to the following:
$g_wiki_engine_url = $t_protocol . '://' . $t_host . '/%wiki_engine%/bin/view/';

2)
simply copping over old file (to my new installation) did not have any effect:
wiki_twiki_api.php

Additional Information

I have looked at previous issues:
http://www.mantisbt.org/bugs/view.php?id=8757
also corresponding wiki entry:
http://www.mantisbt.org/wiki/doku.php/mantisbt%3Aissue:8757

and building on that I have came up with the following - temporary but working - fix:
(after light testing everything seems fine)

modify MantisCoreWikiPlugin.class.php:

============> add one new function:

Normalize & uppercasing

function wiki_twiki_normalize_name( $t_project_name ) {

$wikiword_regex = '/^[A-Z][^A-Z]+[A-Z]+.*$/';

// Normalize (remove) all whitespace
$t_project_name_normalized = preg_replace( '/\s\s*/', '', $t_project_name );
if ( preg_match( $wikiword_regex, $t_project_name_normalized, $matches ) ) {
return $t_project_name_normalized;
}

// Try uppercasing each word first
$t_project_name_uppercased = preg_replace( '/\s\s*/', '', ucwords( $t_project_name_normalized ) );
if ( preg_match( $wikiword_regex, $t_project_name_uppercased, $matches ) ) {
return $t_project_name_uppercased;
}

$t_project_name_final = preg_replace( '/\s\s*/', '', ucwords( $t_project_name_uppercased ) );
return $t_project_name_final;

}

============> modify existing base_url function in class MantisCoreTwikiPlugin to read:
function base_url( $p_project_id=null ) {
$t_base = plugin_config_get( 'engine_url' );

    $t_namespace_raw = '';
    $t_namespace = plugin_config_get( 'root_namespace' );
    if ( !is_blank( $t_namespace ) ) {
        $t_namespace_raw = wiki_twiki_normalize_name( urlencode( $t_namespace ) );
    }

    $t_projectname_raw = '';
    if ( !is_null( $p_project_id ) && $p_project_id != ALL_PROJECTS ) {
        $t_projectname_raw = wiki_twiki_normalize_name( urlencode( project_get_name( $p_project_id ) ) );
    }

    $t_base .= $t_namespace_raw . $t_projectname_raw . '/';
    return $t_base;
}
TagsNo tags attached.

Relationships

related to 0008757 closedvboctor Add wiki integration for TWiki 

Activities

dregad

dregad

2012-04-10 07:56

developer   ~0031625

Here's my 2 cents - take it for what it's worth as I have never actually tried to integrate TWiki with MantisBT but I do use them separately.

For the record, please note that the regex you propose in your function does not strictly match TWiki's WikiWord definition [1]

Also, in the uppercasing each word section, I think you should apply ucword() on $t_project_name, not $t_project_name_normalized (otherwise only the 1st letter will be capitalized)

What happens when the project name contains special characters (e.g. accents, punctuation...) ?

Finally, IIRC in Twiki acronyms (i.e. all-uppercase words) are only valid as links/WikiWords if they are >= 3 char longs so technically a project name like "A" would not work

If you can, it would be better to provide your code contributions as git patches, or at least unified diff vs a clearly identified Mantis release version. That will facilitate eventual integration of your changes by the dev team.

[1] http://twiki.org/cgi-bin/view/TWiki/WikiWord#Syntax_of_a_WikiWord

ahoros

ahoros

2012-04-11 06:02

reporter   ~0031640

Dregad,

I'll try to work on git this weekend,

But I do have quick question regarding root_namespace in mantis ($t_namespace)
Is it always defined? And always equal to 'mantis' ?

contains special characters
I was under the impression that mantis itself checks for validity of project names?

Because if such assumption can be made - than some considerations like 3 char len, or uppercasing each and every work can be less strict e.g.
MantisProject or MantisP1, etc.

dregad

dregad

2012-04-11 06:35

developer   ~0031641

Last edited: 2012-04-11 06:38

I'll try to work on git this weekend

Thanks. If you can, the best option is to fork our repository, then send a pull request via Github. Otherwise, attach your git patch here.

But I do have quick question regarding root_namespace in mantis ($t_namespace)
Is it always defined? And always equal to 'mantis' ?

You can change this in your config. See config_defaults_inc.php

$g_wiki_root_namespace = 'mantis';

I was under the impression that mantis itself checks for validity of project names?

The project name is just that - a name. It can contain any character that you can enter in your system and your DB can store, symbols, accented chars, non-latin alphabet... The following are a few example project names that are valid in Mantis, but could break integration or cause problems in Twiki

.
X
Project spécial
Try/That
Test

I think the logic of the normalize function must be improved to

  • strip out accents and special chars,
  • prefix a standard string, e.g. "ProjectName" in case what remains after normalization is a single word, and
  • ultimately fallback to "ProjectIdXXX" (where XXX is the actual project ID) if if all else including prefixing fails to generate a valid WikiWord.

I believe the correct regex for WikiWord validation should be /^[A-Z][a-z0-9][A-Za-z0-9][A-Z][A-Za-z0-9]$/ (not tested)

EDIT: I also think we should append '/bin/view' as part of the MantisCoreTwikiPlugin class instead of relying on users to add this to their config.

dregad

dregad

2012-09-28 11:08

developer   ~0032985

Unassigning - not sure how the reporter managed to assign to vboctor in the first place

atrol

atrol

2012-09-28 11:54

developer   ~0032987

Last edited: 2012-09-28 11:56

not sure how the reporter managed to assign to vboctor
I noticed this also some time ago. I am quite sure that vboctor was/is assigned to category wiki.

Edited: I tested, probably he is assigned.