Easier page linking method perhaps?

[BFD Calendar]

I'm using a lot of internal page links on my website. When they are in fields they are easy to fetch with asmSelect fields. But I also use them in textarea fields. Adding a link brings the pages menu, but then the hassle starts.... I have a few hundred names and I want to link to one of them, it means guessing where the letter H or S will be in the list of pages. For H start at page 12 or something and then click next, next.... For S definitely go to the last page and click previous, previous....

Is there an easier way that I haven't found out about perhaps?

[Martijn Geerts]

I'm on a project which can grow quickly. I used ProcessDateArchiver (wonderful module) to automagiclly put pages a folder, (year/month/day/)

This way the lists are never to big to browse.

If that is not an option, maybe you can make a some kind of text formatter that most of the linking does for you.

I know, those 2 are not easy options, 

[Soma]

Another option would be to browse this the page and copy the link, Or use the admin search and copy the link from the results.

[BFD Calendar]

Browse and copy the link would be a good option. Is it really the link (as text) that is used or is it the page id? If it's the link as text then I could be in trouble if a name turns out to be written differently and is changed later on, after the link is made. I assumed ProcessWire would use the page id which is shown as a link.

[Martijn Geerts]

BFD Calendar, nothing is save. If a page is deleted your ID will be gone to.

Eventually it's better to stick with name, cause that can be re - created easily, not that id.

WYSIWYG is a dirty thing. When programming, you can link pages with relationship with WYSIWYG you can't.

( without loads of overhead )

[BFD Calendar]

Second thought: if the link is kept as text instead of page id I have a bit of a problem.... I'm working on my site in a separate subfolder until I decide to put it online. So it's in something like www.mysite.com/temporary now. Hopefully in a week or so it will go to www.mysite.com - which means all the links in textarea fields are worthless or what?

[diogo]

you can combine Hanna code and a multiple page field. this is just a hint and I'm on mobile on a bus, so I can't test or explain much better.

[BFD Calendar]

Ok, thanks. I'll first put my site where it will be and then work out what's the best way to get this working smoothly.

I'm not in such a hurry to have all the content in place, having the framework right and working is more of a concern. There are still about 5000 names to add so I have plenty of time to test and find the best solution.

[Macrura]

@bfd - the page path history was developed to solve that problem, and you should enable it on your site once you go live;

http://modules.processwire.com/modules/page-path-history/

prior to going live, when you migrate to the new location you can do a search/replace in the SQL file to fix the paths.

you might also look at this:

http://modules.processwire.com/modules/page-link-abstractor/

[Pete]

I use those two modules a lot nowadays - they keep me sane

[kongondo]

Hmm, should Page Path History (core) still be listed as in Alpha?

[dragan]

I guess using Hanna Code and page ids would be the easiest.

Using the search or looking up the content tree in one browser tab (get the id on hover), and the edit screen in a second one. 

MODX uses something similar: <a href="[~7~]">click here to go to document id 7</a>.

It takes then just 1-2 lines of API code to convert it to a regular link.

This approach would probably also be hassle-free when building a multilang PW site. Because when adding a link via WYSIWYG, you have to manually replace de/ueber-uns/ -> en/about-us. (unless I missed a workaround or new module / hook).

[Soma]

I guess using Hanna Code and page ids would be the easiest.

Using the search or looking up the content tree in one browser tab (get the id on hover), and the edit screen in a second one. 

MODX uses something similar: <a href="[~7~]">click here to go to document id 7</a>.

It takes then just 1-2 lines of API code to convert it to a regular link.

Hanna code just for internal links may a bit cumbersome, but one way to do it. PageLinkAbstractor is an attempt to abstract links to id's, but I'm not sure anymore what it does. I have my own LinkAbstractor for my sites that are mostly multilanguage, and I convert internal links to "pageid:1233" on save and convert them back to a url. 

This approach would probably also be hassle-free when building a multilang PW site. Because when adding a link via WYSIWYG, you have to manually replace de/ueber-uns/ -> en/about-us. (unless I missed a workaround or new module / hook).

Current version of PW and TinyMCE, CKeditor have this feature in now and use language aware links. Thanks to Pete, Ryan and me.

----

Drawback of all this methods is that you can't link from one language to another easily. I guess this is the price to pay when using one page for multiple languages, and this not being the only one. Many features that usually are easy and straight forward become a permanent hassle, cause every feature will need to be considered working for multilanguage too.

[BFD Calendar]

I still wonder why internal page links are not referring to page ids instead of urls. As soon as something in the url changes the whole site can turn into a mess.

I have a list with lots of names that I refer to, mostly by page relations, but once in a while also as link in a text area. Sometimes you find out after a while that a person is called Johnsson and not Johnson. Since the title field and url are based on 'Name, Surname' url 'name-surname' everything is fine when it comes to page relations, but not when it comes to url, it means searching the whole site - or my physical memory - to find out where the misspelled name was used.

Or maybe one day I might decide it's better to put the names under parents A, B, C, etc instead of just all under parent 'people'. Then every text link to a name would need to change.

The above mentioned modules are a workaround in some cases but not a solid solution.

And apart from that, a PageAutoComplete field would be so much easier to search through 500 people, 900 places and 1000 dates for now....

[adrian]

BFD Calendar - I usually just make use of the page path history and the page link abstractor modules, but if you want ID based page links, you might find this module useful: http://modules.processwire.com/modules/process-redirect-ids/

Ryan has also mentioned that he was working on something called Link Monitor - although he may not be persuing anymore. Something to read anyway if you haven't seen it: http://processwire.com/talk/topic/236-module-page-link-abstractor/?p=34398

[BFD Calendar]

Adian, I installed ProcessRedirectIds. It looks like a definite improvement for what I want. I'll keep you posted if anything comes up. Thanks,

DDV