Beiträge von paulchen

ps: der shop bringt auch eine warnmeldung, wenn die configure-files auf 440 oder 400 stehen und behauptet er hätte schreibrechte, was jedoch nicht stimmt. er erkennt einzig und allein, dass chmod ungleich 444 ist. das ist alles.

prinzipiell wäre hier ein eingehendes studium mit benutzerechten unter *ix-system für dich interessant.

diese sind folgendermaßen gruppiert: rwxrwxrwx
das 1. "rwx" betrifft den besitzer der datei (respektive eigentümer oder auch ersteller - das läßt sich mit chown ändern), das 2. die gruppe, welcher der besitzer angehört und das 3. den rest der welt.

r=read
w=write
x=execute

die sitemap.xml beinhaltet lediglich die sitemap. sie hat 777, da sie vom shop erstellt werden muss und jeder soll sie auch lesen können - sonst ist das ganze sinnlos. theoretisch könnte auch ein 744 oder 755 reichen oder gar ein 644, was aber eigentlich irrelevant ist.

die wichtigsten sicherheitsrelevanten punkte sind: die 4 configure-dateien nur lesbar einrichten (im "ungünstigsten" fall chmod 444), da sie die zugangsdaten zur datenbank beinhalten.
man kann die configure-dateien auch auf 777 setzen und das macht trotzdem nix. vorerst! da die configs eine php-endung haben und nicht im klar- btw. quelltext downloadbar sind. ES SEI DENN, man hat eine php-shell mittels joomla oder auch diesem shop installiert und liest nun die configs aus. das würde leider theoretisch auch bei chmod 400 funktionieren.

der punkt ist einzig der, dass bei chmod 444 oder restriktiver der SHOP als risiko, nach jetzigem kenntnisstand, ausgeschlossen wird.

zu deinem server: welche rechte für php-dateien nötig sind, kommt einzig auf deine system-konfiguration an: unter welchen rechten läuft dein php-parser und der apache?
wenn du es nicht weißt, musst du es testen -> einfach mal die index.php auf chmod 400 setzen (bei mir läuft der shop auch so ;)) wenn das nicht geht, 440, dann 444 etc. dateien/ordner die der shop erstellt/ändert brauchen schreibrechte. beim testen jeweils vorher immer den cache leeren (shop + browser <-da am besten direkt ausschalten-wenigstens temporär)

chmod wird interessanter, wenn sich ANDERE user auf deiner maschine befinden, sowie bei statischen inhalten.

das EIGENTLICHE sicherheitsrisiko ist ein schreibzugriff auf den server (via ftp, ssh, telnet, php inkl. skripte [in deinem fall das joomla-modul] etc.)

was kann man tun? immer die aktuellsten sicherheitsupdates einspielen (d.h. NICHT immer die aktuellste softwareversion), statt ftp sftp o.ä. verwenden etc.

konfiguration->meta-tags / suchmaschinen

und bei den einzelnen produkten.

"leider" sind die meta-tags heute nicht mehr sehr interessant, bzw. werden von google wahrscheinlich sogar ignoriert. wie es bei anderen suchmaschinen aussieht weiß ich nicht.

vielen dank für die info! funktioniert einwandfrei.

edit: kommando zurück! die alte version war noch im cache.
die von dir geposteten änderungen zeigten keine wirkung.

deine verwendeten begriffe sind nicht aussagekräftig.

windows ist ein betriebssystem.
da KANN man als WEBSERVER den IIS einsetzen oder auch den apachen. htaccess ist nur für apache interessant.

http://faq.commerce-seo.de/content/8/84/d…-webserver.html

wie seht denn der "hackerangriff" auf dem webspace aus? klingt wie ftp-passwort ausgespäht, oder? da würde auch kein chmod 000 helfen.

und wohin zeigt der graphik-link in der mail?

prinzipiell wäre es vorteilhaft, wenn du einen neuen thread aufmachst. damit ist der nachwelt besser geholfen.

html enthält genau so ascii-code wie utf-8. ich kenne auch keinen, der seine dateien direkt binär erstellt/ändert. an deiner stelle würde ich mich erst einmal um eine valide grundfunktionialität des shops kümmern, wozu korrekte umlaute gehören, anstatt an optischen nebensächlichkeiten zu basteln.

manche grafiken (z.b. buttons) werden, wie es scheint, von einem script erstellt, dessen anweisungen mit an sicherheit grenzender wahrscheinlichkeit vom aktuellen template kommen und manche befinden sich direkt im template-ordner.

