Category: Search Engine Friendly URLs (SEFURLs)

Since june 2014 or so I see every now and then on a few 12.x production sites error pages indicating that no route was found.

The urls that produce this false message are valid urls (such as tiki-admin.php?page=look&cookietab=2), and the solution is just to reload the same page, and it always work at the second time.

I'm sorry I didn't understand better what is causing this issue, or how to reproduce it more consistently.
Maybe all cases are with users with admin rights? But I don't know for sure.

It is a bit worrying to be affected from this issue every now and then in production sites with our LTS version. I hope some dev can get better ideas on where to look at in order to get it solved...

Sometimes, a same site has several domain names. And they all end up with different Canonical URLs.

"Examples of non-malicious duplicate content could include:
Discussion forums that can generate both regular and stripped-down pages targeted at mobile devices
__Store items shown or linked via multiple distinct URLs__
Printer-only versions of web pages"
Source:
https://support.google.com/webmasters/answer/66359?hl=en



Also, is http or https the canonical?


Related pref: add/remove www

Verified in the latest 17.1.7 release. Could not get demo site or show instances to run so not sure there. Verified still in SVN trunk and on branch 18.x (in file tiki.sql)

The menu item "File Galleries" and its first entry "List File Galleries" does not SEF URL rewrite to "files". Using the SEF "files" does not work either.

It appears the tiki.sql file, in line 3335, has the entry for SEFURL rewrite of "files" set to 'tike-file_galleries.php' which no longer exists. The menu entry simply has 'tiki-list_file_gallery.php' without any parameter; which is what seems to work and is what the URL appears as when listing all user galleries. Just changing the table entry in the DB of an active system does get the SEF URL output rewrite to work (so the the /files appears instead of the PHP file reference). After making the change in the DB table, selecting via the menu errors back to the site HomePage (or similar) so likely something else needs to be fixed; not just the table entry (and tiki.sql entry). Checked the secDB menu tables and the template files; all seemed already changed as well (from what my naive eyes to the code can see).

Longer term, especially since image galleries are deprecated, would be nice to change the SEF URL rewrite for the general galleries page to something more recognizable than "files". Especially since hierarchical galleries are allowed. Maybe "dirs", "directories", "folders", or "galleries" (if really gone) is appropriate. But I guess I should submit a "wish" instead of cluttering up this focused bug report :)

(note: ShowTiki still not working. Get error on startup of missing third party extensions)

After changing admin pass in a brand new Tiki install the user is sent to example.com/Homepage even if the preference was not enabled by default, and the server didn't support it, like in the case of show.t.o.

This can produce the awful impression that Tiki is broken just in your first trial/test in a server.

I can't change the language in the homepage using the switch language module when on a homepage when sefurl is active.

This is incomplete: I mainly wish to try if the wsho keys were moved when amette moved the dev.tiki.org server

I tried to edit http://dev.tiki.org/tiki-editpage.php?page=Search%20engine%20optimization and got "Can't duplicate alias link, SEFURL link already present in SEF page"

The page did save though:
http://dev.tiki.org/tiki-pagehistory.php?page=Search%20engine%20optimization&oldver=88

How can the user know what is the duplicate? Perhaps a link to that page so the user can cleanup the duplicate?

Using the following code in a Wiki Parsed module

{CODE(caption=>example module code)}
{if isset($objectCategoryIds) and in_array(42, $objectCategoryIds)}
In category
{/if}
{CODE}

should show the text "In Category" when the wiki page currently shown in the center column is in the category with id 42.
--This works only on pages without spaces in their names.-- Things seem to have changed. This works with pages that have spaces in their name, but not if the spaces are being replaced by dashes.

The above code should also work when on a wiki page with spaces in it's name.

Using the latest Tiki 14.x zip file, creating pages using the Norwegian characters æøå fails, when typing in the name and using the double parenthesis syntax.
The page saves ok and displays the ? - mark.
Click to create the page. All seems well.
Save the page.. leads to page not found.

Will set up a show instance

...later ... show problem
The show instance does not work properly.
After I activated SEFURL, the homepage fails to load.

In Tiki we have an _htaccess file that contain directives that can be used in an .htaccess file.

Before Tiki26 at the end of it, the installation process was choosing an option to end with most of the case (where no .htaccess existed) by creating a symlink .htaccess => _htaccess allowing Tiki to redirect you to the "HomePage". (and not tiki-index.php?page=HomePage)

Eventually it was possible to use a script after the installation to do this manually using:
{CODE()}sh _htaccess.sh{CODE}

It is mandatory to use this to enable SefURL as state on the SefURL control panel and the documentation https://doc.tiki.org/Search-Engine-Friendly-URL

But now, as this script is now gone from Tiki26 the server admin need to create manually the symlink.

