PDF Invoice nach Update auf 4.8 fehlerhaft

Deutsches Forum
1

Hallo liebe Forenmitglieder,

ich habe vorhin ein Update (von 4.7.8 auf 4.8) eingespielt, alles ging ohne Probleme, bis ich die PDF-Funktion für Rechnungserstellung und Lieferschein ausprobierte.

Dort wurde meine Vorlage komplett zerrissen und statt den Werten, die in den Sprachdateien vorhanden sind, werden nur die Funktionsnamen ausgegeben.

Folgende Werte tauchen da z. B. auf:

ORDER_OVERVIEW_PDF_FILLONPAYMENT
ORDER_OVERVIEW_PDF_ORDERSFROM
ORDER_OVERVIEW_PDF_ORDERS
ORDER_OVERVIEW_PDF_ALLPRICENETTO
ORDER_OVERVIEW_PDF_ZZGLVAT19ORDER_OVERVIEW_PDF_PERCENTSUM
ORDER_OVERVIEW_PDF_ALLPRICEBRUTTO
ORDER_OVERVIEW_PDF_SHIPCOST
ORDER_OVERVIEW_PDF_ALLSUM
ORDER_OVERVIEW_PDF_SELPAYMENT

Hat jemand eine Idee, warum das auf einmal nicht mehr angezeigt wird, wie es soll?

Lieben Gruß
Jörg

2

Hallo

Schau mal die lang.php resp. map.php in application/views/azure/de an. Falls keine Einträge drin sind nimm die Dateien aus dem 4.7.8/9 Installationspaket…

LG Pasquale

3

Danke, ich probiere es :wink:

Alternativ werde ich die Werte in die cust_lang.php vom Admin schmeissen, das geht nämlich auch (gerade ausprobiert) :wink:

4

Ich habe das selbe Problem. Die ganzen Sprachelemente liegen ja eigentlich alle in der invoicepdf_lang.php.

Alles zusätzlich in cust_lang.php einzutragen bringt auch nichts.

Weiß da jemand vielleicht was neues?

5

Das Modul wurde verschoben von /modules/invoicepdf nach /modules/oe/invoicepdf. Das alte Modul in /modules/invoicepdf muss also gelöscht werden. Wenn man die Vorlage schon geändert hat kann man sie in /modules/oe/invoicepdf verschieben incl. der lang files und schauen ob’s dann geht.

6

[QUOTE=leofonic;136596]Das Modul wurde verschoben von /modules/invoicepdf nach /modules/oe/invoicepdf. Das alte Modul in /modules/invoicepdf muss also gelöscht werden. Wenn man die Vorlage schon geändert hat kann man sie in /modules/oe/invoicepdf verschieben incl. der lang files und schauen ob’s dann geht.[/QUOTE]
Hat geklappt danke. Hatte übersehen, dass der “alte” invoicepdf-Ordner noch vorhanden war :slight_smile:

7

[QUOTE=leofonic;136596]Das Modul wurde verschoben von /modules/invoicepdf nach /modules/oe/invoicepdf. Das alte Modul in /modules/invoicepdf muss also gelöscht werden. Wenn man die Vorlage schon geändert hat kann man sie in /modules/oe/invoicepdf verschieben incl. der lang files und schauen ob’s dann geht.[/QUOTE]

Hallo zusammen,
ich habe das gleiche Problem, komme aber leider auch mit dem Lösungsvorschlag nicht weiter. Baue gerade unseren Shop mit Ce 4.8.1 neu auf, der noch aktuelle ist in 4.7.1, da hatte ich die Rechnung entsprechend angepasst.