vielleicht weiß keiner was du meinst. da schließe ich mich direkt ein.
was ist edito?

deine keywords trägst du im admin-backend ein.

ich habe die von sikiera gepostete änderung eingefügt und es funktioniert (bis auf einschränkungen bei den versandkosten).

gleiche vorgehensweise, wie bei dir:
-artikel kaufen
-bestellung ändern-> weitere artikel einfügen -> evtl. optionen einfügen -> funktioniert. summe + USt stimmen!

die änderung der versandkosten funktioniert nicht wie vorgesehen. d.h. eine änderung der versandart kann ich nicht vornehmen, da keine alternativen im dropdown-menü erscheinen.
eine preisänderung der aktuellen versandart funktioniert ebenfalls nicht. wenn ich den neuen preis eingebe, wird dieser nicht übernommen bzw. noch etwas kurioser: nach klick auf "speichern" unter "versandart" erscheint ein weißes fenster und es geht nicht weiter.

was tun? ich editiere unten in der zusammenfassung. dort kann ich alles ändern.

nach der gesamtspeicherung stimmen dann alle summen und auch die USt.

damit kann ich leben, was aber auch damit zusammenhängt, dass ich in der praxis noch nie eine bestellung editieren musste
andere fehler sind für mich "gravierender", welche aber vielleicht bereits im fix behoben sind.

falls kategorien per csv importiert werden sollen, kann dazu nicht das shop-backend dienen, sondern direkt mysql oder z.b. phpmyadmin.

hierzu sind die beiden tabellen categories und categories_description relevant.

sonst kategorien direkt im shop manuell anlegen.

wie importierst du dein artikel bzw. kategorien bis jetzt?

der shop ist von haus aus utf-8-fähig.

deine datenbank muss natürlich VOR dem installieren des shops in UTF-8 angelegt/konvertiert werden.

beim speichern (z.b. in oo-calc) einfach als csv-file in utf-8. damit ist die sache erledigt.
falls du viele semikola, anführungszeichen etc. im text hast, kannst du den spaltentrenner noch ändern. ansonsten ist es sinnvoll diesen auf SEMIKOLON zu stellen.

ich habe mir die datei nicht angeschaut, aber umlaute lassen sich problemlos im- und exportieren.

ist ein semikolon im text enthalten, wird das, wie schon geschrieben als neue spalte interpretiert. dem kann man vielleicht mit vorangestelltem backslash abhelfen (bei ") funktioniert das jedenfalls.

sonst kann man auch anderen spaltentrenner wählen, welche garantiert nicht im text vorkommen, z.b. raute# o.ä.

als utf-8 speichern ist natürlich immer pflicht. das läßt sich explizit einstellen.

in zone 1 countries folgendes einfügen: DE
in die darunter liegende shipping table dann deine werte wie bereits geschrieben: 0.5:1.65,2:4.10,10:6.90,20:11.90,31:13.90

die nachfolgenden zeilen dann freilassen bzw. freimachen.

ja. verhält sich bei mir genau so. die erste sache ergibt sich aus deinem langen artikelname. da sollte aber einer bestimmten breite ein zeilenumbruch erzwungen werden.

wäre also ein fall für den bugtracker.

ein escape ist eigentlich nur ein zeilenumbruch.
der fehler kann auch einfach nur dadurch entstehen, dass die text-datei mit einem programm geöffnet wird (aus welchem dann kopiert wird), welche die umbrüche nicht korrekt interpretiert.

Zitat von datenknecht

Hi Leute,

locker bleiben und das Fixpack nach dem release erstmal 1 Woche abkühlen lassen.
Sicher ist sicher...

Grüße
Datenknecht

ja, und wer soll das ganze beta-testen, wenn nicht du?

der eintrag ist eigentlich korrekt.

ich habe jedoch statt der tabellarischen versandkosten das deutsche-post-modul verwendet. das funktioniert einwandfrei.

die struktur der tabellen läßt sich mittels "reverse engineering" leicht herausfinden.
wenn noch nicht geschehen, einige produkte vollständig anlegen und danach folgende tabellen, am besten im csv-format, aus der datenbank exportieren:

categories
categories_description
products
products_attributes
products_description
products_images
products_options
products_options_values
products_options_values_to_products_options
products_to_categories
tag_to_product

auf grund der daraus gewonnenen erkenntnisse ergibt sich alles weitere. wenn nicht - jemanden damit beauftragen.

achtung - alles in utf-8 formatieren!