Some power users reported that there Tiki installation went through and the symlink was set automatically.
I have installed half a dozen of Tiki26 on different system (Debian, OSX, FreeBDS, etc) and I had to create the symlink manually each time.

If you try to name a page starting with "tiki wiki" (dash for space) tiki will see this as an action and refuse to comply.

IE: I tried "tiki wiki help" (spaces are replaced by dashes) and got the following error"
~pp~Action not found (help in wiki) (404)~/pp~

That’s a bit... ?

Steps to reproduce:
# go to ((Make a Wish)) on this site
# click the print icon
# scroll down and try to return to this page by clicking on the link: The original document is available at http://dev.tiki.org//Make+a+wish

On a Tiki22 I have multilingual, restricted language, page and site synchronised.

From Google I land on the English page.
I switch to Hebrew and then paste the french url on the browser bar.

The page language is French
The Tiki language is French
The keyword and description tags are Hebrew
{img fileId="1476" thumb="box"}
This will stay even after a refresh. Only if I click on the French language (language selector) even if it is already displayed as selected the tags will synchronise (all in French).

Now if from an external tools to check what my meta tags are I select the French version of the page (french name) It show me the right page in french, the right text in french but the meta tags, Keywords and Description are still in English.
{img fileId="1475" thumb="box"}

Somethings is not synchronised...
---
~~#F00:UPDATE~~: And this is messing with search engine and social network.
---
~~#F00:UPDATE~~: This happen when using SEFurl.
If you use domain.com/tiki-index.php?page=nameofyourpagenotinenglish it will work (site language will switch)
If you use domain.com/nameofyourpagenotinenglish the page will display but the site language won’t change. I can’t use SEFurl on show2 to demonstrate.

Hello,

installed Tiki20-RC1 on my localhost and noticed that after I enabled SEF and then logged out, Tiki reported "Page not found Homepage". After re-login and disabling SEF everything was fine and then another admin-login, re-enabling SEF and then it worked out.

IIRC, the same behaviour I was also noticing when playing with Tiki20-beta, but then I was too busy testing/evaluating Markdown plugin. (:biggrin:)

Sincerely,
Gour

