Beiträge von tekknotrip

Hi,

ich drehe mich gerade im Kreis - und das schon seit Wochen

und mein ursprünglicher Ansatz bringt mich nicht weiter.

Ich habe MyShariff im Einsatz um die Teilen Buttons auf der Webseite einzusetzen.

Das Problem:

MyShariff bringt 46kb an .css und 130kb .js Dateien mit sich.

Das will ich nicht (mehr) und möchte gerne das .css des Templates dafür einsetzen (yootheme hat dafür buttons deklariert)

DSGVO-Konform sollte ja ein Link sein - bspw. so:

https://www.facebook.com/sharer/sharer.php?u=[Link Kategorie oder Artikel]

Nun lässt sich in MyShariff zwar das .css und .js ausschalten, aber das eigene .css und div-Konstrukt drumherum zu bauen ist nahezu unmöglich - zumindest für mich - ein Anbau von Yootheme ist dann auch in die Tonne zu kloppen.

Daher die Idee - ein eigenes Modul zu kreieren, dass die Parameter wie

URL (Unterscheidung zwischen Kategorie oder Artikel)

Title

Picture

in den Override, bzw. die default.php übergibt.

Dort kann man dann das div -Konstrukt (händisch - manuell) um die Links bauen.

Die Frage ist nur - wie kann ich die URL, Title und das Picture aus Joomla auslesen und in die default.php übertragen?

Hatte jemand ähnliche Probleme, oder Erfahrungen?

Bin gerade darüber gestolpert, dass PHP7.4 nun den OpCache mit preload der Klassen noch etwas weiter gepusht hat.

Frage in die Runde - unterstützt Joomla das, hat das schon einer ausprobiert und wenn ja, zu welchem Ergebnis ist man gekommen?

Schöne Grüße,

Mitches

Hallo,

ich möchte in meinem Template gerne die Social-Media-Buttons einsetzen. Diese werden nicht von Haus aus geliefert, so dass ich dazu ein Modul machen muss. Das allein ist nicht das Problem.

Diese Social-Media-Buttons erscheinen aber auf der Kategorie und auf der Artikelseite und da gilt es im Script zu unterscheiden - die Frage ist, wie würdet ihr die If-Anweisung unterscheiden? Gibt es da schon "fertige Bausteine"?

Beispiellink zu Facebook:

//Link zu Kategorie:
<a href="https://www.facebook.com/sharer/sharer.php?u=<?php echo JRoute::_(ContentHelperRoute::getCategoryRoute($item->catslug)); ?>">

//Link zu Artikel:
<a href="https://www.facebook.com/sharer/sharer.php?u=<?php echo $item->link; ?>">

Vielen lieben Dank für Tipps und Hinweise

Zitat

Indigo66

April April...

Da bist Du einem Aprilscherz aufgesessen.

Ha, das kann erst noch sein

Aber im Ernst, ich bin seit Mambo Zeiten (Mitte 90er) dabei und habe schon meine Beiträge geleistet und nein, ich will niemanden Unrecht tun, die tun alle ihr bestes - nur warte ich eben auf die 4er. Das mag vielleicht auch ein Kommunikationsproblem sein, denn ich glaube Anfang 2019 sollte es doch soweit sein. Ich habe einige Projekte und Relaunches deswegen verschoben...aber Egal.

@all

Mit oben meine ich, dass man mit jch die Scripte auch an das Ende der Seite stellen kann. Das kannst du aber nur für alles machen und dann das herausfriemeln, was nicht passt (auch inlinescripte) usw... Diese Scripte setzt du auf die Liste und die werden dann wieder wie gewohnt ausgespielt. Besser wäre hier, wenn man die Scripte - die an das Ende der Seite gesetzt werden sollen - definiert. Der Rest soll bleiben, wie er ist.

JoomlaWunder

Die css von Yootheme ist doch wegen dem UI-Kit so groß - ich denke nicht, dass sich das verändern lässt

Hi Re:Later

Danke für den Hinweis, habe ich natürlich schon getestet, aber JCH setzt erst einmal ALLES in den unteren Bereich und dann muss man herausfriemeln, was da nicht hin soll. Schicker wäre das gelöst, wenn man sagen kann, was unten hin soll.

Ein anderer Ansatz zur Problemlösung wäre natürlich, dass JCH spätestens alle 14 Tage den Cache leert. Das wird so rigoros gemacht, dass alle .js und .css Dateien gelöscht und unter einem neuen Namen neu angelegt werden. Hat Google nun die alten Daten im "Cache", existieren diese nicht mehr.

Früher hat man da mit einer Versionierung gearbeitet (.css?v101). So war sichergestellt, dass die Datei wenigsten gültig war.

