Category: Banner

Installing BANNER in siteheader crashes with error message about unrecognised BANNER

The same banner works prefectly with 2.0 RC2 and RC4

{syntax type="tiki" editor="plain"}
When configuring a banner, it is possible to set a to- and from-time when the banner can be displayed. Setting and saving these times work OK.
The times are stored as specified (assumed local time for server)

However, when the settings are reloaded/reviewed, the times seems to auto-adjust the times, based on an assumption that the times are stored in UTC.
I am in the GMT+2 timezone, thus both times are incremented by 2 hours when they are reloaded.

Unless this error is detected and manually corrected before re-saving, the time settings will be altered. This will occur every time.

The parameters "URIs where the banner appears only" and "URIs where the banner will not appear" are broken.
I tried in many way starting by the one from the help:
{CODE()}#/tiki-index.php?page=HomePage#{CODE}

For "URIs where the banner appears only", once something is set the banner doesn't appears at all.

For "URIs where the banner will not appear", no matter what the banner is displayed.

{syntax type="tiki" editor="plain"}
Banner show binary data as ascii when using method 'Use image generated by URL' (at tiki-edit_banner.php?bannerId=N )
Example image and url:
http://www.feedintariff.com.au/468x60.jpg

Tested on 1 site.

Banner stats are unreliable. Generally, they count 3 times each click. Needs to be verified on another site.

One one site, (needs to be checked elsewhere), the number of impressions seems to be triple the actual number.

Please comment if banners are reliable for you.

Normally, we want banners from 0h00 to 23h59 and this works well.

However, on banner edit, 3 hours are added (depends on server).

This is a new problem introduced by a fix a few months ago. Tiki 1.10 has much better handling of timezones.

Workaround: On each edit, make sure to change back to 0h00 to 23h59



{img src=show_image.php?id=31}

Banners show as just an empty box when displayed. Images don't work, text doesn't work, nothing will get it to display anything but an empty box.

{banner zone=XXXXX} doesn't work either.

It is not possible to change the image banner once one has been uploaded.
See : http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php?bannerId=1
Try to change the banner it shouldn't work.

There is an issue with the image upload.

If a banner is placed in a col (left_col) and is wider than the col it will spill over the main page data.

#left_modules {overflow: hidden} would work it out ?

Suggested on IRC:
(4:39:16 PM) mose: maybe what is missing in banners feature is a way to point to a custom tpl


This would give more flexibility. It would be easy to add Javascript, or very special banners or using variables (language, etc)

If a wiki page, we could easily delegate management and maintain edit history.

But it is shown fine when you save.

{img src=show_image.php?id=32}

See : http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php?bannerId=1

The image is big (width and height) and it overlap the interface.

__~~#F00:Update; fixed on master~~__

{syntax type="tiki" editor="plain"}
I made a banner in a Tiki master instance, but I can't edit it. To see the banner details, the URL -+tiki-view_banner.php?bannerId=2+- works, but the URL to edit the banner, -+tiki-edit_banner.php?bannerId=2+- , causes a "Banner not found" error.

It works as expected in branch 27.

After creating a zone and banner and using pluginBanner they will not display for me

{syntax type="tiki" editor="plain"}
I configured a banner a while back and set the "Use image" method. When I changed it to the "Use text" method and saved, this error message displayed:

"Fatal error: Uncaught Error: Call to a member function uploaded_file_error() on null in . . . \tiki-edit_banner.php:279 Stack trace: #0 {main} thrown in . . . \tiki-edit_banner.php on line 279"

I deleted the original banner zone and created a new one. After clicking the "Create a new Zone" button, I got the error again.

When certain high-level events occur where the internet community wants to express protest, switching a website to show it's content on black is an often used measure.

Most of the time, some message will be displayed additional to the content (or instead of the content).

Therefore I like to propose the following be added to the banner feature: Turn the Tiki black.

It involves much labour to rebuild a CSS to reflect this. This could be automated. So flicking a switch on the banner feature might compile the previous CSS to one temporal CSS in which each and every colour gets inverted.

As most Tikis will render text mainly as mostly black letters on (kind of) white, such a colour reversal would automatically yield white on black, and even let contrast unchanged, so no areas that become hard to read will spring up.

And the deactivation is even easier to implement, simply go back to the original CSS.

Caches should be cleared after CSS manipulation, of course.

This is an RSS feed:
http://sourceforge.net/export/rss2_projsummary.php?group_id=64258


It's not the traditional way of using RSS but it can be very useful :-) It permits us to get up to date info (Ex.: number of devs, number of downloads, etc.) from SourceForge, using RSS. We can then publish on http://info.tikiwiki.org/



This idea could be used for serving ads.
http://en.wikipedia.org/wiki/Ad_serving

This is also in the same idea as:
http://dev.tikiwiki.org/Connect
http://tikiwiki.org/Viral+Tiki

Two immediate uses
# Manage the footer of all *.tikiwiki.org sites from one place
# Permit to push news & calls to action (Current version of Tiki, vote for Tiki in an Award, new release, etc)


Tiki5 as of now:
http://tikiwiki.org/tiki-index_raw.php?page=rsstest

Tiki4 as of now:
http://info.tikiwiki.org/tiki-index_raw.php?page=DeployWikiPageContentAsRSS



Related
{wish id=1396}

{syntax type="tiki" editor="plain"}
Version 5.3.3

When setting up a banner, "text" works fine. When switching to use of an image for a banner,the image uploads directly to some location other than the file directory I have chosen and am using for images. I cannot tell where it is going. It is not going to the chosen file directory for images.

When putting in {banner zone='xxxx'} and the banner has an image for content, just the word "Banner" appears on the page. Apparently it cannot find the image, or load it.

Also, it is odd that it forms a link, because no linking has been given. According to the documentation, when the link field is empty, no linking will occur.

TikiWiki 6.6

When using banners, and you update the banner table manually, the changes are not visible because the banners are cached. (so far so good).

However when clicking 'Clear all tiki caches' the banner cache (which resides in the /temp dir) is not cleared.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

Many banner advertisers use a javascript for banner adverting. Currently, there is no way to add a JS-based banner.

On the banner feature there is still mention (and certainly strains of code) of Flash. (flash is dead)

See: http://bsfez-11581-7922.show2.tikiwiki.org/tiki-edit_banner.php

The parameters and the strains of code should be removed.

This is not a huge problem but is something that could be improved. On the create or edit banner page (tiki-edit_banner.php), there's a form with the four types of banner content -- Use HTML, Use Image, Use Image from URL, and Use Text. These are radio button labels, and each also has an input or selector where the data is input or selected.

If the user activates the radio button and inputs or selects in the form for that button (in the same row on a large screen), then the banner displays as it should. But it's possible to click the radio button for one content type but input or select content for another type. In this case the form is submitted without an error but the banner won't display correctly.

I know we might think "who would do that?" but the form should probably prevent this user error, if possible, like not allowing form submission unless there's a match between the content-type radio button and data being specified for that content type.

The first problem (maybe local) is that the ad checkboxes on tiki-admin.php?page=ads tend to not stay checked. Please confirm if this is true for other users.

The bigger problem (on two servers): when I switch the logo from left to right on the Look & Feel admin page, the ad checkboxes on tiki-admin.php?page=ads get emptied. Maybe any update on Look & Feel resets the ad activate and publish checkboxes to empty; I didn't check.

Also, on the ads and banners admin page, only the bottom "Apply" button works, for me.

Site header banner ad configuration worked before it was split off as a separate page, afaik. Maybe a bug was introduced by the move to its own page.