relative links with url like "show:MySlideshow" are not prepended the domain in the url. when tiki installed in a subfolder (http://example.com/tiki/). I.e., this code:

{CODE()}
{button href="show:MySlideshow#s1" _text="Slideshow"} {button href="dl543" _text="Slides in PDF"}
{CODE}

would keep the link in the first button as just "show:MySlideshow#s1", while the second one will be converted into the full url (prepended with the domain): http://dev.tiki.org/dl543

Example:
{button href="show:MySlideshow#s1" _text="Slideshow"} {button href="dl543" _text="Slides in PDF"}

This code seems to behave well in dev.t.o, but it does reproduce the error in demo.t.o/12.x/:
http://demo.tiki.org/12x/HomePage

The search engine friendly links do not appear for forum threads. You can use the SEF link to get there, and somewhere on the website the SEF form us used (based on a crawled index of links) but it is not present under the form thread list page, which is arguably the highest traffic page to access the threads from.

I have also looked at the RSS and the SEF links are not used for the forum in there as well. They use the standard tiki-view_forum_thread.php page with a URL passed argument.

Hoping someone can track down what went wrong. I have already searched through my .htaccess file to make sure I did not break it myself, but don't think the issue is there.

SEF links for the forums themselves appear to be functionally normally.

{syntax type="tiki" editor="plain"}
The link to the RtM calendar event on tiki.org currently should be the SEFURL version, e.g. https://tiki.org/tiki-calendar-view_item?calitemId=337 (or maybe something even shorter?) and not https://tiki.org/tiki-ajax_services.php?controller=calendar&action=view_item&calitemId=337

Also, it should be easier to share it, imho.

Links to -+tiki-admin.php+- pages should have a sefurl version - probably -+admin+- so Look & Feel would be [admin-look] etc (maybe this needs discussion)

The links on menu #42 to blogs and forums do not observe the -+sefurl+- setting (always "unfriendly"), however ''trackers'' works as expected.

There are probably others missing...

I recall this working in 6.x or so, so "tagged as regression".

Using (12.1svn): Abril 4, 2014. r50665

Sharing acccess rights, with token access, seems to be failing.
When using "Tell a firend" for a wiki page, as user with tiki_p_admin, there is a checkboxa message sending time, and the link in the email received by the destination emial contains a TOKEN hash inside. However, once clicked in that link in a browser as anonymous, the user see the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

When using Share, as user with tiki_p_admin to share a wiki page, I see the dropdown to indicate how many times to share access rights with that email. I shared for 3 accesses (the mas allowed in the admin panel, and thus, in the dropdown, also). The eamil that receives a message comes with a token hash inside, but still gets the message "L'accés a aquesta pàgina està acabat" (the access to this page is over).

---
u: admin
p: 12345
Homepage restricted to registered users. When SEFURL is off, sharing access rights with friends seemed to work as expected.
http://xavi-9794-5225.show.tikiwiki.org/tiki-index.php?page=Community+Members+HomePage
---
IT seems the bug was not solved in trunk by then (15.x currently), and a new fix was added by jonnyb in r58322. {sign user="xavidp" datetime="2016-04-14T12:54:16+00:00"}
---
Fix unconfirmed for me {sign user="xavi" datetime="2016-04-18T11:41:19+00:00"} in localhost with a snapshot of this site upgradeed to 15.x (rewrite rules do not work in show.t.o so SEF cannot be tested there). When attempting to view the site as anon. with the url (which includes the token param name and value), I get:
{QUOTE()}
Your access to this page has expired
{QUOTE}

Update June 22, 2016: This issue seems to happen still when any param is added to the url (page_ref_id=nnn - from structures, or fullscreen=y to prevent disclosing information from the side modules that the user has access to, besides the content that would like to be shown frmo the central column). {sign user="xavi" datetime="2016-06-23T07:32:05+00:00"}

short links indicating tab number do not work anymore after upgrade from 9.x to 12.x.

Example:

Links like:
# http://ueb.vhir.org/12.x/tracker5&show=mod
# http://ueb.vhir.org/12.x/tracker5&cookietab=2

do not work any more

but their equivalent full links do work normally:
# http://ueb.vhir.org/12.x/tiki-view_tracker.php?trackerId=5&show=mod
# http://ueb.vhir.org/12.x/tiki-view_tracker.php?trackerId=5&cookietab=2

Something to do with the change in route.php?

Something about namespaces seems to conflict with url sending user after updating tracker item with SEFURL

Url where I update an item is:
{CODE()}
http://example.com/item608?from=SERGEN-Xavier%3A_%3AMagatzem-LH-AraVinc
{CODE}

Editing the tracker item is done in a modal window. I update a datepicker field in the tracker, save, and I'm re-sent to this full url in the browser:
{CODE()}
sergen-xavier:_:Magatzem-LH-AraVinc
{CODE}

i.e., with no http, nor domain, etc.

The tracker item edit was saved properly, it's just disorienting for the user to be sent to that defective url.

For invalid Tiki URLs ending in .php (or .html, etc.), instead of a nice 404-type message, there is this: ~np~"No route found. Please see http://dev.tiki.org/url+Rewriting+Revamp"~/np~. This is ok for a dev site (looks like a message to a developer), but isn't appropriate for a production site. In Tiki 13, there is something a little familiar, though not very nice: "404 Not Found - nginx". Is there some way to have a nice, styled page, that looks like part of the site and not a server message?

{img type="src" src="tiki-download_item_attachment.php?attId=756"}

Here is a URL:
http://suite.tiki.org/tiki-pagehistory.php?page=Tiki+Suite+Slideshow

Say I want to check the history and share a URL, I click "history" and then "compare", I get:
http://suite.tiki.org/tiki-pagehistory.php?page=Tiki+Suite+Slideshow&history_offset=1&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=125&tra_lang=sq&paginate=on&history_pagesize=200

This is long and has things which are not useful to share the link.

So let's look at the params:

|| page=Tiki+Suite+Slideshow | Needed
history_offset=1 | Not needed
diff_style=sidediff | Needed only if different than the default diff
diff_style=sidediff | this is there twice
show_all_versions=y | Not needed
compare=Compare | Why do we need this?
newver=0 | Needed. 0 seems to be for latest. So if ommitted, it should
oldver=125 | Needed
tra_lang=sq | Not needed
paginate=on | Not needed
history_pagesize=200 | Not needed
||

So diff_style=sidediff is there twice

I would want the simple one to be like this:
Compare version 120 to current:
http://suite.tiki.org/tiki-pagehistory.php?page=Tiki+Suite+Slideshow&oldver=120

Compare any two versions:
http://suite.tiki.org/tiki-pagehistory.php?page=Tiki+Suite+Slideshow&newver=124&oldver=120

And if diff style is different from site default:
http://suite.tiki.org/tiki-pagehistory.php?page=Tiki+Suite+Slideshow&newver=124&oldver=120&diff_style=unidiff

Thanks!

{syntax type="tiki" editor="plain"}
On a Tiki29 I use multilingual and it displays a manage translations dropdown in the top wiki page actions bar.

The links there to go to one translation to another are using the legacy form for the URL instead of the SEFurl.

IE:
https://opensourcesolutions.pro/tiki-read_article.php?articleId=24#%20Admin%20Tips%20That%20Actually%20Help%20on%20Tiki%20Wiki

Instead of:
https://opensourcesolutions.pro/article24-Admin-Tips-That-Actually-Help-on-Tiki-Wiki

For consistency and to avoid possible problems in the future, if SEFurl is enable, all links should use it.