Könnte zumindest eine Ursache sein, dann würden aber mehr darüber berichten.

Dass man bei JCH das Cache leeren nicht abstellen kann, ist nervig.

Ich hoffe ja, dass Joomla bald mal in die Pötte kommt. Warte gefühlt schon seit 2 Jahren darauf und irgendwo meine ich einmal gelesen zu haben, dass man die 4er verwirft und gleich zur 5er übergeht - aber nach dem Alpha Release wird das wohl nicht mehr der Fall sein.

ich erhoffe mir so einiges von Joomla 4.0

Ist ein Versuch wert

Aber nichtsdestotrotz - wie schaffe ich es denn, teile der .css, oder ganze .cs

Was ich schon einmal bestätigen kann, ist, dass der Google Bot Probleme mit css und js Dateien > 500 kb hat.

Das ist ein Problem, wenn man diese Dateien zusammenführt. Wie gesagt ist die css von yootheme ja alleine schon rund 600 kb groß.

Insofern wäre es nützlich, wenn man zunächst nicht gebrauchtes css erst am Ende, oder das Haupt css per preoload versucht zu laden. Doch wie bewerkstelligt man das mit Joomla?

JoomlaWunder - Danke für die Antwort

Nein, die Seite hat - laut Google Mitarbeiter - einen overload. Der Robot bricht nach ca. 15 Sekunden ab. Meist versemmelt der Robot die .css und die .js Daten zu laden (geprüft wird das in der Google Search Console mit URL-Prüfung). Das passiert aber nicht immer, sondern im Turnus von rund 14 Tagen und dann meist 3 Tage lang - warum? Keine Ahnung.! Leere ich den Cache (Yoothme, Joomla und JCH), ist erst einmal wieder Ruhe - aber auch nicht immer.

Das Thema treibt mich nun seit ca. 8 Monaten um, seitdem ich eben auf Yootheme umgestiegen bin. Das Phänomen aber ist derart tricky, dass das nicht so einfach ist zu beschreiben. Ich habe aber jch_optimize im Einsatz. Der Provider wurde zwischenzeitlich von Strato auf Webgo gewechselt. Die Performance ist top, daran sollte es nicht liegen (vollständige Ladezeit rund 1,7 Sek., DOM bei 800 ms, mit Werbung 10 Sek.). Die Seite setzt allerdings Werbung mit Header Bidding ein - auch ein Faktor - das wurde aber schon getestet, in dem die Werbung raus genommen wurde.

Da Yootheme von Haus aus eine sehr große .css Datei hat, beträgt die .css von JCH rund 600kb - und das kann i.d.T. für den Robot zum Problem werden. Nun versuche ich Teile der .css zu extrahieren und nach "unten" zu verfrachten. Evtl. hilft es ja. Ich habe dabei ein Menü im Verdacht (JUX- Easy Mega Menu), das zum Menu auch SVG. mit einsetzt.

Nein, die Verzeichnisse sind richtig gesetzt und auch in der robot.txt zig mal geprüft, die ist i.O. - Nutze im Übrigen Yootheme Pro 2.x

Hallo,

ich bin gerade auf der Suche nach einen Phänomen, dass der Google Bot von Zeit zu Zeit mit meiner Seite hat. Um dem Problem auf die Spur zu kommen, möchte ich ein paar .css Dateien entweder per preload, oder am Ende der Seite laden. Mein Template (Yootheme) kann das nicht und überlässt die Steuerung Joomla. Von daher die Frage, wisst ihr, wie man die .css Reihenfolge beeinflussen/ausschließen kann und ob man die Ladebedingungen für die css Dateien verändern kann (preload)?

Vielen lieben Dank für Hinweise

Jap, vielen lieben Dank das habe ich gesucht:

$images = json_decode($item->images);
$images->image_intro

Zitat

Die robots.txt diente ja ursprünglich nur zum Verbieten. Alles was nicht verboten wurde, war erlaubt.

So ist es auch immer noch - nur scheint sich Google manches mal zu verschlucken - aber wie gesagt denke ich, dass es in meinem Fall das Crawlingbudget ist. Das bedeutet dass die Anzahl der Files im Abfrageturnus zu hoch ist - deshalb brauche ich JCH.

In Yootheme 2.0 ist im Übrigen die Optimierung nicht mehr zu finden.

Zitat

Und da dein media-Verzeichnis kein disallow hat, musst du für Unterverzeichnisse von media auch kein allow setzen. Selbiges für templates, plugins und images.

Ich habe bei der Recherche für dieses Problem häufiger lesen müssen, dass man - wenn Google bemängelt - es explizit mal damit versuchen soll, die bemängelten Pfade in der robots.txt freizugeben. Nach diversen Tests soll das geholfen haben - schaden kannst nicht, aber du hast recht - erst verbieten, dann erlauben.

