Category: 14.x

https://developers.google.com/search-appliance/documentation/68/admin_crawl/Preparing#pagepart

class=”robots-nocontent”

http://antezeta.com/news/avoid-search-engine-indexing

See screencast

I just came along a problem.

We use the tiki structures, combined with the menu module to display our navigations.
The structure-menu-combinations doesn't link to tiki-index.html?page=page_slug, but to the page slug itself.

That may be because of the sefurls. It's what we want, but it can lead to problems.
If you rename a page to, for example, test.html (or something else with a dot), the page is not available through the menu any more.

If you press the menu entry, you will just come to the page, where:

__No route found. Please see http://dev.tiki.org/url+Rewriting+Revamp__

is written.
So my question is, should dots be allowed in the pageSlug?

If I use CODE plugin look like as attached images, the right side horizontal scroll should be disappeared, I think. Because of it does not have any hotizontal scroll until Tiki 12.0.

This horizontal scroll appears in Tiki 12.1 alpha and beta even if the page content is too short.

{img fileId="751" thumb="y" rel="box[g]"}

Thanks,
Joon.

In the shoutbox module, each post is followed by "x" and "e" links for delete and edit. Edit works ok, but the delete link doesn't. The edit link is a standard URL, but the delete link is a short URL. Clicking it produces a Tiki 404:

Error

Page not found
shout_remove=17

I guess the URL rewrite is wrong or something.

I am just creating a show instance for a community project related with the release of Tiki 14.0 beta

ref1: http://torsten-11143-5621.show.tikiwiki.org/tiki-list_trackers.php
ref2: Release Team
ref3: Jonny, Bernard, Wolfgang, Torsten, et al

T.

Hi Devs, I need one show.t.o instance to show all (or most) of the bugs, which I find for Tiki pre-13.

I have a few smaller websites in production with pre-13 trunk to have a productive testing environment.

The bugs will be reported individually and refer mainly to this show instance instead of individual instances, where it makes sense (at least in my mind).

In case of questions or comments to this tracker item / show instances / bugs, you may write to torsten@tiki.org

Maybe a toggle like "Reset password to admin/12345"?

Instead of renaming _htaccess to .htaccess, it's better to make an alias. (more future-proof on svn up)

Nelson: IMO it should probably be on by default for now, and then toggle is another feature request. reassigning to amette.

I am routinely setting up show instances.

Going through 1st login password change / set is a pain.

{flash type="url" movie="display518" width="716" height="229"}

On a trunk version installed by show.tiki.org

"Your database requires an update to match the the Tiki version; use the installer. Using Tiki with an incorrect database version will cause errors. If you have shell (SSH) access, you can also use the following, on the command line, from the root of your Tiki installation: php installer/shell.php"

This seems to be a regression since Tiki12 LTS at least. (non-bootstrap, I mean)

since last visit module using bootstrap tabs: add different bg color to active vs non active tabs
You can see it reproduced here in dev.t.o in 14.x also, in the corresponding "Since your last visit..." module. All tabs have same whote background, and this makes it less usable to easily distinguish where tab you are at.

since last visit module using bootstrap tabs: make icons bigger (for human fingers in smartphones)

Have tried using it on a smartphone? It's way difficult to tap on them.

You can try in 14.x in dev.t.o.

Site timezone is not respected when using Plugin Convene

E.g.: site default is UTC-2. You choose your time in the convene plugin, as UTC (even if you have no indication of the timezone, it seems), for instance, and the stored time is shown 2 hours before the time you selected in your choice.

Reproduced using Tiki 13.x here:
https://tiki.org/Admins+Team+Meetings

However, I can't reproduce it in an associated show instance in trunk. Maybe it has something to do with the timezone set in php settings, and not just the setting in Tiki?
I kept the tiki set as "Admin home > General > Date and time > Displayed Time zone: Use site default".

{CODE()}"An {include} with a cache_lifetime within {block} tags could create wrong results in certain situations.
For that reason 3.1.15 is more restrictive and created an error."{CODE}

source:
http://www.smarty.net/forums/viewtopic.php?t=24599

Should be fixed in 3.16:
http://code.google.com/p/smarty-php/source/detail?r=4797

