OXID Community Forum

Problem beim deinstallieren des Sofortüberweisung-Moduls

Jonesey — Thu, 02 Jul 2009 21:08:22 GMT

Hallo Oxidler,

heute ist mir was ganz komisches mit meinem Shop passiert. Wollte gestern das Aggrosoft-Sofortüberweisungs-Modul installieren. Alles schön gemacht, heute fällt mir dann auf, dass ich nicht mehr auf meine Produktdetails komme - es erscheint immer nur ein White Screen ohne jeglichen Inhalt.

Gut, da ich nicht genau wusste ob es mit dem Modul zu tun hat, habe ich dieses Stück für Stück wieder deinstalliert und dann passierte etwas ganz komisches: Sobald ich im Admin-Backend den Aufruf des Moduls aus den Grundeinstellungen nehme, komme ich nicht mehr auf den Shop?! Rufe ich die Root-Domain auf, kommt diesmal schon dort ein weisser Bildschirm - sonst nichts. Stelle ich den Aufruf wieder rein, funktioniert es wieder. Wie geht sowas denn!? :D

Weiss jemand hier Rat?

Viele Grüße,
Martin

Zugriffsschutz auf Verzeichnisse in .htaccesss

upaffrath — Thu, 02 Jul 2009 15:22:59 GMT

Hallo,

ich habe mir gerade mal den Bug-Eintrag https://bugs.oxid-esales.com/view.php?id=899 von Marco angeschaut.
Für die tpl-Dateien funzt das. Beim Aussperren der php-Datein kommt ein Zugriffsfehler (Shop startet nicht).
Mache ich da was falsch?

Gruß Uwe

Statt 3.Bestellschritt erscheint "Newsletter"

SvenA — Thu, 02 Jul 2009 14:10:38 GMT

Hallo,

ich habe in meinem Shop heute gerade ein sehr merkwürdiges Verhalten festgestellt. Wenn man im 2.Bestellschritt "Newsletter abonnieren" ankreuzt, erscheint nach dem Klicken auf "Weiter zum nächsten Schritt" nicht der 3.Bestellschritt, sondern eine weiße Seite mit dem OXID Logo und dem Titel Newsletter.
Mache ich das Kreuz nicht komme ich ganz normal zum 3.Bestellschritt.

Was läuft denn da falsch?

Der Shop liegt unter http://stralsunder-piratenschatz.de

P.S. In den Error-Logs steht folgendes:

Code:

PHP fatal error: Smarty error: [in ox:oxnewsletteremailoxcontent line 6]: syntax error: unrecognized tag: $oViewConf-?phpMyAdmin=vuKrXCNBMhbK-0z6ij3FPGe0781>getSelfLink()](Smarty_Compiler.class.php, line 446) in /srv/www/usw..../Smarty.class.php on Line 1092, referer: http://stralsunder-piratenschatz.de/index.php?

Hm, er kennt also irgendeinen Tag nicht, aber warum und wo genau? In einem Template oder mag er etwas nicht was ich im Adminbereich eingegeben habe?

Не отображается Variants description text

oxenbash — Thu, 02 Jul 2009 13:35:42 GMT

добрый день!

подскажите, пожалуйста, как можно включить отображение описания варианта?

оксен.

CE 4.1.3 - werden gelöschte Bilder nicht gelöscht?

mihinri — Thu, 02 Jul 2009 12:58:18 GMT

Hallo zusammen,

ich hab mal ne Frage weil ich gerade an den Bildern und Strukturen bin ...

Wenn man in einer Kategorie, einem Artikel etc. ein Bild im Admin Bereich löscht,
wird das nicht auf dem Server "mit-"gelöscht.

Warum eigentlich nicht?
Ist das so üblich ... oder evtl. ein "bug" ?

Viele Grüsse
Michael

CE : ../httpdocs/out/pictures - wo liegen welche Bilder?

mihinri — Thu, 02 Jul 2009 12:52:45 GMT

Hallo zusammen,

hat jemand eine Info für mich, in welchem Verzeichnis welches Bild liegt?
Die vier z1 bis z4 (Zoom1 - Zoom4) kann ich mir neben icon ja noch zusammenreimen :-)

Ist das so :
ICON = Icon
0 = Thumbnail
1 = Bild 1
...
7 = Bild 7

wofür dann noch 8-12?

Danke
Michael

Detailansicht Kategorien htaccess

saschamarkuse — Thu, 02 Jul 2009 08:42:15 GMT

Hallo

Shop-Url: tstshop.rc-eheli.de

Die Detailansicht der Artikel funktioniert leider nicht. Besteht die Möglichkeit das dies an der htaccess liegt?

Danke schonmal!

Sascha

