Hallo,

wir wollen bald die 3.0 beta herausbringen.
Wir wären den Anwendern sehr dankbar, wenn jeder nochmal die zwei wichtigsten Punkte posten würde, die aus seiner Sicht in eine Version 3.0 hineingehören würden.
Wir möchten einfach feststellen, ob wir auf dem richtigen Weg sind und evtl. vergessenes noch nachholen.

Vielen Dank
hop

Hallo,

also für mich wäre das schönste Geschenk eine  "suchen/ersetzen" Funktion auch für Varianten
(dieser Wunsch ist nicht ganz neu, aber ich schreib das halt mal so hin - ohne viel Hoffnung, das es realisierbar ist..... ;))

ansonsten im Moment "wunschlos glücklich" mit den neuen Funktionen, die es geben wird  ;D

P.S.: doch noch etwas eingefallen - eine Möglichkeit, eigene Funktionen in benutzerdefinierte Formulare einzubauen, wäre schön.
Gehört aber genaugenmmen zum VisualForms-Modul

Hallo SP-user!
Was ist los mit euch? - keiner eine Idee (Vorschläge/Wünsche)?

... wenn niemand Vorschläge macht, dann darf aber auch keiner im Nachhinein "meckern"  ;)

also mir ist jedenfalls gerade noch ein kleiner Wunsch eingefallen:
ich hätte gerne eine "weitere Seiten" Funktion für Varianten - bzw. das "x Artikel pro Seite anzeigen" auch für Varianten.

Problem dabei: Varianten können ja nicht mit <!--spmacro:loopitem--> ausgegeben werden.
Es müßte da also eine ganz anderes aufgebaute "weitere Seiten" - Funktion geben und bei "x Varianten pro Seite anzeigen" sollten (genauso wie bei den Artikeln) auch nicht die Variantenanzahl sondern die Zeilenanzahl eingetragen werden können, bzw. wahlweise nicht auf allen Seiten, sondern nur dort wo es sinnvoll ist.
(aber machbar ist doch alles  ;D -> wenn man's kann.... nur ich kann's nicht - zumindest nicht alleine....)

nachdem ich SEHR viel mit Varianten arbeite, wäre ein Ausbau der Varianten-Funktionen für mich sehr hilfreich
= das man generell da die selben Möglichkeiten wie bei Artikeln hat

Hallo,

@dobra
> Was ist los mit euch? - keiner eine Idee (Vorschläge/Wünsche)?
Nicht so hektisch, wir sind ja dran - wir haben viele Wünsche... ;)

Ich habe unsere 'alte' Wunschliste hier im Forum aktualisiert. Guckst du hier:
http://www.shoppilot.net/pf/empty-t362.0.html;msg1448#msg1448

Unser Programmierer schreibt zum Thema Beta 3.0 in den nächsten Tagen auch noch etwas...

Grüße, jg

www.schmuckzone.de

Hallo,

da wäre schon einiges zu nennen:

- Kundenspezifische Festpreise, um nicht für jeden Kunden komplette Subkataloge anlegen zu müssen. Rabatte nützen leider nichts, da die Preisvereinbarung nicht zeitidentisch mit einer Listenpreisänderung ist und die Warenwirtschaft und die dazugehörige Preis- und Vertragsdatenbank für die Preise die Masterfunktion hat. Der Shop ist nur "ausführendes Organ".

- individuelle Nummerierung der Informationsseiten und der Formulare - innerhalb der Nummernbereiche -, damit man Code aus anderen Shops ohne Änderung weiternutzen kann.

- Brutto- und Nettoverpreisung in einem Shop - ohne für jede Preisart andere Vorlagen bauen zu müssen (evtl. pro Subkatalog einstellbar), ein Identifier ob es sich um Brutto- oder Nettopreis handelt. (Ich weiss, Haken im Händler und Benutzerdefiniertes Feld... aber was ist, wenn dummerweise mal Haken und Feld nicht zusammenpassen?)

- für den Unternehmenskundenbereich, leider für uns inzwischen sehr wichtig:
- Kundenverwaltung für einen Kundenbereich durch einen Kundenadmin (Einkäufer kann die Besteller aus seinem Haus anlegen und verwalten)
- mehrstufiges Bestellverfahren (Einkäufer muss Bestellungen der unterstellten Besteller freigeben bzw verändern können)
- Weitergabe von Warenkörben 
- Umsatzauswertung extern (Einkäufer kann die Bestellung der unterstellten Besteller einsehen und auswerten)