I discovered an issue with my calendars a couple of weeks ago. It turns out that it was caused by one of our users giving a certain input to a new calendar item. Essentially, they were attempting to add an image to a calendar event and submitted an improperly formatted string in the description field. Instead of using the the 'Image' button on the new calendar item page (tiki-calendar_edit_item.php) to load their image, they did some sort of copy/paste of the image or its syntax from a page using the ''wiki'' syntax.

Their input in the database looked like:
<p>~np~{img fileId="791"}~/np~</p>
But the correct syntax looks like:
<p><img alt="" src="display791" /></p>

After hunting this bug down, it was determined that it was in fact the cause of our calendars getting hung during the loading screen, and this resulted in the WSOD. After simply deleting the two entries from our database that had the incorrect syntax, the entire issue was resolved, and the calendars began loading correctly again.

In pursuit of a fix for this kind of bug happening again, maybe there is some way to prevent a write to the database when the title or description field (in tiki-calendar_edit_item.php) contains this form of syntax?

Hopefully, there will be a way to restrict this from happening, as it took a couple of weeks to hunt this bug down, since we had no idea when or where it originated from.

I'm submitting this bug report in case future users experience this same type of issue.

See 9.x:
https://profiles.tiki.org/Admin

Still a problem in trunk:
http://nextprofiles.tiki.org/Admin

This is the commit that caused it:
https://profiles.tiki.org/tiki-pagehistory.php?page=Admin&compare=Compare&newver=14&oldver=13

Sort on rating at this tracker is broken.
To reproduce:
* Login here: http://dev.tiki.org/tracker5 (as user xavi, plain registered user)
* click on rating column (to sort items on their rating): it apparently works, even if it shows first the ones with the lowest rating.
* click again on rating column (attemping to sort the items with highest rating first), and still items with 0 in the rating are showed first.

url (only with open items, to reduce potential factors interfering): http://dev.tiki.org/tiki-view_tracker.php?trackerId=5&sort_mode=f_152_desc&status=o

^ __Note__:
Please note that this is using the maintained (non deprecated) rating tracker field (field 152, type "Rating"). If you are an admin, you will see still 2 fields as rating, but one, the former and unmantained (field 62, "Old Rating - Stars (system) visible by Admins only"), is hidden from registered users (it's kept there in dev.t.o in case some devs makes an script to convert the data from the old tracker field into the values for the new tracker field in all tracker items of the same tracker).

I tag this wish a regression since I remember that this worked in past, years ago, but unfortuntely I can't say in which specific version.

I consider this isse to be somewhat important since tiki are being used more and more to allow communities to gather user feedback to prioritize issues, actions, strategies, proposals, etc., in a genuine "wisdowm of crowds" way, and this issue prevents using tiki for this goal, which is a pity when you are using Tiki in the same community for many other community needs... See http://doc.tiki.org/E-democracy
^

---
Maybe related to [item1446|item 1146: Trackers: Need to be able sort as numerical instead of text]?

As seen here: http://themes.tiki.org/tiki-pagehistory.php?page=Sample+page&source=0
This happens only when jQuery UI is set to "None".

while using the paper template, spreadsheet UI style is broken, as it "moves" around when you try to click a button.


After hours of trying to debug this, I found that it was not specifically related to paper. The UI buttons jump around on many themes.

In the end I narrowed the issue down to a style in tiki_base.css

by removing the padding rule under a.toolbar:hover, the UI no longer jumps around.

a.toolbar,
a.toolbar:hover {
--padding: 4px 2px;--
display: inline-block;
border: none;
background: transparent;
}

Spreadsheets (jquery --s5-- sheets) do not work as expected in a productive environment, even not for use in an internal team.
This is a regression, as they have been working before.

Issue: __The edit menu and it's subitems had no effect (Edit | View | Style).__

--Before considering it a bug I want to test here with a show instance.--
__Tested. Fix needed.__

[http://torsten-11143-6133.show.tikiwiki.org/tiki-view_sheets.php?sheetId=1&parse=edit|try here (show/show => admin/12345)]

Regards,
Torsten

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?

The TOC gets populated with some headings from plugins like trackerlist (probably should not as it seems to appear on wrong position at the top of the TOC).
---
affecting autotoc and standard maketoc, also in Tiki15. {sign user="xavi" datetime="2016-05-20T09:48:34+00:00"}

this is just a test

test pls ignore

The canonical is:
<link rel="canonical" href="https://nextthemes.tiki.org/tiki-all_languages.php?page=CSS">

But should be
<link rel="canonical" href="https://nextthemes.tiki.org/CSS">