Category: Theme: Look & feel, Styles, CSS, Theme Control Center

tiki-admin.php?page=wiki left column eats up the whole page with Mozilla


recently introduced in BRANCH-1-9

{syntax type="tiki" editor="plain"}
When on "tiki-admin.php?page=look" you have to enable "View Templates" and "edit Templates" to use one of the both features.
Then, if you choose to edit or view a template, tiki-edit_templates.php
is called, loads forever with high Apache load, and finally showing a blank page.

I set site theme to Business, and set Admin theme to jqui.

A registered user found the tiki-user_information.php page used jqui theme but other pages were Business. My Admin account had the same result.

I think the expected result shall be:
Admin user shall use admin theme in all pages;
Regular users shall use theme in all pages.

mdavey recently added a drop-down menu for List authors:
*as Creator & Last Editor
*Business style
*Collaborative style
*none

This needs to be propagated to all TikiMods styles

Thanks!

Hey Guys,
it would be pretty amazing if you would have time to develop tikipedia theme for tiki 12.x or 13.x in this case i really will buy you a coffee (donation) :)

sincerely

Hey Guys,
it would be pretty amazing if you would have time to develop tikipedia theme for tiki 12.x or 13.x in this case i really will buy you a coffee (donation) :)

sincerely

Title and subtitle lost css properties on upgrade from 9.x to 12.x

If no automatic conversion is possible, at least some information should be provided in the http://doc.tiki.org/Tiki12#Upgrade page.

The Problem
i.e. the structure tee ist partial accessible for anonymous -
but in the Page view /tiki-index.php?page=xyz all the substrucktures are clickable but they are not accessible (permission of the subtree gives a 302 for the visitor - so he must go back ...

a robot like google creates so much traffic becose he want follow this dead links

so i thought this is solvable by a sitemap
but Tiki has no intern tool for a sitemap like some other cms.
so i started with a online sitemapgenerator - but disasterarea 302 permission
next sitemap-gen.py from sourceforge but the same disasterarea 302 permission
but much bigger becourse it generates from the apache accesslog.

So next i thought about this mess!OK Why create a link if it is not clickable for anonym
yes thats the first solution to give the thing a straight line

looks like a big bugfamily

<lq_013> before a few day's i started with working on a sitemap for tiki
<lq_013> first Idea with using a external tool end up in a disaster
<lq_013> this courced by permission on some struktures
<lq_013> next disasterpart is the rewrite seo engine wich produces some pages 4 times
<lq_013> each accessible in an other way
<lq_013> the sitemaptool from sourcefrge which makes analyse of the access.log produces much more shit
<lq_013> some things can be restricted in a config file but thats no god Idea
<lq_013> so my suggestion to solve some of this sitemap disasters is to cancel all a href=... where annonymous can't click to
<lq_013> this is more then recommented becourse all visitors and searchengines follow this links and get a 302
<lq_013> with redirekt to login or whatever

It is very difficult to use tiki.org sites header menus and login and does not look nice on smartphones. I'm filling this bug report from iPhone 4S and just to login using the login pop up in the top bar was PITA.
See the screen captures below:
(hmm, another issue is tapping the "Choose and upload image" icon does nothing - ah, I need to tap it twice! anyway, it is also PITA using the elFinedr on smartphone to upload images - can we switch it off and use the new jQuery Upload UI instead?)

{img fileId="1024" thumb="box"} {img fileId="1025" thumb="box"} {img fileId="1026" thumb="box"} {img fileId="1027" thumb="box"} {img fileId="1028" thumb="box"} {img fileId="1029" thumb="box"} {img fileId="1030" thumb="box"}

{img fileId="920"}

Bootstrap:
{img fileId="921"}

See the capture:
{img fileId="925" thumb="y" rel="box[g]"}
Please make it nicer :)

Administration home does look really ugly with hidden disabled sections now

I don't know how to fix this one myself.

Icons are defined in the sql schema. therefore the logic to display the icon needs to be adapted to use
{CODE()}
{icon name="foo"}
{CODE}

instead of the img html tag.


See it reproduced here:
--http://xavidp-1553-5651.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=43&offset=0&sort_mode=position_asc&optionId=195&maxRecords=25#contentadmin_menu_options-2 --
u: admin
p: 12345

----
Confirmed issues still exists in Tiki18.0 {sign user="xavi" datetime="2018-02-05T19:39:10+00:00"}
---
Re-reproduced in 18.2svn {sign user="xavi" datetime="2018-04-03T16:08:42+00:00"} in a new show.t.o instance (even if the issue is more easily shown when upgrading a previous tiki site where those settings where more easily ticked):
Login as admin here:
http://xavi-9794-5783.show.tikiwiki.org/tiki-admin_menu_options.php?menuId=42
u: admin
p: 12345

