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

{syntax type="tiki" editor="plain"}
When displaying a Wiki page as slides the wrong favicon is displayed. I'm using 1.9.11 and the favicon from Xampp is displayed which is found in the root web directory ./htdocs/ rather than using the favicon found in the TikiWiki directory ./htdocs/tikiwiki/

* report about usability (& scary bug for the end user because WSoD)
** intro: you have one site with a custom theme in a tiki installation. No change of theme is allowed for users.
** problem (when): you upgrade from tiki3 to tiki5 to a new folder in your server or new server, without your new custom theme there yet.
** problem (what): after upgrade, anons. see the site in thenews.css (for instance). Good enough. But once you log in in the upgraded site, you get WSoD, until you are able to remove the .css seletions stored in tiki_preferences table.

Kind of an edge case, but if layout theme names change between versions or due to development work, so there's a mismatch between the stored layout preference and the layouts listed in the files, then a blank screen is the result. The database needs to be edited directly to correct the problem (tiki_preferences site_layout updated to match available layout names).

There should be a fallback to a default layout ("basic") if the preference name isn't found, similar to how the site will fall back to the default theme if the selected theme or stored-preference theme isn't found.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

It seems that what was achieved with profile
https://profiles.tiki.org/Hide+Fixed+Top+Nav+Bar+on+Scroll

up to Tiki18 (included) is no more working in Tiki 19.x, maybe due to changes related to the Bootstrap4 migration?

I.e.: Top module zone in dev.t.o and other *.t.o sites is no more hidable on scroll, nor topbar module zone gets sticky anymore.