Wenn ich in dem frischen Shop jetzt die Rechnung generiere, fehlen nicht nur diverse Sprachvariablen sondern es verschiebt auch alles mögliche übereinander. Was mich wundert: Auch in der 4.8.1 ist der “alte” Modulordner /modules/invoicepdf noch vorhanden. Wenn ich diesen lösche, streikt das Modul (Modul kann nicht geladen werden".

Wenn ich die Rechnung erneut anpasse, würde ich das natürlich gerne an der richtigen Stelle tun, was nach meinem Verständnis in modules/oe/invoicepdf/myorder.php ist. Aber das macht ja nur Sinn wenn ich das alte Modul löschen kann. Habt ihr eine Idee, warum er das nicht zulässt? Habe ich etwas übersehen?

Danke vielmals!!

EDIT: Jetzt krieg ich das “Modul kann nicht geladen werden leider gar nicht mehr raus”, egal ob mit oder ohne altem invoicepdf Ordner :confused:

8

Führ mal das SQL aus:

DELETE
FROM oxconfig
WHERE OXVARNAME LIKE ‘aModulePaths’

9

wow - vielen Dank!! Das Modul lässt sich danach wieder aktivieren.

Allerdings scheinbar immer noch “das alte”. Wenn ich den alten Modulordner umbenenne und die Rechnung erzeuge heißt es das pdf sei beschädigt und im Backend heißt es dann wiederum “Modul kann nicht geladen werden”.

Wenn ich das sql erneut ausführe und den alten Ordner umbennen lässt sich das Modul zwar scheinbar aktivieren (die Schaltfläche ist vorhanden und kann gedrückt werden), es passiert jedoch nichts und es gibt keine pdf Ausgabe…

Wie bringe ich den Shop dazu, dass er merkt, das er das andere Modul nehmen muss? Der Shop wurde ursprünglich auf CE 4.7.8 installiert und dann auf 4.8.1 geupdated…

10

[QUOTE=Miri-am;137705]wow - vielen Dank!! [/QUOTE]

Hallo, das steht alles schon hier im Forum. Wenn du den Ordner umbenennst, musst das in der metadata ebenfalls angeben.

11

Ich hab ihn ja nur umbenannt um ihn “auszuschalten”. Ich kann ihn auch löschen, eigtl braucht es den alten Ordner ja nicht mehr. Das Ergebnis bleibt das gleiche, Modul kann dann nicht geladen werden obwohl der richtige Ordner im richtigen Verzeichnis vorhanden ist, inkl. lang files.

Ich scheine blind zu sein, aber es wäre super, wenn du mir einen Link schickst wenn das im Forum schon steht, ich habe nur diesen Thread gefunden der auf meine Probleme zu passen schien. vielen Dank schonmal!

12

In dieser Reihenfolge:

  • Modul deaktivieren
  • Modulordner im Rootverzeichnis löschen (umbenennen reicht nicht)
  • SQL ausführen
  • /tmp leeren
  • im Admin nochmal “Erweiterungen/Module” anklicken
  • falls Meldung erscheint ob Einträge gelöscht werden sollen: Ja
  • Modul aktivieren
13

http://forum.oxid-esales.com/search.php?searchid=2041915

daraus z.B. http://forum.oxid-esales.com/showthread.php?t=20667&highlight=Modul+entfernen

Ohne den Quelltext wird es, wenn es so nicht klappt, schwierig.

14

Das Modul ist nun aktiv, leider passiert aber nichts wenn man den “Rechnung ausgeben” Button drückt. Aber ich weiß, dass das schon oft Thema war und mach mich mal auf die Suche. Vielen Dank Frank, immerhin hab ich jetzt schonmal das richtige Modul am laufen :slight_smile:

15

DELETE
FROM oxconfig
WHERE OXVARNAME LIKE ‘aModulePaths’

[QUOTE=leofonic;137720]In dieser Reihenfolge:

  • Modul deaktivieren
  • Modulordner im Rootverzeichnis löschen (umbenennen reicht nicht)
  • SQL ausführen
  • /tmp leeren
  • im Admin nochmal “Erweiterungen/Module” anklicken
  • falls Meldung erscheint ob Einträge gelöscht werden sollen: Ja
  • Modul aktivieren[/QUOTE]

DANKE :smiley:
Ich hatte genau das gleiche Problem, aber damit hats anstandslos funktioniert. d:)b

16

