Jockel666

Super, danke!

Viele Grü?e, J?rg

Hi,

this happens even with the build-in calendar app from Google.

Further investigation hints that it is a misunderstanding between Zimbra and Android: When I choose another Timezone far away from Berlin on Android, Zimbra shows it correctly. When I choose one of the +1/+2 zones like Berlin, Bruxelles, Windhoek, even Zimbra itself shows the strange GMT+1/+2 string. Strange too that Android seems to be the only system making these strange events, and all other (tested) clients are doing better.

So I’ll contact our server admins, maybe its a configuration thing in Zimbra or the underlying system.

(My guess is: Android is sending the correct “Berlin” string. Zimbra (other than e.g. the Google Server) is checking the definition of the TZ-definitions, is seeing the difference in BYDAY and then is thinking that “Berlin” is wrong and then is giving these events a self-created “special” time zone. But I have no idea, why only the +1/+2 timezones are affected, and why only android-events…)

Thanx again, greetings, Joerg

Hi,

btw: It seems only Zimbra does not realise these strange TZID strings. Google Calendar changes them to standard IDs so the problem does not occur.

But thanx to your hint, now it works, even with the cheap solution as all our TZIDs are local ??

function repair_timezoneid( $tzid ) {
return “Europe/Berlin”;
}
add_filter( ‘amr-timezoneid-filter’, ‘repair_timezoneid’ );

Bye, Joerg

Hi,

the application which is creating these timezones is… Android… we have several entries made by several android devices and no common details (different apps used, different models and versions). All sync to a Zimbra server, some by Activesync, some by CalDAV.

Ah, yes, there is information in the header, and it looks the same than the following Europe/Berlin, only one detail at the DST start is different, the BYDAY is -1SU vs. 4SU which is the same in most marchs I hope ??

As we can’t change Android being used, I try your other solutions, thanx!

BEGIN:VTIMEZONE
TZID:GMT+01.00/+02.00
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETTO:+0100
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=10;BYDAY=-1SU;WKST=MO
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=3;BYDAY=4SU;WKST=MO
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETTO:+0100
TZOFFSETFROM:+0200
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETTO:+0200
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE

Greetings, Joerg

Hi JP,

Das Problem grob: Ich habe ein Plugin, das nicht ein DIV um alles packt, in dem die R?nder/Breiten definiert sind. Stattdessen legt es einzelne “Elementzeilen” an mit den Randdefinitionen. Und Shariff packt sich hinter diese Zeilen, steckt also gar nicht mehr in dem DIV mit den R?ndern/widths.?

Im Detail: Das Theme nutzt das Plugin Visual Composer. Solange ich keines dessen Elemente nutze, ist alles in Ordnung. Doch sobald ich ein Element hinzufüge, passiert folgendes: Der bisherige Text eines Beitrags wird automatisch in ein Visual-Composer-Text-Element geschmissen, das kommt in eine Visual-Composer-Zeile. Und folgende neue Elemente kommen alle in solche Zeilen-DIVs. Genau in den Zeilen-DIVs findet aber die Breiten- und Randdefinition statt.

Shariff fummelt sich aber an eine Stelle in den HTML, die *hinter* den Visual-Composer-Zeilen liegen. Und damit fehlen die ganzen Definitionen der R?nder usw., die ja auch wg. responsive sich über einige @media-Dinger verteilen, die ich erstmal alle finden müsste.?

Hier ein Beispiel:
https://schoenergesehen.de/technik/farbprofile/telekom-vodafone-verfaelschen-farbprofil-mobilfunk-komprimierung-1113

(Das ist der erste Artikel auf meiner Seite, wo ich mit den neuen Visual-Composer-Elementen herumspiele, und auch bisher nur der grüne Kasten unten. Daher tritt das bisher nur hier auf.)

Wenn Du in den Source schaust:?
– die beiden <div class=”eut-section… sind diese Element-Zeilen
– dadrin erst der eut-container ist der div mit der fraglichen Rand/Breite-Definition
– das shariff-div landet auf der gleichen Ebene wie die eut-sections, und so fehlen Rand/Breite

Die machen das halt, weil Visual Composer die M?glichkeit hat, dass diese Zeilen auch über 100% Breite ohne Rand gehen. Daher ist nicht die Ebene über section und shariff schon “berandet”. Im Unterschied n?mlich zu allen anderen Eintr?gen ohne den Visual Composer: Da ist der eut-container um den kompletten Beitrag inklusive Sharrif drumherum. Und somit stimmen alle R?nder. (Aber wenn ich Elemente haben will, die 100% sind, muss ich wiederum mit negativen Margins arbeiten, auch l?stig…)

Ich br?uchte also eine M?glichkeit, dem Shariff-DIV die Eigenschaften von .eut-container zu geben. Entweder über class=”shariff eut-container”, oder sowas wie <div class=”eut-container”>[shariff]</div>. Ein weiterer Workaround w?re natürlich, dass ich manuell jedem Beitrag eine Visual-Composer-Zeile hinzufüge mit einem Textelement, das nur [shariff] enth?lt. Was auch etwas l?stig ist ?? Aber immerhin k?nnte ich die Position dann auch frei w?hlen.

Ich hoffe, ich habe das Problem halbwegs verst?ndlich beschrieben? Sonst frag nochmal.

Viele Grü?e, J?rg

Hi JP,

danke für die schnelle Antwort! Hmm, die Definitionen der CSS-Klassen finden im Theme statt. Ich müsste dann IMHO entweder in dessen CSS-Dateien rumfummeln und das bei jedem Theme-Update wiederholen. Oder ich müsste in einem Child-CSS s?mtliche Definitionen wieder abtippen (und bei jedem Update überprüfen). Sofern ich mich da auf ein gekauftes Theme verlassen m?chte und kein eigenes entwerfe, halte ich das für eine ungeschickte L?sung. Oder gibts da eine andere L?sung?

Viele Grü?e, J?rg

Hi Michael,

thanx, that works!! Strange, because my Map and my aesop installation was only 1-2 weeks old, and I never have used any of these services before.

Maybe Mapbox creates old IDs under certain circumstances?

What not works is the search function. Whatever I put in the search field, when I press return, nothing happens. There is a dropbox with the (german) google hints popping up, but wheter I type by myself or use the google hits, the map does not change.

But the more important thing is that the ID is working now, thanx for this interesting solution!

Greetings, Joerg

Aesop 1.6.3

Theme Myth (child), but I tried also the Myth main and Literatum: Same problem.

I tried to create a second map and paste it’s ID, like said in some thread here. But that did not help.

When it worked (before using my own ID), I had another problem which I read of also: The search field did not work. Maybe same reason?

BTTW: Is there a way to edit the marker, especially the order?

Thanx, Joerg

Same problem here. It worked once. Then I made a Mapbox account and pasted the ID, and after this, nothing works. Only grey boxes in backend and frontend.

Even after deleting the ID I cound not get the maps back to work.

https://schoenergesehen.de/reisen/afrika/namibia-2014-unsere-routen-und-unterkuenfte-1773

Same problem here, but only with two images which are the largest images on my side. Both over 2 MB in size. One e.g. 5472×3080 px.

Year, solved, it was a WordPress Bug fixed in 3.9.1!! Had nothing to do with Hueman.

https://core.trac.www.ads-software.com/ticket/27897

That’s great news, thanx for the fast answer! So I’ll wait until the update ??