Converting of relative internal links to absolute is not good (Proposal) about ckgdoku HOT 44 CLOSED

Sorry, our DokuWiki looks like this:

• en
  • dev
    • ugd
    • gui
    • faq
  • tags
    • v2_1
      • ugd
      • gui
      • faq
    • v2_2
      • ugd
      • gui
      • faq
• ru
  • dev
    • ugd
    • gui
    • faq
  • tags
    • v2_1
      • ugd
      • gui
      • faq
    • v2_2
      • ugd
      • gui
      • faq
        ..................

from ckgdoku.

I've been looking at this. It would be nice to have, but it is not a simple fix. It requires changes to the CKEditor link tool, the ckgedit pre-processor, and the ckgedit parser, all of which have to work together without interfering with anything already in place. I'll look again but can't make any promises. Whatever is done has to be portable, not just directed at your site.

from ckgdoku.

You can try this:
https://github.com/turnermm/ckgdoku/archive/rel-links.zip
To create links using the link tool, you must be using the Dokuwiki Filebrowser. Select your file using linkwiz and when its name appears in the link tool, you can edit the link to the relative path. When reloaded into the editor these links will show in red, as though broken, but they will save correctly. If this works for you, I can always fix the red to green, this is merely cosmetic. Keep me informed of your experience.

from ckgdoku.

Just had to make a small change but want to give you a warning. As you may know, both of these refer to the same page:

..ns1:ns2:example
..:ns1:ns2:example

But ckgedit needs the first form, since there is a conflict between the dokuwiki parser and the ckgedit treatment of these links. I have made a fix for this, but a side-effect is that all of the links of this format ..:ns1:ns2:example will be permanently converted to the non-colon format: ..ns1:ns2:example. I have just done this, so if you have already downloaded, you should update.

Please test carefully.

from ckgdoku.

Thank you very much for your so quick response and fixes. Unfortunately, I was very busy today and I had not possibility to check your work. I will do it as soon as possible and report the result.

from ckgdoku.

