Beiträge von curiosys

Hallo,

der Patch der das Problem in der kommenden Version beheben wird, entspricht der nachfolgenden Änderung in dieser Datei: /components/com_contact/views/contact/view.html.php Zeile 335. Eine Anpassung erstellter Overrides ist dann nicht mehr nötig.

Dort wird:

$this->params = &params;

zu:

$this->params = &$item->params;

Wer die view.html.php nicht anpassen kann / möchte, kann vorübergehend die von christine2 beschriebenen Änderungen im entsprechenden Override vornehmen. Diese funktionieren auch nach dem Patch.

Gruß,
Sven

... hat hier etwa jemand preg_match gesagt?! Frevel!

@obiwan7
ist der Link (index.php?option=com_weblinks&view=category&id=11) als Beispiel zu verstehen, oder geht es dir wirklich darum Weblinks einer bestimmten Kategorie auf einer Modulposition zu veröffentlichen? Sollte dem so sein, was spricht gegen das Weblinks Modul? Abgesehen davon kann man das Plugin wirklich nicht empfehlen.

So sehr ich die Arbeit der jeweiligen Entwickler zu schätzen weiß und ihnen ihr Honorar für die Aufwände nicht absprechen möchte, kann ich nur sagen, dass kaum eine der genannten Erweiterungen eine saubere, stabile, performante, pflegbare oder dem "nativen" Status gerechtwerdende Codebase bietet.

Das wird seine Gründe haben und, beispielsweise im Fall von Joomleage, weiß ich, dass es nicht zuletzt an Freiwilligen mangelt die ein solches Projekt weiter vorantreiben. Nichtsdestotrotz, aus Sicht des Nutzers bzw. Kunden muss ich mich auf das Produkt verlassen können. Wenn ich dann sehe, dass ein JSM-Sports-Management in der Alpha Version bereits ein 13MB großes Installationspaket mitbringt (PHP 4 gemischt mit Joomla! 1.5 Code) und in Teilen aus Joomleague zu stammen scheint (Copyright?), fällt es mir persönlich sehr schwer mich damit anzufreunden, geschweige denn, mich darauf verlassen zu können.

Als zukünftige Entscheidungshilfe, nicht nur für die genannten Erweiterungen:

• wie viele Personen sind an der Entwicklung beteiligt?
• sind die Erweiterungen "nativ", dass heißt, für die jeweilige Joomla! Version entwickelt worden, oder wurden sie "migriert" (1.5.x -> 3.x)?
• wie aktiv ist die Community / der Support für diese Erweiterung und wie schnell die Reaktionszeit?
• Gibt es eine "online" Demo?
• ist der Preis angemessen? Gibt es eine Geld-zurück-Garantie? Wie hoch sind die Folgekosten, beispielsweise durch eine Verlängerung der Lizenz?
• usw.

Das Entwicklerteam sollte im besten Fall eine Firma und / oder eine Gruppe von mindestens drei Personen sein hinter denen eine aktive Community steht. Ist die Community bzw. "der Kunde" glücklich, sind meist auch die Entwickler motiviert / engagiert.

Eine Erweiterung die sowohl Joomla! 1.5/6/7.x bis hin zu 3.x unterstützt, sollte man meiden. Der Overhead an Kompatibilitäts-Layer ist kaum zu rechtfertigen. Kauft nicht die Katze im Sack und schaut im Vorfeld (online Demo oder Download), ob die Erweiterung euren Ansprüchen genügt.

Was den Preis betrifft sind 150,- € um das Beispiel von JoomSport aufzugreifen, nichts im Vergleich zu den echten Entwicklungskosten. Die Frage ist jedoch, ob man diesen Preis dem Kunden gegenüber rechtfertigen kann.

tl/dr
Augen auf beim Eierkauf

Gruß,
Sven

Danke, angepasst.

Zitat von Alex

[...]
Mir ist Deine Fragestellung noch nicht ganz klar. Generell gilt der Unterschied: HTML-Sitemap für den User, sitemap.xml für die Bots.

Die HTML-Sitemap soll dem User ein Inhaltsverzeichnis bieten. M.E. (fast) vollkommen überflüssig. Eine vernünftige Navigationsstruktur und Suchfunktion macht da schon mehr Sinn. Stichworte: Usability, User-Experiance, etc.
[...]

Hallo @Alex,

mir persönlich sind die Unterschiede klar, jedoch habe ich das Gefühl, dass einige Joomla! Webseitenbetreiber nicht selten eine Erweiterung installieren, deren Nutzen sie nicht verstehen. Oder anders ausgedrückt, deren Nutzen sich durch die Installation alleine nicht einstellen wird. Wie du bereits angedeutet hast, ist eine HTML Sitemap im Gegensatz zu einer XML Sitemap nochmal besonders zu bewerten. So sollte z.B. darauf geachtet werden welche Links man dort in welcher Tiefe aufnimmt und nicht zuletzt, dass die Ausgabe ge-cached wird.

To be continued,...
Sven

Zitat von Luby

Habe ich richtig verstanden dass ich "FACEBOOK_MODULE_ID" mit der ID des Moduls ersetzen soll welches ich zeitgesteuert einblenden will? Und natürlich in den Einstellungen des Moduls die neue Override Datei auswählen.

1.) Du erstellt in deinem Template ein Override des Moduls
Der Override wird in /templates/name_des_templates/html/name_des_moduls erstellt
2.) Du ersetzt den Code des Overrides mit dem von mir
2.1) Du trägst für FACEBOOK_MODULE_ID die ID des Moduls ein, dass in dieser Zeit nicht erscheinen soll (z.B. 64).

Ich hatte es mit verschiedenen Modulen / Zeiten getestet.

Gruß,
Sven

Hallo Luby,

sofern du nicht auf weitere Funktionen des MetaMods angewiesen bist, sollte es genügen ein Template Override des mod_custom mit folgendem Inhalt zu erstellen:

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


defined('_JEXEC') or die;


// Set FACEBOOK_MODULE_ID and time
$hour = (int) JHtml::_('date', 'now', 'G', false);
if(((int) $module->id === FACEBOOK_MODULE_ID) && (($hour >= 21) || ($hour < 6))) return;
?>


<div class="custom<?php echo $moduleclass_sfx ?>" <?php if ($params->get('backgroundimage')) : ?> style="background-image:url(<?php echo $params->get('backgroundimage');?>)"<?php endif;?> >
    <?php echo $module->content;?>
</div>

Dies mag einem weniger komfortabel erscheinen als MetaMod, erfordert aber nicht noch eine Erweiterung die es zu pflegen und / oder aktualisieren gilt und ist im Vergleich zu MetaMod weitaus weniger Overhead (~1KB vs. ~480KB).

Gruß,
Sven

P.S. Der Vollständigkeit halber sei gesagt, dass hier die Server Zeit inkl. Offset (Server) berücksichtigt wird.