Bei mir funktioniert es leider nicht. Ich habe das modul schon im richtigen Ordner, aber hatte früher auch mal invoice pfd direkt im modules-Ordner und bekam die Meldung, daß sich das Modul nicht aktivieren läßt.

Nach dem Ausführen von

DELETE FROM oxconfig WHERE OXVARNAME LIKE ‘aModulePaths’

ist leider der shop weg und auch das backend.

Die Debug in der Einstellung 8 meldet:

oxSystemComponentException—!–NOT CAUGHT–!–oxException (time: 2014-08-28 12:57:52): [0]: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND Stack Trace: #0 /var/www/ich/html/core/oxutilsobject.php(192): oxUtilsObject->_getObject(‘oxsystemcompone…’, 0, Array) #1 /var/www/ich/html/core/oxfunctions.php(382): oxUtilsObject->oxNew(‘oxSystemCompone…’) #2 /var/www/ich/html/core/oxutilsobject.php(182): oxNew() #3 /var/www/ich/html/core/oxfunctions.php(382): oxUtilsObject->oxNew(Array, Array) #4 /var/www/ich/html/modules/oe/oethemeswitcher/core/oethemeswitcherconfig.php(91): oxNew() #5 /var/www/ich/html/modules/oe/oethemeswitcher/core/oethemeswitcherconfig.php(62): oeThemeSwitcherConfig->oeThemeSwitcherGetThemeManager(‘oxSystemCompone…’) #6 /var/www/ich/html/modules/oe/oethemeswitcher/core/oethemeswitcherconfig.php(76): oeThemeSwitcherConfig->getConfigParam(‘oeThemeSwitcher…’) #7 /var/www/ich/html/modules/oe/oethemeswitcher/core/oethemeswitcherlang.php(124): oeThemeSwitcherConfig->oeThemeSwitcherGetActiveThemeId(Array, Array) #8 /var/www/ich/html/core/oxlang.php(988): oeThemeSwitcherLang->_getLangFileCacheName(‘oeThemeSwitcher…’) #9 /var/www/ich/html/core/oxlang.php(409): oxLang->_getLangTranslationArray() #10 /var/www/ich/html/application/models/oxmanufacturer.php(178): oxLang->translateString(‘sCustomTheme’) #11 /var/www/ich/html/application/models/oxmanufacturer.php(164): oxManufacturer->_setRootObjectData() #12 /var/www/ich/html/application/models/oxmanufacturerlist.php(126): oxManufacturer->load(false, 1, NULL) #13 /var/www/ich/html/application/components/oxcmp_categories.php(176): oxManufacturerList->buildManufacturerTree(1, false) #14 /var/ich/html/application/components/oxcmp_categories.php(78): oxcmp_categories->_loadManufacturerTree(‘BY_MANUFACTURER’, 1, false) #15 /var/www/ich/html/application/controllers/oxubase.php(606): oxcmp_categories->init() #16 /var/www/ich/html/core/oxshopcontrol.php(404): oxUBase->init(‘root’) #17 /var/www/ich/html/core/oxshopcontrol.php(337): oxShopControl->_initializeViewObject(‘manufacturerlis…’, NULL, ‘http://www…’) #18 /var/www/web1968/html/core/oxshopcontrol.php(636): oxShopControl->_process(NULL) #19 /var/www/ich/html/core/oxshopcontrol.php(125): oxShopControl->_handleSystemException() #20 /var/www/ich/html/core/oxid.php(38): oxShopControl->start() #21 /var/www/ich/html/index.php(27): OXID::run(‘exceptionError’, ‘displayExceptio…’, NULL, NULL) #22 {main} Faulty component –> oethemeswitcherthememanager

Hat jemand einen Rat?

17

In dem Fall kann man mit
DELETE FROM oxconfig WHERE OXVARNAME LIKE '%module%'
alle Module zurücksetzen und danach im Backend wieder einschalten (Einstellungen der Module bleiben erhalten).

18

Yippie Yeah! Geht wieder!