User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /tmp/
Allow: /*.js*
Allow: /*.css*
Allow: /*.png*
Allow: /*.jpg*
Allow: /*.gif*

#Optional - Test
User-Agent: Googlebot
Allow: .js
Allow: .css
Allow: /media/plg_jchoptimize/cache/css/
Allow: /media/plg_jchoptimize/cache/js/
Allow: /images/icons/
Allow: /templates/yootheme/fonts/
Allow: /plugins/content/myshariff/css/

Zitat

Auch die allows für die Dateiendungen (falls überhaupt richtig eingetragen) sollten weggelassen werden.

Gemäß Google wäre das Korrekt (respektive für Allow):

Grundsätzlich aber funktioniert das bei Google ja - aber nur sporadisch eben nicht. Wenn du 10 mal die Seite in der GSC prüfst, war das 6 mal erfolgreich und 4 mal nicht. Google sollte niemals die Weltherrschaft erlangen

Danke für eure Hinweise und Erfahrungen.

Das interessante ist, dass wenn Google etwas bemängelt, ich aber einen Test laufen lasse, so kommt es zu keinen Fehlern. Das - kann - auf das Crawlbudget zurückzuführen sein.

JoomlaWunder

Die Robots.txt sieht mittlerweile wie folgt aus - doch verändert hat das an der Problematik nichts:

User-agent: *

Allow: /*.js*
Allow: /*.css*
Allow: /*.png*
Allow: /*.jpg*
Allow: /*.gif*

User-Agent: Googlebot
Allow: .js
Allow: .css
Allow: /media/plg_jchoptimize/cache/css/
Allow: /media/plg_jchoptimize/cache/js/
Allow: /images/icons/
Allow: /templates/yootheme/fonts/
Allow: /plugins/content/myshariff/css/

Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /tmp/

@Birger

Wie meinst du das, dass das nicht miteinander funktioniert?

Hallo Birger,

Danke für den Tipp - alles schon ausprobiert - doch auch das hat Nachteile:

JCH fungiert in diesem Sinn nicht als Cache, sondern als Optimizer. Der Page-Cache ist aktiv, weil dieser die response Zeit des Servers auf ein Minimum setzt. Den Yootheme Cache kann man nicht deaktivieren. OPcache ist vorhanden, doch sorgt dieser nicht für statische Seiten (response Zeit).

Was fehlt, ist vermutlich ein anständiges "Löschkonzept" - die Fehlersuche ist deshalb problematisch, da es kein Fehler im klassischen Sinn ist und nur sporadisch bei Google zu finden ist. Häufig führte die folgende Reihenfolge zum Erfolg:

1.) Yootheme Cache löschen

2.) JCH-Chache (im Plugin) den Cache löschen

3.) Joomla und jch Cache löschen

Aber eben nicht immer und ich würde gerne dem auf den Grund gehen, warum das so ist.

P.s. was mir gerade aufgefallen ist: Yootheme hatte bis Version 2.0 noch die eigene minify Variante von .js und .css an Board (war bei mir aber abgeschaltet) - diese fehlt nun in der 2.0.x Version. Das werde ich mal testen.

Was für mich halt so absolut nicht nachzuvollziehen ist:

Google Search Console sagt, dass das css File nicht zu erreichen ist. Ist es aber und funktioniert - ein Timeout kann ich nicht feststellen (auch nicht in den Logs). Nun könnte man noch sagen, dass es sich um einen Schluckauf von Google handelt - so ist es aber nicht, da dieses Phänomen nun seit einigen Monaten alternierend immer wieder kehrt.

Hmm, denkbar wäre auch folgend banales:

https://translate.google.com/t…hread%2F2348563%3Fhl%3Den

Hallo zusammen,

bei einer meiner Seiten kann Google - zeitweise - nicht auf die komplette Webseite zugreifen.

Dabei handelt es sich nicht um die Blockierung von robots.txt oder um einen Timeout.

Das tritt auch nicht immer auf - so alle 14 Tage, manchmal auch 21 Tage. Die Webseite ist in der Search Console von Google zu erreichen, doch wird zumeist das .css, .js oder einzelne Bilder nicht geladen. Ich hatte zunächst den Hoster in Verdacht, doch den habe ich zwischenzeitlich gewechselt und das Phänomen tritt weiterhin auf.

Das Phänomen tritt auf, seitdem ich Yootheme nutze. Parallel dazu läuft JCH und das Cache-Plugin von Joomla.

Die Webseite selbst läuft flüssig und weist keinerlei Probleme auf - ich denke aber, dass es ein Cache Problem ist.

Manchmal hilft es, wenn man alle Caches leert (auch den von Yootheme) und die Seite eine weile ohne Cache laufen lässt, doch ist das keineswegs immer der Fall

Vielleicht kennt einer von euch dieses Phänomen, oder hat eine Idee!?

Robots.txt

User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /tmp/

Die Webseite teile ich gerne per PM mit

Schöne Grüße

Das Original "Latest_News" Modul sieht ja so aus:

<?php
/**
 * @package     Joomla.Site
 * @subpackage  mod_articles_latest
 *
 * @copyright   Copyright (C) 2005 - 2020 Open Source Matters, Inc. All rights reserved.
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */

defined('_JEXEC') or die;
?>
<ul class="latestnews<?php echo $moduleclass_sfx; ?> mod-list">
<?php foreach ($list as $item) : ?>
    <li itemscope itemtype="https://schema.org/Article">
        <a href="<?php echo $item->link; ?>" itemprop="url">
            <span itemprop="name">
                <?php echo $item->title; ?>
            </span>
        </a>
    </li>
<?php endforeach; ?>
</ul>

Ich möchte aber gerne ein Image vorne an stellen. Dieses Bild ist bereits optimiert. Was ich aber nicht weiß, wie ich den Pfad zum Bild im Script selbst aufrufen kann. Könnt ihr mir einen Tipp geben?

Danke,

Mitches

Hallo Indigo66

danke für die Antwort.

Ich hatte schon nach den OPcache hier im Forum und Web gesucht und bin teilweise über Empfehlungen gestolpert, die ich für falsch halte - ohne es aber zu wissen.

Viele - auch im Web - empfehlen den System Cache, das Cache Plugin, JCH UND den OPcache zu aktivieren.

Das ist zu viel, da sich mir der Sinn vom zeitgleichen System Cache und dem Cache Plugin nicht erschließt. Wird aber leider von Joomla auch nicht sonderlich kommuniziert, bzw. darauf hingewiesen.

Ich bin bei webgo - dort ist es aktiviert, aber nicht aktiv. Das muss man erst über die php.ioi aktivieren:

zend_extension=opcache.so
opcache.enable =1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Da sich der Cache aber erst aufbauen muss, habe ich am Anfang das Cache Plugin in Joomla parallel zum OPcache laufen lassen. Erst jetzt, wo sich die Zahlen im OPchache stabilisieren erwäge ich das abschalten des Joomla Caches.

Würde mich freuen, wenn noch andere ihre Erfahrungen teilen könnten

Schöne Grüße in die Runde!

Hallo,

ich möchte hier einmal eine Frage an die Experten stellen, was Sinnvoll ist, und was nicht.

Joomla hat ja zwei Cache Möglichkeiten - der dynamische und der statische Cache.

Ich habe mit dem statischen sehr gute Erfahrungen gemacht.

Sinnvollerweise sollte also nur einer der beiden Routinen aktiv sein.

Ebenso habe ich gute Erfahrung mit jch und dem statischen Cache gemacht - jch standardmäßig auf Average

Gzip habe ich deaktiviert, da ich über die htaccess deflate nutze

Da scheiden sich die Geister, was besser ist.

Nun bietet mein Provider aber den OPcache an.

Wenn ich es richtig verstehe, werden da ganze PHP-Script Routinen in den Speicher geschmissen, so dass diese nicht mehr geparst werden müssen.

Theoretisch kann ich mir ja dann den Cache von Joomla sparen - oder?

Theoretisch auch den jch, bzw. diesen auf das Minimum setzen

Wie seht ihr das?

Ich habe so meine Probleme in Spam oder sicherheitsrelevanten Themen eine Webseite zu posten, so lange nicht klar ist, was die Ursache war. Zu groß ist die Versuchung, eine mögliche Lücke auszunutzen - so zumindest meine Erfahrung.

Es handelt sich aber nicht um eine Lücke, sondern um eine etwas unglückliche Einstellung, bzw. eine standardisierte Möglichkeit Joomla als Spammaschine zu nutzen.

j!-n

Danke für den Hinweis - jetzt verstehe ich, wie das missbraucht werden kann!!!

Soo, habe den Kontakt einmal deaktiviert. Mal sehen, ob das funktioniert.

Sieger66

Habe ich gegen Forenregeln verstoßen?

Und ja, Re:Later kennt den Link

Die Frage, die ich mir aber stelle: Wie kann es sein, dass über den Aufruf eines Kontaktformulares Spam-Mails an andere E-Mailadressen versendet werden kann? Wenn, dann sollte das doch nur an die eigene Adresse gehen!?