Viele Grüße
Emil

Hallo,

hätte da noch einen Wunsch nach einer (alternativen oder zusätzlichen) "Volltextsuche"
=> es wäre schön, wenn man (auch! - nicht nur - "unsichtbare" Felder müssen so wie jetzt bleiben) den kompletten Text einer HTML-Seite - auch Infoseiten (z.B. Hilfeseiten) durchsuchen könnte.

Habe schon vor längerem versucht, soetwas in "Eigenbau" zu improvisieren, hab's dann aber aufgegeben da ich damit keinen Schritt weitergekommen bin.

Ideal (für mich - weiß nicht, ob das von allgemeinem Interesse ist) wäre es auch, gezielt einzelne Seiten (nicht nur Kategorien mit allen Unterseiten) von der Suche ausschließen könnte.
auch die Möglichkeit externe Seiten (2. Shopprojekt) in die Suche eizubeziehen wäre schön.
hatte das mal in einem externen Suchprogramm daß aber nur statische Seiten durchsucht (also keine "unsichtbaren" Felder) und nicht integrierbar ist, da es dann die Suchergebnisse natürlich auch zu den statischen Seiten verlinkt - und auch sonst bei weitem nicht an die SP-Suchmöglichkeiten herankommt

Hallo,

ich habe noch 2 neue Wünsche - Punkte 13 und 14 - eingefügt:
http://www.shoppilot.net/pf/empty-t362.0.html;msg1448#msg1448

jg

Hallo jg

die Lösung für Punkt 13 gibts hier
http://www.shoppilot.net/pf/ssp_bibliothek/nach_login_auf_ausgangsseite_zurueck-t939.0.html
(läuft bei mir seit ca 1 Jahr problemlos und fehlerfrei (auch mit der neuen MD-Lizenz)

zu Punkt 14:
Das geht leider nicht. Wenn der erste Identifier zum zweiten mal auftaucht, wird davon ausgegangen, dass ein neuer Artikel anfängt. Wenn wir diese Logik nicht hätten, müssten wir vorschreiben in welcher Reihenfolge Identifier zu benutzen sind.

Es gibt jedoch eine ein einfache Lösung. Man mancht sich einen SSP-Identifier, der dann den Rückgabewert $ssp::noinc hat.
Dann wird bei diesem Identifier der Artikelzähler auch bei mehrfachem Auftauchen nicht erhöht.

Gruss hop

@dobra:
Danke für den Link. Funktioniert das bei dir von allen Seiten kommend?
Soweit wir wissen lässt sich nicht jede Seite mit ssp::get_var_form('seite') auslesen.
Natürlich kann man in SP mit Perl und SSP mittlerweile vieles Umsetzen,
was jedoch für den 'normalen Shoppilot-Benutzer' nicht oder eher schwierig
machbar ist.

@admin:
> Es gibt jedoch eine einfache Lösung. Man mancht sich einen SSP-Identifier,
> der dann den Rückgabewert $ssp::noinc hat.
Damit arbeiteten wir bereits viel. Das funktioniert u.M.n. aber nicht in jedem Fall -
je nach 'Code-Konstellation'... Deswegen die direkten SQL-Abfragen.
Habe Punkt 14 wieder entfernt.

Leider habe ich jetzt eben erst gelesen, dass ich nur die 'zwei wichtigsten Punkte'
posten sollte. Sorry, wenn unsere Liste länger geworden ist. Trau' mich jetzt gar nicht,
noch mehr zu schreiben...
:(

jg

Hallo jg,

ja - es funktioniert auf allen Seiten
kannst ja mal testen  ;)
http://www.woll-insel.at/cgi-bin/shop2/iboshop.cgi?show0
(test/test)

P.S.:
nach neuem Sicherheitstandard sollte die ssp::get_var_form Abfrage so geändert sein:
ssp::qform(ssp::get_var_form('seite'));
...

Hallo dobra,

... zusammen mit 'pagetype' läuft das, alles klar.
Danke für deine Hinweise.

jg

Hallo - ich auch mal was......

Es wäre super, wenn man unterschiedliche Suchergebnissseiten definieren könnte
(bei uns z.B. für die Reifensuche und zusätzlich für die allgemeine Shopsuche ..)

Suchmaschinentauglichkeit (nur mal ne Frage):
Ich weiß, das IBO am Staticbuilder hängt - aber aufgrund der recht hohen Anforderungen...
... könnte man nicht (zusätzlich) auch noch mal über den Tellerrand schauen ... (nicht gleich hauen...)
Viele Shopsysteme schreiben die URLs für Suchmaschinen um (so als Laie mal gesagt) - gibt es
denn nicht hier auch Entwicklungsmöglichkeiten ?

Grüße von ANDI

Hallo,

falls ich noch einen Wunsch "nachreichen" darf .....
ich würde dringend eine 3. e-mail Adresse/Vorlage für Bestellungen brauchen
idealerweise auch mit eigenem "Betreff"

1.) Bestellung für mich (und Partnerfirma - hier brauche ich Zusatzinfos, die den Kunden aber nichts angehen)
2.) Rechnung (wird gedruckt und der Lieferung beigelegt nachdem ich die Bestelldatenvorlage aus den WC nicht als Attachment versenden kann)
3.) Bestellung = für den Kunden bei manueller Auftragsbestätigung bzw. Versandaviso