I haven't yet finished the testing, but I found this issue:
Simple relative links (like [[page#section]] ) are converted to absolute links (like [[:en:dev:ugd:page#section]]).
Is it possible to fix?
If it is hard to fix now it's OK. We will regenerate DokuWiki pages from the source documentation (Doxygen based) where we replace these kind of links to [[.page#section]]

from ckgdoku.

This isn't feasible. It would require converting all internal link handling into relative forms.

from ckgdoku.

Is it OK to use relative links like [[.page]] to link to a page from the same namespace?
(Or [[.:page]])
It looks that I found another serious issue with such kind of links.
Serious means that a part of page is disappeared when saved.
I will try to create an example of such effect tomorow.

from ckgdoku.

I can't believe that the two are related. Once a page is loaded it has to be independent of the link which brought you to the page. Have you ever had this problem before with ckgdoku? If you duplicate this problem, it would help if you could give me a sample of the page causing the problem.

from ckgdoku.

The problem duplicated with 100% guarantee.
I attached simple test pages set which can demonstrate the problem:
pages.zip
If you will make any edition of :en:dev:ns:ns_page1 , this page is trimmed after saving.
Ckgdoku without last your fix doesn't have this problem

from ckgdoku.

I have lost track of which version of ckgdoku you are using. Is it this:
https://github.com/turnermm/ckgdoku/archive/rel-links.zip

from ckgdoku.

Try this instead: https://github.com/turnermm/ckgdoku/archive/Oct23.zip

from ckgdoku.

I found the problem, and hope to have a solution soon.

from ckgdoku.

I've used https://github.com/turnermm/ckgdoku/archive/rel-links.zip
and 'not fixed version' of 2017-09-24 for comparison.
It sounds great, that you found the problem! I will wait the solution.

from ckgdoku.

I've updated https://github.com/turnermm/ckgdoku/archive/rel-links.zip. I used your pages as a model and it seems to be OK.

from ckgdoku.

Thank you very much! It looks like OK. I will do careful testing on our whole docuwiki and I will report the result.
Sincerely,
Sergey

from ckgdoku.

Thanks. Once you are happy with it, I will merge it into the master copy of ckgdoku.

from ckgdoku.

Hi!
I'd tested your last fixes on our DokuWiki,
Unfortunately, these fixes still have issues.

1. Relative downlinks (i.e., links to pages in child namespaces) don't work.
   For example,

[[.ns:ns_page1]]
[[.:ns:ns_page1]]
[[.ns:ns1:nsns1page]]

are converted to

[[:dot-repl_ns:ns_page1]]
[[:dot-repl_ns:ns_page1]]
[[:dot-repl_ns:ns1:nsns1page]]

2. Two level relative uplinks don't work,too:
   [[..:..:testpage]]
   is converted to
   [[:dot-repl:testpage]]

3. It's my fault: I forgot to tell that we need relative references to media (images) files, too!
   Currently, all relative image links are converted to absolute form, for example:
   {{.ns:ns1:nsns1image.png}}
   is converted to
   {{:en:test:ns:ns1:nsns1image.png}}

Will it possible to fix these issues?
Here are the test pages and media:
test1.zip

from ckgdoku.

I have no plans to do the media links. I'll look at the other issues.

from ckgdoku.

I have no plans to do the media links.
Isn't it almost the same?

from ckgdoku.

Isn't it almost the same?

Not for what I would like to do, which is to automate the creation of relative links in the link dialog. As for the parsing of media links created by the user, I'll look into it.

In the meantime, you can download the updated : rel-links.zip
I believe I've finally solved the internal link issues. You can even do something like this now:

   [[en:dev...:dev_1|]] en:dev:dev_1`

Which from page_ns3, looks like this:

en:dev:ns:ns2:ns3:page_ns3

from ckgdoku.

I tweaked the processing of internal links.
I also added minimal support for images, but I'm afraid it's not very pretty and whether or how I will eventually handle images is still not certain. What may seem to be a simple parallel between the internal links and images doesn't exist. In any event the current update will preserve the relative images by embedding them in a plugin-like syntax.

You will need the latest update.

from ckgdoku.

Thank you so much!
I'm sorry for a long delay with my answer. I've had a chance to test your changes only today. It looks like that all relative links are preserved now. It's very good and we can accept this version as a base of our DokuWiki development.
I am a programmer and I completely agree with you that "Not everything is as simple as it seems at first glance", especially in a complex system, such as DokuWiki.
Yes, this support for images is not so pretty as somebody would like, but I believe you will find more elegant solution.

from ckgdoku.

What's about the following idea.
I am not familiar with Dokuwiki plugins development but it seems to me pretty simple (provided that plugin's save action knows absolute path of the page edited).
Master copy operates on absolute paths. Let it continue to do so all the time except save action.
Save action can convert absolute links to relative ones (on base of absolute path of the page).

Lets add ckgdoku configuration parameter with the name 'save_rel_links' (values Yes/No, default is 'No' to achieve backward compatibility with previous ckgdoku versions).
And lets add two metadata patterns:
{{ckgdokulinks>rel}}
{{ckgdokulinks>abs}}
which, being placed in page, will overwrite global 'save_rel_links' parameter on per page basis.

Save action will analyze 'save_rel_links' and metadata overrides. If the resulting value of this option is true, then save action converts all links (if possible) to the relative form, else links are not touched at all (i.e. coverted by ckgedit to absolute form).

What is your opinion about this proposal?
Minimum fixes, backward compatibility, no modification of dialogs, isn't it?

from ckgdoku.

You're getting ahead of me. I have already implemented a rel-links option in the config settings and am working on the sequence of events which you outline. {{ckgdokulinks>rel}} is too much like a link but the idea is a good one. And I tweaked the code which inserts the dot-repl place-holders so that dot-repl doesn't appear in the link text when in the editor. To convert absolute links to relative, we need a fool-proof algorithm. I've begun working on one but since you are a coder, perhaps you could also try your hand at it.

from ckgdoku.

I do not use PHP very often, so I'm a dummy in this language. And I'm not regexp expert.
But I think this array-based abs2rel function

abs2rel.zip

may be taken as a base for a more effective implementation.
The idea is very simple: strip left identical namespaces from the page and link paths, then go up ('..:') on stripped page path namespace count, and concat the stripped link path.

The file contains some test cases. I think, that you, as the Dokuwiki expert, may add more
refined tests to test the function more carefully.

from ckgdoku.

You abs2rel seems to be working very well. I had to tweak it to compensate for the fact that in Dokuwiki, the global which holds the current page id does not have an initial colon. Your tests look like this:

$testPage=':en:dev:ugd:page';
$testLink=':en:dev:gui:pageLink';

But DW presents $testPage without the leading colon: en:dev:ugd:pagen:dev:ugd:page.

Here is the latest update:
https://github.com/turnermm/ckgdoku/archive/rel-links_tmp.zip
The images display in the browser, and nothing special has to be done to mark up either images or links. They are automatically converted to relative. I haven't done anything yet about a per-page macro.

from ckgdoku.

The relative links checkbox in link dialog is now shown only if the relative config option in the admin panel is selected.

Another fix to abs2rel, from:

    if ($nPageDiff>1){
        $aResult=array_fill(0,$nPageDiff-1,'..');
    }

To:

    if ($nPageDiff>1){
        $aResult=array_fill(0,$nPageDiff-1,'..');
    }
     else if($nPageDiff == 1) {
        $aResult[] = '.';
    }

I became aware of it in this case:
On Page: ns1:ns2:page

[[.ns3:ns4:ns5:pageLink]]    
[[.:ns3:ns4:ns5:pageLink]] //equivalent of above

OR
[[ns3:ns4:ns5:pageLink]]

which gives
This:
http://epicurus.bz/tsort/doku.php?id=ns1:ns2:ns3:ns4:ns5:pagelink
OR
http://epicurus.bz/tsort/doku.php?id=ns3:ns4:ns5:pagelink

Again, this is:
https://github.com/turnermm/ckgdoku/archive/rel-links_tmp.zip

from ckgdoku.

Various fixes today.

Also:
Added ~~AUTO_INTERNAL_LINKS macro. When found on page, all new links will be automatically converted to relative, if the relative links config option is set to true. When that option is true, all image links are also auto-converted, and there is no other way to convert image links.

I believe that this upgrade is essentially finished and will wait for your feed-back before merging it into the master, I would like to credit you for the relative links function; you can email me in the forum

from ckgdoku.

How it works:
You can choose the create a relative intern link in the link tool dialog:

For this checkbox to appear, you must set the relative links -- rel_links -- Configuration Option to true in the Config Manager. When this is set to true, all media links will be converted to relative links. There is one macro: ~~AUTO_INTERNAL_LINKS~~. When the latter is found on a page and the rel-links option is true, all internal links on that page will automatically be converted to relative links. Relative internal links are permanent after a save, whereas media links are converted back to relative with every save. I haven't yet looked at what will happen to if a page is moved to another namespace at a different place in the hierarchy. That's another project for another time. I suppose that the move plugin should be able handle that.

from ckgdoku.

I've finished long testing of last fixes on our relatively big DW.

Mostly all works fine, except of two issues:

1. Despite of my and your efforts, the function abs2rel still had errors.
   I changed it a bit, tested it more thoroughly, and I hope that now it works correctly.
   Please replace it in Ckgdoku sources:
   abs2rel.zip

2. Ckgdoku forcibly adds a title to a link, if the link doesn't contain any title.
   I.e. the link [[linkPath]] is converted to the [[linkPath|linkTitle]].
   And the linkTitle depends on the value of rel_links option.
   If rel_links is off, linkTitle is the referenced page's heading (for example [[linkPath|User Manual]]).
   Otherwise, linkTitle is equalent to the link path, i.e. [[linkPath|linkPath]]
   Original Ckgdoku (without relative link fixes) forces the title too. It uses the referenced page heading as the title.
   This behavior is not desirable because of it adds unnecessary anoying work for editors of DokuWiki content.
   DokuWiki uses the referenced page heading to dislpay a 'no-title' link. And if heading is changed, all links will be redisplayed correctly, and we use this feature. But Ckgdoku-forced titles break it. In this case after page heading change it is necessary to find all references to this page and correct links titles. It's bad.

Probably, this second issue is for another ticket? But it related to the current work (rel_links option affects the title generated)
I think it will be very desirable have some configuration option for disabling of forcible title generation.
Isn't it?

from ckgdoku.

If rel_links is off, linkTitle is the referenced page's heading (for example [[linkPath|User Manual]]).
See: https://www.dokuwiki.org/config:useheading

from ckgdoku.

When this option is enabled, a link to a wiki page name will automatically use the first heading in the page for each of the following:

• The title of the page, as shown in the browser or in search engine results.
• The text for a link to the page, unless the link specification contains an explicit title.
• The title of RSS feed entries for the page

Bolded text in the second item is very important and we were relying on it when we converted our documentation to the DokuWiki format.
I.e. if an explicit title is absent, DokuWiki will use the page heading as the text of this link.
I.e. if we will edit heading, all referred links' texts will take into account this change automatically.
Ckgdoku fixes links text during any edit (it sets explicit title to the current page heading).
It means that when we change a page heading we have to find all links to this page and correct the explicit title which was added by ckgdoku. It is not very good.

from ckgdoku.

There seems to be some miscommunication. I had difficulty following some of your previous post and and am not sure I make full sense of the current post. Let me try to sort some things out:

1. ckgdoku is programmed to comply with the useheading setting when creating new links with the link dialog. This requires a synchronous ajax call to the php side. But synchronous calls on the main thread are now deprecated in current browsers. To pick a random illustration, see: CodeByZach/pace#364. I am currently trying to find a means to circumvent this short-coming. What this means is that when creating new links, the ckgdoku ajax rarely, if ever, manages to get back in time to insert the page heading into the link title.

2. Ckgdoku fixes links text during any edit (it sets explicit title to the current page heading). This I completely do not understand. Are you saying that when a page is re-loaded into the editor, ckgdoku replaces the current title with the page heading? And how does it know the page heading? I certainly have not programmed for it. I have never seen this happen, and something so obvious would surely have been reported before now. Unless what you mean has to do with point no. 3?

3. In your previous post you say:
Ckgdoku forcibly adds a title to a link, if the link doesn't contain any title.
I take it what you mean is that ckgdoku does not re-create links that are marked up like this: [[ns:ns:ns:id|]]. From such markup, Dokuwiki creates a url and inserts the missing display text, which depends upon the current options settings. It's one thing for Dokuwiki to create html from plain-text markup, another thing entirely for ckgedit to work back from html to text. When ckgdoku is presented with a link and its display text, how can it know the origin of the display text: user, useheading, standard dokuwiki place-holder (i.e. the page name)? I suppose it could be done, but it would involve laborious, potentially error-prone messaging between the preprocessor and the parser.

I will get back to you about the current state of the ckgdoku relative links distro. It tries to address some of these issues and is a more streamlined package.

from ckgdoku.

I think I may have solved the problem you are having by dealing with these things in the post-processing. There is an alternate link.js in ckgdoku/ckeditor/plugins/link/dialogs/jsinfo. Current name link.js.jsinfo. If you want your useheading to show up in the editor:
(1) Rename it to link.js and replace the current dialogs/link.js.
(2) Create a file named conf/userscript.js and insert into it the following javascript:
JSINFO['CKG_usyn'] = 1;
This isn't necessary and probably not guaranteed. The useheading name will be inserted during the post-processing. Depending on how the browsers parse link.js, they make eventually catch up to this little trick.

I hope this works out because it will insure greater conformance with Dokuwiki.

https://github.com/turnermm/ckgdoku/archive/current_rel.zip

from ckgdoku.

I am very sorry for my delays with answers. I was really very busy this week.
I have not yet tried your last recomendations in your last post. Sorry, I'll do it tomorrow.
But I think that you really didn't understand my last comments.
I worried about the fact that the Ckgdoku adds explicit titles to links which are didn't have explicit titles before. I.e. the link entry [[.:link]] is converted to the the link entry [[.:link|Linked page heading]] on any editing .
Moreover, the explicit title which is added depends on rel_links option value. Forced explicit title additions are very unpleasant. I explained why is it in the previous post. But the dependence of the contents of these headings on the rel_links option is not good at all.
I prepared simple test pages
testHeadings.zip

Test2 directory contains original pages.
Test2_rel_links_off contains result after the simple edition (I've added simple text after heading of the mainpage.txt) when rel_links is off.
Test2_rel_links_on contains result after the simple edition (I've added simple text after heading of the mainpage.txt) when rel_links is on.

useheading option was set to 'Always'

Please compare the links' titles in the mainpage's files.

from ckgdoku.

I had some time to update the link dialog's interface. In particular, I updated some language strings so that they would be more self-explanatory. You no longer need the ~~AUTO_INTERNAL_LINKS~~ macro. All internal links are now post-processed for Dokuwiki compliance, and all translation of relative links is done in the post-process phase. The difficulties I foresaw in my earlier comments were because I wasn't thinking backwards.

In the link dialog there are now three choices of how to handle the link's display text (title). What you want is the Page Name option. The display text will no longer have the form of relative links.

I haven't tested your new material; I'll wait for you to download the latest update and try it out first. Again: https://github.com/turnermm/ckgdoku/archive/current_rel.zip

from ckgdoku.

I'm testing your latest version.
I hasten to immediately inform you about one defect of this version: if rel-links option is off, internal links is lost when the page is saved after editing. For example, [[page]] is converted to [[|]]
This happens with both relative and absolute links

from ckgdoku.

Amusing oversight. Fixed in latest update.

from ckgdoku.

Great!
It looks like that we may close the relative links problem!
Let me however make the last tests tomorrow morning (now it's late and it's time to go to bed).
And I think that it is better to set default value of rel_links option to zero for backward compatibility. Isn't it?

from ckgdoku.

And I think that it is better to set default value of rel_links option to zero for backward compatibility. Isn't it?
I agree.

from ckgdoku.

I done with tests of latest update.
It works pretty good. I think that the 'relative links' feature may be merged in the master copy of ckgdoku.
Should I close this 'relative links' thread myself?
I found some issues with editing of links, but I think it is another work.

from ckgdoku.

Keep in touch of there is anything that needs attention and thanks for your essential contribution.

from ckgdoku.

This issue cropped up: #37
External links got mangled in the function in save.php which assigns relative links and useheadings. The current version simply excludes external links:

 $TEXT = preg_replace_callback(
      '#\[\[(.*?)\]\]#ms',
       function($matches){ 
          global $ID, $conf;                      
          if(preg_match("/\[\[http/",$matches[0])) return $matches[0];  //not an internal link

action/save.php ll. 179ff.

from ckgdoku.