Hier die htaccess:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_URI} !(\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteRule admin/test\.php$ admin/test.php?mod_rewrite=1

RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !(\.html|\/|\.jpg|\.css|\.pdf|\.doc|\.gif|\.png|\.js)$ %{REQUEST_URI}/ [R=301,L]

RewriteCond %{REQUEST_URI} !(\/admin\/|\/core\/|\/export\/|\/modules\/|\/out\/|\/setup\/|\/tmp\/|\/views\/)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (\.html|\/)$ oxseo.php

Options -Indexes

RewriteBase /shop/
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

Der Stand der Dinge..... (Entwicklersicht, Teil 2)

avenger — Thu, 02 Jul 2009 07:24:38 GMT

Warnung: Das folgende Posting ist auch lang, sehr technisch, und nix für schwache Nerven! :D

OXID geht standardmäßig so vor:

Jede "Content"-Vorlage (verwendet von den "view"-Klassen) inkludiert als erstes die "_header.tpl"-Vorlage und gibt das Ergebnis des Renderns dieser Vorlage direkt aus.

Dann wird die jeweilige "Content"-Vorlage selbst gerendert, und der Code ausgegeben.

Abschließend inkludiert die "Content"-Vorlage die "_footer.tpl"-Vorlage und gibt deren Code aus.

Die Aufgabe bestand also darin, zu erreichen, dass das HTML der jeweiligen gerenderten "Content"-Vorlage nicht direkt ausgegeben wird, sondern in einer Smarty-Variable ("$main_content") bereit gestellt wird.
(Und das, ohne die bestehenden Template-Dateien ändern zu müssen...)

Dies wurde durch Änderungen der "_header.tpl"- und "_footer.tpl"-Vorlagen realisiert.

Die "_header.tpl" startet jetzt kein Rendern und keine Ausgabe mehr, sondern schaltet PHP nur in den "Output-Buffering"-Modus um, damit der folgende Inhalt der "Content"-Vorlagen nicht direkt ausgegeben, sondern in einen Buffer geschrieben wird.

Sie besteht nur noch aus folgendem Code:

Code:

[{php}]

ob_start();

[{/php}]

In der "_footer.tpl"-Vorlage muss nun (konsequenter Weise) der Inhalt dieses Output-Buffers ausgelesen, und in der Smarty-Variablen "$main_content" gespeichert werden.

Und es muss natürlich dann das Rendern meiner neuen "_index.tpl"-Vorlage gestartet werden, um die komplette Seite endgültig aufzubauen.

Der Code der neuen "_footer.tpl"-Vorlage ist wieder trivial;

Code:

[{php}]

$main_content=ob_get_clean();

$this->assign('main_content',$main_content);

[{/php}]

[{include file="_index.tpl"}]

(Der eigentliche "_footer.tpl"-Vorlagen-Code wird jetzt an anderer Stelle ("boxes.php") gerendert und in der Smarty-Variablen $footer bereit gestellt.)

Und, voilà, meine OXID-Seite ist komplett....

Nun fühle ich mich mit dem OXID-Templating wieder "pudelwohl", und habe mir damit einige Vorteile verschafft:

Es gibt eine Stelle, an der das Seitenlayout komplett definiert, überschaubar und verständlich ist ("_index.tpl").
Die sehr einfache Möglichkeit, "Boxen" innerhalb des Designs zu verlagern,
Für Änderungen leicht identifizierbarer Boxen-Code (pro Box eine Vorlage)
Mein in mehreren Jahren entwickeltes Templating-Konzept und Know-How aus dem xtc/Gambio-Bereich kann ich damit weitestgehend auf OXID übertragen, was die gedankliche und handwerkliche Umstellung sehr viel einfacher macht.

Zugegeben, ich musste dafür an ein paar Stellen die reine "Smarty"-Lehre über Bord werfen, und ein wenig PHP zu Hilfe nehmen.

Aber das sehe ich sehr pragmatisch: wenn das mir hilft, Dinge für mich wesentlich zu vereinfachen, dann tue ich das (und pfeife auf die "reine Lehre")!

Noch ein paar Besonderheiten:

Wie man in der "_index.tpl" sieht, werden hier nicht direkt die zuvor erwähnten Boxen-Namen verwendet (z.B. "box_LOGIN"), sondern Namen wie "box_l_01" usw..

Dies ist ein weiterer Teil der schon erwähnten Automatismen, die mir mein Template-Entwickler-Leben erleichtern: die externe Definition (in einer Datei) welche Boxen verwendet, und wo die plaziert werden sollen!

"box_m_xxxx"-Boxen werden dabei im Header-Bereich, die "box_l_xxxx"- und "box_r_xxxx"-Boxen im linken bzw. rechten Navibereich plaziert.

Mit einfachen Anweisungen wie z.B. "box_bestsellers=r,5" wird damit die "Bestsellers"-Box aktiviert, und als 5. Box im rechten Navi-Bereich plaziert.
(Man muss damit also gar nicht mehr irgendwelchen Code umkopieren, um eine Box hinzuzufügen/zu entfernen/zu verlagern, das regelt sich alles automatisch....)

Gleichzeitig werden daraus auch die "SHOW_XXXXX"-Konstanten definiert, so dass man damit in der "boxes.php" prüfen kann, ob eine Box verwendet werden soll oder nicht.

Diese Konfigurationsdatei für das Template auf http://oxid.powertemplate.de/ sieht beispielsweise wie folgt aus:

Code:

#

# box-name=navi-area (l,m,r),box-position in navi-area

#

box_accessories=

box_also_purchased=

box_bestsellers=l,4

box_cart=

box_categories=l,1

box_content=l,2

box_cross_selling=

box_currencies=

box_languages=

box_login=m,8

box_longruns=l,6

box_manufacturers=

box_mini_cart=m,7

box_news=

box_navbar=m,4

box_newsletter=m,6

box_partners=

box_search=m,5

box_service=l,3

box_similiar=

box_specials=

box_tell_friend=

box_top_links=

box_top_navi=

box_top_navi_links=m,14

box_vendors=

box_whatsnew=l,5

box_wishlist_link=m,11

Ein (teilweise schon ereichtes) Ziel ist es auch noch, die OXID-Konfigurations-Parameter daraus gleich so zu setzen, dass nicht verwendete Boxen gar nicht erst erstellt werden.
(Bisher kann man das im Admin-Bereich steuern, aber da ich keine Lust habe, das bei jeder Kunden-Installation mühsam wieder händisch konfigurieren zu müssen, mache ich das lieber programmatisch.)

Mit Hilfe meiner (per Subclassing) erweiterten Smarty-Version erhalten die "Boxen" auch gleich die richtigen CSS-Klassen und IDs zugewiesen.

So ist jede Box eingeschlossen in einen DIV wie "

", so dass die Boxen automatisch die CSS-Eigenschaften der linken, rechten und Header-Boxen erben, aber auch die Möglichkeit eines individuellen CSS-Stylings geben.

Ich kann damit sehr einfach das Layout der linken und rechten Boxen und Navi-Spalten (unterschiedlich) gestalten, ohne jede Box einzeln anpassen zu müssen, egal, wohin ich sie plaziere!.

Weiterhin habe ich OXID für einen dynamischen Template-Wechsel vorbereitet!

Es gibt viele Gründe, wofür so was nützlich ist:

URL-abhängiges Template-Design.
Kategorie-abhängiges Template-Design.
Sprach-abhängiges Template-Design.
Tages-/Jahreszeit-abhängiges Template-Design.
Demo verschiedener Template-Designs in einem Shop.

usw. (Das sind alles Dinge, die wir im xtc/Gambio-Umfeld für Kunden schon gemacht haben...)

Standardmäßig scheitert das in OXID daran, dass a.) der Template-Name fest in der Datei "config.inc.php" festgelegt wird, und dass es b.) shopweit nur ein Smarty "Compile"-Verzeichnis gibt ("out/tmp").