bei der automatischen Auftragsbestätigung nach abgesendeter Bestellung erhält der Kunde nur

ZitatDanke für Ihre Bestellung.
Sie erhalten die Auftragsbestätigung
sowie eine Kopie Ihrer Bestellung
in Kürze per mail an __eMail__

und die tatsächliche Auftragsbestätigung manuell, da oft individuelle Mitteilungen notwendig sind

Hallo,

ich bin zwar etwas zu spät mit meinen Wünschen, jedoch wollte ich
noch ein paar Vorschläge für zukünftige Versionen machen.

Die Änderungen in der 3.0 Beta gefallen übrigens mir schon sehr gut.

Hier nun meine Liste (ist hoffe ich nicht zu lang):

-----------------------------------------------------------------------
| Wünsche und Änderungen für ShopPilot 3.xx.xx: |
-----------------------------------------------------------------------

Fehlerkorrekturen:
-------------------

- Zahlungsart ändern:
  -------------------
  Im Shoppilot-WC werden Änderungen richtig übernommen -
  jedoch nicht immer ins Web übertragen. Derzeit kann als
  Lösung dieses Problemes nur die Zahlungsart in "MERPAY"
  manuell hinterlegt oder die DB neu angelegt werden.


- Löschungen von Kunden und Händlern:
  -----------------------------------
  Es werden nicht immer alte Datenbestände in der MySQL gelöscht.
  Im lokalen Shop sind die Datensätze raus, online jedoch sind
  noch Daten in der MySQL-DB vorhanden und verursachen so Probleme.

- Händler bearbeiten/anlegen
  ---------------------------
  Beispiel: Ein Händler wird neu angelegt und man trägt in Registerkarte
  'Händler' die Domain einträgt. Diese wird kopiert, um sie in der
  Registerkarte 'Benutzerdefiniert' bei 'XDOMAIN' einzutragen.
  Änderungen in der Karte 'Händler' sind dann leider verschwunden,
  wenn nicht 'Übernehmen' geklickt wurde. Hier wäre es schön,
  wenn die Daten auch ohne zu 'übernehmen' bestehen bleiben.
  Auch wäre es nicht schlecht, wenn in der Händlerbearbeitung das
  'Übernehmen' mit SRTG+S oder ähnlich funktionieren würde.


Wünsche (Allgemein):
-------------------

- Pro Händler separater Mehrwertsteuersatz
  ----------------------------------------
  Filialshops für Händler aus anderen Ländern müssen wir bisher
  leider ablehnen, da keine unterschiedlichen MwSt-Sätze je HÄNDLER
  definiert werden können.