You need to ensure that the menu is not using bootstrap but css, plus the setting enabled to use icons for menus (done already in the show.t.o instance)

Cheers

Update PluginVersions to Bootstrap classes (missing tabbed-like display). Tab titles show up as if they were plain text. However, if you click on them, links do work indeed. It¡s just a question of missing css classes, I guess, to restore the intuitive display.

See:
https://doc.tiki.org/PluginVersions#Basic_example

And compare it with:
https://doc.tiki.org/pluginTabs#Example

These plugin was used in doc.t.o pages. It looks like a standard Plugin Tabs, but the difference is that when you click on a tab title, all sections with plugin tabs siwtch to that version, so that you can print a long page (ideally, a whole wiki structure) with the sections related to that version of the software set to display its contents in place.

Something like these css properties might be missing at __./themes/default/css/default.css__ in trunk:
{CODE(colors="css" ln="1")}
/* Versions plugin */
.versionav {
padding: 0;
border: 1;
margin-bottom: -1px;
border-color: #eeeeee #eeeeee #dddddd;
border-bottom: 1px solid #dddddd;
}

.versionav .button {
margin-bottom: -1px;
}

.highlight {
background-color: #f5f5f5;
color: #262626;
margin-bottom: -1px;
border-top: 1px solid #e2e2e2;
border-left: 1px solid #e2e2e2;
border-right: 1px solid #e2e2e2;
}
{CODE}

Check http://branding.tiki.org/ vs http://nextbranding.tiki.org/

{img fileId="855"}

https://nextbranding.tiki.org/tiki-admin.php reports
{img fileId="856"}

This would be nice to have more control over menu look & feel

http://wiki.novemberborn.net/sifr/
"sIFR (or Scalable Inman Flash Replacement) is a technology that allows you to replace text elements on screen with Flash equivalents."


http://www.text2png.com/code_standalone.php


http://www.iconforge.co.za/

Compare these 2 pages:
http://tiki.org/Community
http://next.tiki.org/Community

Go to the section "Contributors to this page" and mouseover the names one by one: Torsten Fabricius , Marc Laporte , Rick , Oliver Hertel , ...

userlist heading link color

table background and th link are set to white in tiki-list_users.tpl
Setting a.userlistheading to another color into theme css did not overide this

When selecting a Machine Translation, the resulting page is "broken" -- the left & right columns appear after/under the center column.

Tested with 5.0SVN on http://info.tikiwiki.org with FiveAlive theme

To duplicate:

#Go to home page: http://info.tikiwiki.org/tiki-index.php?page=HomePage
#Select machine translation: __Spanish__
The left column in the Spanish translation is at the bottom of the page.

{syntax type="tiki" editor="plain"}
WYSIWYG editor is displaying theme background inside of edit box using darkshine. This results in the red and red stripe background behind your editing, but this background does not appear behind the wiki page when viewed (displayed on white, as is desired)

Please see http://themes.tiki.org/Bootstrap#&panel1-1 in Firefox for Windows:

{img fileId="927"}

There is mis-alignment of the dropdown structure navigation carets and the structure page names. See the attachment for details.

Wiki tables are really ugly now. Ex.: http://tiki.org/Domains
{img fileId="857"}

Fancy tables are better. Ex.: http://themes.tiki.org/Sample+page (notice there are no stripes)
{img fileId="858"}

And PluginWish, which is an alias of PluginTrackerList looks like this (notice the stripes):
{img fileId="859"}

PluginProposal looks like at http://dev.tiki.org/CSS+Frameworks+and+Preprocessors
{img fileId="861"}


So what is right Bootstrap way to do tables?

Here are two related commits in trunk:
https://sourceforge.net/p/tikiwiki/code/51838
https://sourceforge.net/p/tikiwiki/code/51677

Should they be changed?
Should they be backported to 13.x?

Wiki pages can have pseudo-buttons, some of which allow to perform actions. For example, a link may allow editing the page. These icons are displayed at the top of the central column, aligned right. In Tiki 12, this region has a height of 19 pixels.

Starting in Tiki 13, this region no longer contains actual images by default, but rather glyphs, which increases the basic height to 20 or 21 pixels. Most importantly, a vertical padding of 12 to 16 pixels (6 px top and 6 px down for Fivealive, 8+8 in Journal) defined for .btn is added. In the end, the region's height is now between 34 and 40 pixels, which makes it more clear than before version 13 that this region uses the full column width, pushing all Wiki content by 34 to 40 pixels down.

This is of course highly inefficient, and IMO ugly. Since multilingual wikis have a language choice widget, this region can show even for unprivileged visitors.

This persists in trunk as of r60089.