I presume this is easy to fix (<30' ?) by some css & bootstrap 4 master in the tikiverse? (not me for sure)

Thanks

P.S: fyi, Work in progress to get the profile updated:
https://profiles.tiki.org/Hide+Fixed+Top+Nav+Bar+on+Scroll+19

Hello,

sorry for my bad English, but I´m from Germany and I´ve got my last lesson at school - nearly 20 years ago...

So I hope that you will understand me, here my problem :

I use Tiki 2.0 RC4 with the "andreas08"-Theme. It works quite good, but this bug (maybe ?) happens when I try to edit and save the Theme-CSS via the Admin-Menu :

Some command lines will be added with a "x" (included by tag-brackets) and the instruction given by this command will be ignored - cause it´s "rubbish" than.
( I can´t show you an example, i tried it, but here the "X" in the brackets not appears after saving this thread. )

This strange "effect" also happens by editing or formatting an text by the wysiwyg-editor, so that the text appears with some "rubbish" code-tiles instead of the formatted styles. (Text-Color, Size, Justify, etc.)

I´m not sure - is it a bug, or is this a failure caused by myself ?

Thanks for any answers or comments an greeting form Germany.

Hofnarr

Several themes are losing module text on the left margin: damian, nomia, simble, smartiki. Affects text-emitting modules such as "last changes" (last item is number 0 instead of 10), related categories, and external RSS feeds. This makes the unmodified themes unusable for some sites.

In damian.css this seems to be caused by the following near the bottom:
/* Lists in modules */
.box-data ol,
.box-data ul {margin-left: -1em;padding-right: 1em;}

Files created with the Edit CSS feature (tiki-edit_css.php) are 0 bytes.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

I get a 404 error while switching from http://dev.tiki.org/tiki-utilities-modal_alert?controller=tracker&action=update_item&fullscreen=n, into full screen mode. That is the page that one is redirected to (and populated with information, unlike if you just navigate to it) That one finds themselves on after updating a bug report.

Ive tried to re-create it by navigating directly to that url, and the 404 does not appear. Im presuming the page content plays a role in this.

Hi,

Particularly for Chibaguy, to show screenshots about the problem

The col3 ( or right-modules) are most of time send to the end of "middle".

This generally come from a "center" with two lateral column, when the calculated width of the three column is greater than the limited width of the container.

This seems to happen in several cases (mines), I commonly uses fivealive and have tested here "business". I get the same since a little more than one week.

Joined four screen shots from top to down (1920x1200 selection cropped).

You can see :
#The top and the right column not in place
#the middle : an anomaly on the width and all the display of the module action calendar (somebody has tried something while I am working on a lot of commented bugs on calendars 17 bus interacts, I have to merge or replace) . The ### comments are test to check modification at execution on my version.
#Where the col1 is ended and col3 begins
#The col3 end before the main footer

This is what I got with no SVN conflict on this.

Not sure since when but access to Google fonts (the Lato web font) fails now on all tiki.org sites. This is reported in the Chrome browser console here:
{CODE()}
Access to font at 'https://fonts.gstatic.com/s/lato/v14/S6uyw4BMUTPHjx4wXg.woff2' from origin 'https://dev.tiki.org' has been blocked by CORS policy: Request header field x-client-data is not allowed by Access-Control-Allow-Headers in preflight response.
{CODE}

__Update__: seems it is back to normal. Works for me now. {sign user="luci" datetime="2018-11-26T13:03:39+00:00"}

Syntax error in template "file:/var/www/html/templates/styleguide/sections/lists.tpl" on line 47 "" unclosed {tr} tag

In version 24.0 and 24.1 as of 18th March 2022

As pointed out by Brendan/drsassafras ([https://tiki.org/forumthread69192-CSS-Compatibility-Issues?topics_offset=14]), the CSS files in trunk are missing vendor prefixes that Bootstrap 4 bootstrap.css normally has. This is because the Autoprefixer script isn't being used in Tiki's current stylesheets workflow. For better browser compatibility (so we aren't supporting only the latest browser versions), it would be good to integrate an Autoprefixer script in our workflow.

I found this script, which could be helpful: https://github.com/vladkens/autoprefixer-php . Or maybe there's another solution that works for the devs who compile SCSS to CSS.

Update: I added Release Blocker category to put this on the front burner. The solution doesn't have to be the script I found, but some solution is needed for Tiki 19 to have maximum browser support.

Update 3/16/2020: This isn't fixed in my local installation; I'd like us to have another look at it. {sign user="chibaguy" datetime="2020-03-16T06:54:46+00:00"}

Update 9/22/2020: This seems to be less an issue as legacy Edge and IE browser usage declines. I can't test IE10 and other instances of vendor prefixes aren't critical. I'm removing the blocker category and changing the status to pending for now, and will check again when we update to Bootstrap 5. {sign user="chibaguy" datetime="2020-09-21T16:21:02+00:00"}

This tracker item could not be found

{syntax type="tiki" editor="plain"}
Currently in master ([https://gitlab.com/tikiwiki/tiki/-/commit/fa7d91ee2af2f24cc5a4c6ffecb0438dfdd138cb] - March 4) the admin option for site theme has no effect. Instead, the admin theme is used for the whole site. Because the global theme can't be set, the theme-switch module also has no effect.

I would say this is a release blocker, as it's essential to be able to set the site theme (and not just by using the admin theme option).

To allow for greater styling, it would be great to allow HTML coding and/or wiki syntax in the __Site Title__ and __Subtitle__ fields on Admin: L&F.

In the current (r22100 or so) trunk, the switch-theme module (or url tiki-switch_theme.php) only works for logged-in users. This is a regression from just a few days ago. Anonymous users need to be able to change the theme, for example at the themes demo site.

The switch-theme module appears to work without error but when the page refreshes, the theme hasn't changed.

I'm not sure of the revision when this started, but anon can change theme in my install of exported files dated Oct. 3 (approximately r21960), but by Oct. 6 in my updated trunk (approximately r22000), it's no longer possible.

When I assign a theme to a group and submit the change, when the admin-group page displays again, the theme selector shows "site default" instead of the theme name I chose, and the theme being used for the group doesn't change.

Since the use of Bootstrap in Tiki (13.x+), wide tables (like many of the ones we use in dev.t.o to display bugs and their associated variables) display a bunch of columns hidden, and the scrollbar is only shown at the bottom of the whole table.

New users might not notice that there are columns on the right hand side of the table, designed to be shown (like in our case, the column "Comments", which indicates which bugs have been commented, by whom and when, to facilitate info to the viewer about bugs that received feedback and more opinions/replies might be expected, etc).
Example (from https://dev.tiki.org/Tiki14+Blockers on a wide screen):
{img fileId="985" thumb="y" rel="box[g]"}


I was searching for something like what you can doo with doodle on wide tables, but couldn't find any jquery plugin for that.
|| ::Default view on wide table (doodle.com ):: | ::Expanded view after clicking at the shrinked columns (doodle.com)::
{img fileId="983" thumb="y" rel="box[g]"} | {img fileId="984" thumb="y" rel="box[g]"} ||

The floss solutions that we might explore to integrate might be (after 30' of searching around):
# Footable jquery plugin: (MIT licensed)
+ http://fooplugins.com/footable-demos/
# Table column toggle, from jquery mobile (compatible with using Bootstrap?)
+ http://demos.jquerymobile.com/1.3.0-beta.1/docs/tables/table-column-toggle.html

Try the demos, and see
Alternatively, some sort of custom trick could be desinged using colResizable jQuery Plugin? (MIT licensed)
http://www.bacubacu.com/colresizable/

If equally complex to implement, I would cast my vote for Footable jquery plugin, for what I've seen in their website as end user.

{syntax type="tiki" editor="plain"}
In view mode:

PluginCODE should have horizontal scroll bar when there is too much code on one line. This used to work a while ago on some browsers, but not all.


In edit mode:
CodeMirror seems to force the page to be super large

bad contrast of text vs bg in alternate row with trackerlist (or fancytable?) inside a remarksbox plugin with theme cosmo (at least)

After upgrade from tiki12 to tiki15, and selecting theme cosmo.
I had to convert calls of plugin remarksbox into plugin box.
For the record, reproduced here: https://sustainability.seeds4c.org/Shared+Forms+to+include
(with plugin remarksbox, currently replaced by plugin box, since it's a production site)

{syntax type="tiki" editor="plain"}
Dear community,

Here's a screenshot:
{img src=show_image.php?id=70}
Many blessings.

With the Journal theme, blog descriptions (at the top of tiki-view_blog.php) are displayed with a #b7b7b7 (light gray) text color on a white background. Considering that text is small, this b7b7b7 to #ffffff contrast means that the text is not only hard to read, but even easy to miss, as can be seen in the attached screenshot.

This happens because the Journal theme specifies color #b7b7b7 for class help-block, and because blog descriptions have the help-block class. I understand that help text is made discreet. But frankly, such a low contrast is a readability issue. Moreover, descriptions are not help text. They do not warrant big red text, but with such a small size, I'm not sure they even warrant gray. I would have no problem if they were pure black.

I am not clear on what change(s) are best, but I don't exclude that ideally:
# help-block color would be changed
# Blog descriptions would be changed to use a different, more prominent class