- Feld für eindeutigen URL-Sicheren Titel (Alias-Feld):
  ------------------------------------------------------
  Dieses Feld könnte den Seitentitel in URL-sicherer Form beinhalten
  (z.B. "Mein_schoener_Seitentitel").
  Wir nutzen zum Aufruf von Seiten 'showbyname' und ModeRewrite.
  Da 'showbyname' aber den Titel abfragt und dieser nicht URL-sicher ist,
  muss man improvisieren und den Titel in ein anderes Feld schreiben
  (Hinweis: wir haben auch schwedische und französische Titel).
  Anstelle des Titels schreiben wir jetzt den URL-sicheren Titel.

  So ein Feld wäre vielleicht auch für den StaticBuilder interessant,
  da Sonderzeichen und Umlaute in diesem Feld nicht erlaubt wären
  und somit auch nichts kompliziert per Sript umgewandelt werden muss.
 
  Aufrufen könnte man das Feld z.B. mit 'showbylabel'. showbyname sollte
  wegen intensiver Nutzung weiter so verwendet werden.
  Kunden könnten dann auch Einfluss auf die Seitenbenennung nehmen.

  Ich kenne diese Lösung aus einigen CMS (z.B. SIXCms), dort heißt das
  Feld 'label' und erfüllt genau diesen Zweck.

- Felder für Metadaten
  ---------------------
  Um in den Suchmaschinen weiter nach vorn zu kommen, haben wir aus den
  Titeln und einigen anderen Artikelangaben sowie aus Seitenbeschreibungen
  Meta-Keywords und Meta-Descriptions erstellt. Das ist aber für Kunden
  ohne Programmierkenntnisse nicht möglich.
  Auch hier wäre eine einfachere und flexiblere Lösung nützlich.
  2 Felder wären ideal: Keywords und Description, speziell bei den Seiten,
  wo keine benutzerdefinierten Felder möglich sind.

  Vielleicht sind aber auch benutzerdefinierte Felder bei Seiten
  von allgemeinem Interesse?


- Der Katalog als Auflistung und nicht nur als Linksammlung
  ----------------------------------------------------------
  Der Platzhalter '__katalog__' erzeugt nur nomale Links.
  Hier wäre es für Seitenstruktur und für Suchmaschinen besser,
  wenn der Katalog in Form von Auflistungen dargestellt wird.
  Barrierefreie HTML/XHTML-Seiten bevorzugen zusätzlich auch noch
  ein "title-Attribut".
 
 
  <ul>
   <li><a href="meine_Seite1.htm" title="Link 1">Link 1</a></li>
   <li><a href="meine_Seite2.htm" title="Link 2">Link 2</a>
     <ul>
       <li><a href="meine_unterSeite1.htm" title="Unter-Link 1">Unter-Link 1</a></li>
       ...
     </ul>
   </li>
   <li><a href="meine_Seite3.htm" title="Link 3">Link 3</a></li>
   ...
  </ul>
 

  Wir haben unseren 'Katalog' so programmiert und auf den SP-Platzhalter
  verzichtet. Vorschlag: 2 Möglichkeiten der Darstellung für den 'Katalog':
  Darstellung als einfache Links (wie jetzt) oder in Form einer Auflistung
  (wie oben).
   


Wünsche (SSP-Programmierung):
------------------------------

- SSP-Variablen in allen Seiten/Templates verfügbar machen
  --------------------------------------------------------
  Zum Beispiel ist die "pageid", die wir zur Abfrage von aktiven Menüs brauchen,
  nicht in allen Seiten verfügbar. Einige Seiten haben wohl gar keine Nummern.
  Auf unserer Loginseite (Menüpunkt Login ist 'aktiv') wird z.B. nach dem
  Absenden der Logindaten keine 'pageid' übermittelt.
  Hat ein Kunde einen falschen Login eingegeben, bekommt er eine Fehlermeldung
  und wieder das Formular. Das Menü ist jedoch nicht mehr aktiv,
  da die 'pageid' angeblich '0' ist.  ??

  Dieses Phänomen ist auch im Warenkorb so. Im Warenkorb habe ich das
  Problem jedoch mit 'pagetype' gelöst, um das Menü aktiv zu halten.

  Mein Wunsch wäre daher:
  ALLE Variablen (außer Artikel- und warenkorbspezifische Variablen)
  auf allen Seiten wie Fehler-, Bestell- und Warenkorbseiten,
  sowie in allen E-Mail-Templates verfügbar zu machen.

Gruß
mt