(Letzteres würde dazu führen, dass immer die zuletzt kompilierten Vorlagen aus allen Templates dargestellt würden, bzw. die Vorlagen immer neu kompiliert würden....)

Das Smarty "Compile"-Verzeichnis wurde daher jetzt nach "out/template_name/tpl_c" verlagert, so dass die verschiedenen Templates sich nicht mehr gegenseitig stören können.

Und der Template-Name wird dynamisch gesetzt, so dass OXID unterschiedliche Templates verwenden kann.

Fazit:

Das Standard-OXID-Templating ist m.E. etwas "sperrig" (was sich m.E. auch darin äußert, dass viele Shops sich nur mit kosmetischen Änderungen (andere Farben und anderes Logo) am Standard-Design zufrieden geben (müssen)).

Aber es ist auch so flexibel (vor allem Dank der Verwendung von Smarty), dass man sich das relativ einfach nach seinen Vorstellungen zurecht biegen kann...

Und es bietet durch die Bereitstellung der kompletten Shop-Objekte im Template, mächtige Möglichkeiten, das Shop-Aussehen zu beeinflussen.

Bei Magento z.B., das von Hause aus um Größenordnungen sperriger ist (weil es im Grunde kein akzeptables Templating-Konzept besitzt), würde ich noch nicht mal wagen, an so eine Änderung zu denken...

Die von mir auf Template-Basis durchgeführten Änderungen könnte man natürlich wesentlich eleganter im OXID-Core vorsehen.

Vielleicht ist das ja eine Anregung für die OXID-Entwickler: das OXID-Templating kann man definitiv (und ohne allzu große Mühe) übersichtlicher gestalten!

To do:

Als Entwickler finde ich diese über den Admin-Bereich gesteuerten Änderungen des Templates ("Look & Feel") einfach ätzend (wie bei Gambio auch),
Das ist mindestens 10 mal ineffizienter, als wenn ich die resultierenden CSS-Änderungen direkt in der CSS-Datei vornehme....
(Man stelle sich mal vor, ein komplexes Template wie das auf http://oxid.powertemplate.de/ auf diese Art und Weise bei einem Kunden installieren zu wollen...)

Das war also das erste, was ich über Bord geschmissen habe, ich verwende jetzt meine eigene CSS-Datei!

Was mich jetzt noch stört sind die diversen eMail- und sonstigen CMS-"Snippets", die ja auch über den Admin-Bereich geändert werden müssen....

Für mich als Entwickler wäre das wieder sehr viel einfacher, wenn diese CMS-"Snippets" auch in Dateien in meinem Template-Verzeichnis liegen würden...

Ich denke, ich werde mal das OXID Smarty-Plugin "oxcontent" so modifizieren, dass es erst mal nachschaut, ob eine Datei des gesuchten Namens im Template-Verzeichnis existiert, bevor es in der Datenbank sucht...

Dann kann man diese CMS-"Snippets" nämlich auch einfach mit dem Template ausliefern...

Der Stand der Dinge..... (Entwicklersicht, Teil 1)

avenger — Thu, 02 Jul 2009 07:23:52 GMT

Warnung: Das folgende Posting ist lang, sehr technisch, und nix für schwache Nerven! :D

HTML clipboardIch hatte ja in Post http://www.oxid-esales.com/forum/showthread.php?t=1578 schon meine Eindrücke von OXID aus Anwendersicht niedergeschrieben (nach einiger Beschäftigung damit), und auf auf http://oxid.powertemplate.de/ ein paar Dinge gezeigt, die ich mittlerweile da "templatemäßig" realisieren konnte.

Heute will ich mal (aus Entwicklersicht) beschreiben, wie ich das OXID-Templating so umgebaut habe, dass es m.E. wesentlich übersichtlicher und leichter handhabbar ist. Und mir meine Arbeit als Templateentwickler auf Dauer erleichtert.

Vielleicht sind die folgenden Erläuterungen ja auch hilfreich für andere, die sich, wie ich, von der xtc-Erfahrung her dem OXID-Templating nähern...

Vielleicht auch als Anregung an die OXID-Entwickler, da sich meine im folgenden beschriebenen Änderungen natürlich sehr viel eleganter im OXID-Core realisieren lassen....

Mein erster Eindruck vom OXID-Templating war: sehr unübersichtlich.

Was mir am OXID-Templating insbesondere nicht gefiel, war, dass die Templatestruktur zu sehr auf das jetzige OXID-Standard-Template ausgerichtet ist, und Änderungen am Code und der Plazierung der "Boxen" ziemlich unübersichtlich sind.

Es gibt in OXID 4 Template-Dateien ("_header.tpl", "_left.tpl", "_right.tpl", "_footer.tpl"), die das Layout der Seite definieren, und in denen inline(!) (Iiiigiiiittttt!) der Smarty-Code (der auch noch wie PHP-Code aussieht!) der verschiedenen "Boxen" enthalten ist.

In diesen Vorlagen "sieht man den Wald vor lauter Bäumen nicht" (zumindest ich nicht), d.h., Änderungen in den Codes für die "Boxen" bzw. deren Umplazierung sind m.E. sehr unübersichtlich.

Andererseits fand ich die xtc-Template-Struktur schon immer sehr übersichtlich: es gibt eine "index.html", in der die komplette Seitenstruktur übersichtlich definierbar ist, und in der individuelle Boxen über ihre Smarty-Platzhalter sehr einfach eingebaut und verlagert werden können.

Und jede "Box" ist als eine separate Smarty-Template-Datei vorhanden, so dass man sehr genau weiß, wo man ggfs. etwas ändern kann.

Hinzu kommt, dass mir diese Struktur über die letzten ca. 6 Jahre einfach sehr vertraut geworden ist, und ich mir (mit Hilfe einer (per Subclassing) modifizierten Smarty-Version und ein paar PHP-Modulen) im Laufe der Zeit einige Automatismen geschaffen habe, die mir das Leben als Template-Entwickler sehr vereinfachen.

Und so habe ich denn OXID auch eine solche Strukturierung und ein übersichtliches Zentral-Template (a.k,a "index.html" in xtc) "verpasst", damit komme ich einfach sehr viel besser klar.

Nach Analyse der OXID "_header.tpl"-, "_left.tpl"-, "_right.tpl"-Vorlagen habe ich folgende "Boxen" in OXID identifiziert (die xtc Nomenklatur habe ich dabei weitestgehend beibehalten):

box_ACCESSORIES
box_ALSO_PURCHASED
box_BESTSELLERS
box_CART
box_CATEGORIES
box_CONTENT
box_CROSS_SELLING
box_CURRENCIES
box_INFORMATION
box_LANGUAGES
box_LOGIN
box_MANUFACTURERS
box_MINI_CART
box_NAVBAR
box_NEWS
box_NEWSLETTER
box_PARTNERS
box_SEARCH
box_SERVICE
box_SIMILIAR
box_SPECIALS
box_TELL_FRIEND
box_TOP_LINKS
box_TOP_NAVI
box_TOP_NAVI_LINKS
box_VENDORS
box_WHISHLIST_LINK

(Interessant, dass "cross-selling", "also-purchased" und "accessories" bei OXID als Boxen behandelt werden. In xtc gehört das ja bekanntlich zum Content. Wohin ich das mittlerweile (alternativ) auch verlagert habe...)

Den relevanten "Smarty"-Code für diese "Boxen" aus den "_header.tpl"-, "_left.tpl"-, "_right.tpl"-Vorlagen habe ich dann in jeweils eine separate Vorlagen-Datei für jede Box ausgelagert. (Richtig, der xtc-Kenner ahnt es schon: die liegen im Unterverzeichnis "boxes" des Template-Verzeichnisses...)

Diese ausgelagerten (Boxen-)Code-Teile wurden dann aus den "_header.tpl"-, "_left.tpl"-, "_right.tpl"-Vorlagen entfernt. ("_left.tpl" und "_right.tpl" werden deswegen jetzt gar nicht mehr benötigt...)

So weit, so gut!

Aber wie kommen jetzt diese "Boxen" wieder in das Template hinein?

Man ahnt es schon (xtc lässt grüßen!): indem es ein PHP-Modul "boxes.php" gibt, das die verwendeten Boxen mit Hilfe von Smarty rendert, und deren gerenderten HTML-Code der Box als Smarty-Variable dem Template zur Verfügung stellt!

Diese "boxes.php" ist ziemlich simpel:

Code:

$oView=$this->_tpl_vars['oView'];

if (SHOW_NAVBAR)

{

  $box_content=$this->fetch("boxes/box_navbar.tpl");

  $this->assign("box_NAVBAR",$box_content);

}

if (SHOW_SEARCH && $oView->showSearch())

{

  $box_content=$this->fetch("boxes/box_search.tpl");

  $this->assign("box_SEARCH",$box_content);

}

if (SHOW_NEWSLETTER && $oView->showNewsletter())

{

  $box_content=$this->fetch("boxes/box_newsletter.tpl");

  $this->assign("box_NEWSLETTER",$box_content);

}

if ($oView->showTopBasket())

{

  $box_content=$this->fetch("boxes/box_mini_cart.tpl");

  $this->assign("box_MINI_CART",$box_content);

}

.... u.s.w. ....

(Die "SHOW_XXXXX"-Konstanten sind Teil des schon erwähnten Automatismus', mit dem ich u.a. sehr einfach festlegen kann, welche Boxen wo verwendet werden sollen. Mehr dazu später.)

Damit habe ich jetzt das HTML jeder verwendeten Box als jeweils eigene Smarty-Variable im Template verfügbar.
Zusammengeführt wird das OXID Seiten-Layout, wie bei xtc & Co., dann über eine (vollständig definierte, abgeschlossene und übersichtliche!) "_index.tpl"-Seite (analog zur "index.html" in xtc), und nicht aus mehreren losen Enden ("_header.tpl" & Co.)!

Meine "_index.tpl" sieht wie folgt aus:

Code:



  

    .... head-data .....

  

  [{php}]

  //Do the templating magic!

  include(INC_PATH.'pt_setup.inc.php');

  [{/php}]



      

        [{$pt_header_image}]

        [{$box_m_04}]

        [{$box_m_05}]

        [{$box_m_06}]

        [{$box_m_07}]

        [{$box_m_08}]

        [{$box_m_09}]

        [{$box_m_10}]

        [{$box_m_11}]

        [{$box_m_12}]

        [{$box_m_13}]

        [{$box_m_14}]

        .......

        [{$box_m_nn}]

        


      


      

        

          [{$box_l_01}]

          [{$box_l_02}]

          [{$box_l_03}]

          [{$box_l_04}]

          [{$box_l_05}]

          [{$box_l_06}]

          [{$box_l_07}]

          [{$box_l_08}]

          [{$box_l_09}]

          [{$box_l_10}]

           .......

          [{$box_l_nn}]

        


        

          [{$box_r_01}]

          [{$box_r_02}]

          [{$box_r_03}]

          [{$box_r_04}]

          [{$box_r_05}]

          [{$box_r_06}]

          [{$box_r_07}]

          [{$box_r_08}]

          [{$box_r_09}]

          [{$box_r_10}]

          .......

          [{$box_r_nn}]

        


        

          [{include file="inc/error.tpl" Errorlist=$Errors.default}]

          [{oxid_include_dynamic file="dyn/newbasketitem_message.tpl"}]

          [{$main_content}]

          


        


        

          [{$footer}]

        


      


      


      [{oxid_include_dynamic file="dyn/newbasketitem_popup.tpl"}]

      [{if $popup}][{include file=$popup}][{/if}]

(Wer den Code der OXID "_header.tpl"-, "_left.tpl"-, "_right.tpl"-Vorlagen kennt, weiß diese Übersichtlichkeit sicher ebenso zu schätzen wie ich....)

HTML clipboardDas große Problem dabei war, dass OXID den Template-Code seriell ("wie er kommt") rendert und ausgibt.

Und die einzelnen Elemente nicht als Smarty-Variable bereit stellt, die dann in einer "_index.tpl", gemäß dem darin festgelegten Bauplan, "zusammengerendert" werden können.
Damit das alles dennoch so funktioniert, musste ich allerdings etwas von der reinen "Smarty"-Lehre abweichen...

Mit

Code:

[{php}]

include(INC_PATH.'pt_setup.inc.php');

[{/php}]

in der "_index.tpl" rufe ich nämlich im Template den PHP-Code auf, den ich brauche, um die ganzen notwendigen Umsetzungen für mein neues OXID Template-Konzept vorzunehmen.

Aber die Vorteile, die mir diese Vorgehensweise bringt, sind m.E. so immens, dass ich diese kleine "Sünde" gerne in Kauf nehme....

Wie wurde das realisiert?

Weiter geht es in: Der Stand der Dinge..... (Entwicklersicht, Teil 2)

Design Menü Problem

racoon — Wed, 01 Jul 2009 17:00:00 GMT

Hallo mal wieder,

soll-zustand meine menüs: Als Beispiel...

aktivierte Hauptpunkte rot.
aktivierte Unterpunkte dunkelgrau und Hauptpunkt bleibt rot.

mouse over bei Hauptpunkten rot.
mouse over bei Unterpunkten hellgrau.

Die Spaltenhöhe bei Unterpunkten ist ein paar Pixel weniger.

Ist zustand:
Ich kriege kein Layout für die Unterpunkte hin!?

Denke hierfür müsste ich die category_tree.tpl anfassen, oder?

HTML Code:

[{if $tree || $oView->getContentCategory() }]

[{assign var="oContentCat" value=$oView->getContentCategory() }]

[{defun name="category_tree" tree=$tree act=$act class=$class testSubCat=''}]

[{strip}]

    

    [{foreach from=$tree item=ocat key=catkey name=$test_catName}]

        [{if ( !$ocat->isTopCategory() || !$oView->showTopCatNavigation() ) && $ocat->getContentCats() }]

            [{foreach from=$ocat->getContentCats() item=ocont key=contkey name=cont}]

                        

            "test_BoxLeft_Cms_[{if $ocat->isTopCategory()}][{$ocat->oxcategories__oxid->value}]_[{$smarty.foreach.cont.iteration}][{else}][{$testSubCat}]_sub[{$smarty.foreach.cont.iteration}][{/if}]" href="[{$ocont->getLink()}]" class="[{if $ocat->isTopCategory()}]root[{/if}][{if $oContentCat && $oContentCat->getId()==$ocont->getId()}] act last[{/if}]">[{ $ocont->oxcontents__oxtitle->value }]

            [{/foreach}]

        [{/if}]

        [{if $ocat->getIsVisible() }]

        

            "test_BoxLeft_Cat_[{if $ocat->isTopCategory()}][{$ocat->oxcategories__oxid->value}]_[{$smarty.foreach.$test_catName.iteration}][{else}][{$testSubCat}]_sub[{$smarty.foreach.$test_catName.iteration}][{/if}]" href="[{$ocat->getLink()}]" class="[{if $ocat->isTopCategory()}]root [{/if}][{if $ocat->hasVisibleSubCats}][{if $ocat->expanded }]exp [{/if}]has [{else}]last [{/if}][{if isset($act) && $act->getId()==$ocat->getId() && !$oContentCat }]act [{/if}]">[{$ocat->oxcategories__oxtitle->value}] [{if $ocat->getNrOfArticles() > 0}] ([{$ocat->getNrOfArticles()}])[{/if}]

            [{if $ocat->getSubCats() && $ocat->expanded}]

                [{fun name="category_tree" tree=$ocat->getSubCats() act=$act class="" testSubCat=$ocat->oxcategories__oxid->value }]

            [{/if}]

        

        [{/if}]

    [{foreachelse}]

        [{if $oContentCat }]

            "test_BoxLeft_Cms_0" class="root act" href="[{$oContentCat->getLink()}]">[{ $oContentCat->oxcontents__oxtitle->value }]

        [{/if}]

    [{/foreach}]

    

[{/strip}]

[{/defun}]

[{/if}]

Hier kenn ich mich aber ganz und gar nicht aus. Wie kann ich denn erfahren, was z.b. $testsubcat usw. überhaupt in sich trägt.

CSS:

HTML Code:

ul.tree li a {background:#fff  no-repeat right  500px;color:#669999;display:block;padding:10px 2px;border-top:1px solid #CCCCCC;}

ul.tree li a.has{background:#66CC33;padding-right:10px;background-position:right -175px;}  

ul.tree li a.root{background:#fff;text-indent:10px;padding-right:0;background-position:0 -175px;font-weight: bold;border-color:#CCCCCC;}

ul.tree li a.exp{background:#fff;text-indent:10px;padding-right:0;background-position:0 -200px;}  

ul.tree li a.act{background:#55728a;color:#fff;}

ul.tree li a:hover{ background:#55728a;color:#fff;}

ul.tree li a.exp.act{background:#34534}

Hier ist wohl pauschal der gesamte baum betroffen. Muss eine zusätzliche child-css für die Unterpunkte anlegen und im .tpl diese ansprechen. Doch wo im category_tree.tpl.
Oder ist meine Vermutung falsch?

Wäre jmd so nett und hilft mir auf die Sprünge. 100000 Dank schon im Voraus!

...Ansonsten komm ich sehr gut voran. Vielen Dank an alle!

Oxid Logo

slike — Wed, 01 Jul 2009 14:50:55 GMT

Hallo Oxid-Gemeinde!

Ich bin mir nicht sicher, ob ich hier richtig meine Frage los werden kann ..

Ich überlege mir von XTC zu Oxid um zu steigen

Demo Installation habe ich soweit im Lokal noch hinbekommen, allerdings schwebt mir

die Gedanken, ob es möglich oder gar Erlaubt den Link und Logo von Oxid zu entfernen.

Im Falle daß man es nicht entfernen darf, wäre es möglich dies woanders zu plazieren?

zB. im Impressum ...

Vielen Dank im Vorraus

htaccess und apache mod rewrite

saschamarkuse — Wed, 01 Jul 2009 11:02:52 GMT

Hallo

Ich habe folgendes Problem.

Habe die Dateien von Oxid (CE-Edition) auf den Server kopiert, alles in eine Subdomain. Wenn ich jetzt das Setup aufrufe steht das Apache mod-rewrite-Modul auf rot.

Wo liegt denn wohl der Fehler? Help pls!

Grüße Sascha, der mal gerade keine Ahnung hat.

Database Publishing

toto99 — Wed, 01 Jul 2009 09:34:05 GMT

Hallo,
welche Möglichkeiten gibt es, oxid mit Database Publishing Systemen zu verbinden - also es sollten aus Quark XPress Layouts Informationen in die oxid Datenbank gebracht werden und auch wieder retour. Wer kennt einen Weg?

lg
Hubert

Firefox 3.5 und Oxid Admin

laramarco — Wed, 01 Jul 2009 03:45:22 GMT

Moin Moin

wollte gerade in meinem Admin bei den Spezifikationen Änderungen vornehmen, stelle fest, daß ich ein Attribut nicht anklicken kann.
Bin dann versuchsweise zum Reiter Crosssell. dort läßt sich auch nix anklicken. Mir erschleicht sich der Verdacht, Oxid ist NICHT Firefox 3.5 tauglich.

Kann das wer bestätigen und was ist die Lösung ??

Umsatz

funairliner — Tue, 30 Jun 2009 19:02:33 GMT

:mad:
Der OXID CE Shop macht in 3 Monaten den Umsatz was mein alter t-online epages Shop in einem Monat an Umsatz gemacht hat.
Große Frage!!! Was läuft beim Oxid CE Shop falsch?:eek::eek::eek:
Es kann ja nicht nur die Wirschaftskrise sein.

Preisalarm

funairliner — Tue, 30 Jun 2009 18:45:03 GMT

:eek:
Preisalarm Sinn oder Unsinn
sehe nicht wirklich einen Sinn dahinter
Besser wäre ein Preisvergleich wo den Usern eine Übersicht über einen bestimmten Artikel gegeben wird wobei andere Anbieter verglichen werden.
So ähnlich wie eine Preissuchmaschine.

Für Meinungen und Anregungen Dankbar.:)

Login admin funktioniert nicht mehr

funairliner — Tue, 30 Jun 2009 17:44:35 GMT

:mad:
Login admin funktioniert nicht mehr,
hat jemand die gleichen Probleme?
oder Lösungen

Abfrage Lieferart

walhalla — Tue, 30 Jun 2009 17:10:42 GMT

Hallo
Ich möchte beim Bestellabschluss (order.tpl) die ausgewählte Liefer-/Versandart abfragen ( beim Wechslen vom 3. in den 4. Bestellabschnitt). Welche Variable wir verwendet und wie wird die Info dort gespeichert, resp. wie kann ich den Inhalt vergleichen (Text, Zahl...)
Danke für Eure Hilfe
Shop: PE 4.

Pay Pal funktioniert nicht mehr

funairliner — Tue, 30 Jun 2009 16:50:07 GMT

:mad:
Pay Pal Bezahlung funktioniert nicht mehr
Hat jemand die gleichen Probleme / Lösungen?

Newsletter-Empfänger importieren

kathrin-77 — Tue, 30 Jun 2009 16:09:33 GMT

Hallo,

gibt es eine Möglichkeit bereits vorhandene Newsletter-Empfänger, die jedoch kein Kundenkonto im Shop haben, zu importieren?

Wenn ich das anhand der Datenbank richtig sehen, dann muss ein Newsletter-Empfänger auch mit einem Kundenkonto registriert sein, weil über diese user-ID (aus der oxuser) dann die Zuordnung zu der Newsletter-Benutzergruppe (oxobject2group) gemacht werden muss. Das heißt, eigentlich muss ich für jeden Newsletter-Empfänger einen Account anlegen, sehe ich das richtig? Ich müsste in der oxuser, oxnewssubscribed und in der oxobject2group etwas eintragen?

Gibt es da keine einfachere Handhabung?

Danke für eure Hinweise!

Viele Grüße,
Kathrin

Portlets PayPal wird künftig vom OXID eFire Shop-Connector abhängig sein - Verständnisfrage

laramarco — Tue, 30 Jun 2009 15:14:41 GMT

habe eben gerade ne Mail erhalten, daß "Portlets PayPal wird künftig vom OXID eFire Shop-Connector abhängig sein"

zum Verständnis meinerseits und vielleicht auch manch anderer:
- es sollte ja nicht vorkommen, aber es kann dennoch passieren (denke gerade an Weihnachten 2008) - was passiert wenn efire Server down ist, wer ist notfallsmäßig 24h erreichbar ?? welche "Gefahren" lauern noch ??

Gerade weil Paypal sehr gut genutzt wird, insbesondere halt auf der anderen Erdhalbkugel, interessieren mich diese Fragen doch und ich stells deshalb gleich hier öffentlich.

priceFrom

Medicus — Tue, 30 Jun 2009 14:35:56 GMT

Hallo
Suche mir gerade einen Wolf. Wo verd.. Hacke finde ich die tpl die den Preis ab beinhaltet. In der lang steht darunter ( priceFrom ).
Hat das schon jemand gefunden?

Hintergrund ist, das ich nachdem ich auf die 4.1.2 geupdatet habe der Preis ab plötzlich erscheint. Könnte das zwar aus der lang löschen,aber es erscheint bei ein paar produkt in der übersicht auch der preis 0,00. In der Deteil wird alles aber korrekt angezeigt. Ich habe auch keine Preise ab.

Hoffe mal auf Hilfe.

Wo finde ich Update auf 4.1.3

frickel — Tue, 30 Jun 2009 13:47:38 GMT

Ich würde gerne das Update auf 4.1.3 installieren. Wo kann ich das runter laden ? Ich finde nur die Vollversion. Vielleicht kann mir jemand mit einem Link helfen.

Artikellink über Artikel-ID ohne SEO

upaffrath — Tue, 30 Jun 2009 11:52:00 GMT

Hallo zusammen,

nachdem die große Arbeit getan ist (bin seit gestern mit der 4.1.2 online unter http://www.decowunder-tapeten.de), kommen jetzt die kleinen Nacharbeiten. Ich benötige Link-URLs auf die Artikeldetailseiten. Die kommen ja beim Artikelexport wunderbar raus:
.../index.php?force_cl=details&anid=xxxxx
Das Problem: das funktioniert nicht. Egal welche ID dort steht, man landet immer auf der Startseite. Dieser Effekt ist auch im Demoshop nachzuvollziehen.
Ist das möglicherweise ein Bug oder habe ich den Datenexport nur falsch interpretiert?

Gruß
Uwe

Weiße Seite nach Import

Ginchen — Tue, 30 Jun 2009 11:23:35 GMT

Hallöchen!

Ich will mal wieder das leidige Thema "Import" anschneiden. :)
(Ich hoffe, es wurde nicht schonmal gefragt, ich habe jedenfalls vorher gesucht.)

Nachdem ich die anfänglichen Probleme beim Import durch Erhöhung von PHP-Speicher und -Laufzeit in den Griff bekommen habe, kriege ich jetzt immer nur eine weiße Seite nach dem Import. Keine Meldung, wie viele Zeilen importiert wurden, keine Fehlermeldung, gar nichts.

In der Datenkbank sehe ich, daß ca. 550 von ~750 Zeilen importiert werden. Könnte sein, daß die restlichen aufgrund wilder Sonderzeichen o.ä. nicht funktionieren - aber wenn der Shop mir nicht einmal eine Meldung ausspuckt, dann weiß ich ja auch nicht, wo genau ich nach der Fehlerquelle suchen soll. :confused:

Hat jemand eine Idee, woran es liegen kann oder wie man dem Fehler auf die Spur kommen könnte?