node/add/ in 2 Formulare splitten?

Eine Idee hätte ich, allerdings nicht getestet:
Vielleicht kannst du in die Links je eine Variable reinpacken, die per https://drupal.org/project/prepopulate
ein Auswahlfeld kaufen oder mieten vorab ankreuzt und die Darstellung aller jeweils benötigten Felder mit https://drupal.org/project/field-conditional-state an die Auswahlbedingung binden.

Beste Grüße
Marco

Hallo Marco,

vielen Dank, prepopulate guck ich mir an. Bei field-conditional-state ist leider das Problem das es mir im Formular die Open Layer Karte rauswirft und ebenso das Taxonomy Menu für Orte, dafür nutze ich https://drupal.org/project/shs und auf shs will ich auf keinen Fall verzichten, da es super funktioniert für meine Taxo Auswahl.

Würde field-conditional-state funktionieren bräuchte ich diesen Aufwand mit zwei node/add gar nicht, habe auch schon conditional fields getestet, dieses macht Probleme mit node clone, was ich auch dringend brauche.

Manchmal ist es wie verhext, ich hatte mit conditional fields alle Einstellungen perfekt, Checkbox Miete fährt alle Felder für Miete aus und bei Kauf ebenso, bei node clone können die Werte dann leider nicht sinnvoll geändert werden, erst nach 3 x öffnen, leer speichen, neu öffnen usw., das kapiert keiner....

Daher meine Idee die Formulare zu splitten, das muß dann ohne eines dieser beiden Module geschehen.

Viele Grüße Jenna

Hmm, also ich meine, dass man mit dem Pagemanager auch edit-Seiten gestalten kann (habe es selber aber noch nicht gebraucht).
Vgl. dazu das Tutorial von nodeone.se.
Ev. könntest Du also zwei Varianten davon machen und auch unterschiedlich aufrufen...

Danke Leda, ich habe den noch nie benutzt, werde das aber gleich heute abend testen, an den hab ich gar nicht gedacht, gut möglich...

Grüße Jenna

Ok, dumm wenn die Module nicht zusammenspielen. Lass uns bitte wissen, wenn du das mit dem Pagemanager umsetzen kannst.

So, habe die Nacht mit Panels und PageManager verbracht (hatte das mal auf einer Drupal 6 und vollkommen vergessen) und es funktioniert damit auch wie gewünscht.
Nur ist das Ganze für meinen kleinen Fall ein echter Overkill und ich will diese mächtigen Module dazu nicht benutzen.

Habe eben diesen Thread gefunden und denke das kommt genau in meine Richtung: https://drupal.org/comment/6952636#comment-6952636

Grüße Jenna

Danke für den "Test". Für mich persönlich ist es jedenfalls interessant zu wissen, dass es so ginge.
Ich hatte mal einen ähnlichen Fall wie Du, aber da habe ich in der Edit-Maske die Doppelspur in Kauf genommen und optisch die Felder wenigstens in zwei Fieldgroups gesteckt, zum Auf- und Zuklappen. Dafür war dann die Ausgabe mit Templates mehr sophisticated...

Hallo leda,

für deinen Fall könntest du, falls du da noch optimieren willst, ja mal conditional fields ansehen, das Modul funktioniert super, Felder in Abhängigkeiten anzeigen und vieles mehr, läuft auch mit fieldgroups.

Ich habe lediglich ein Problem im Zusammenspiel mit node clone, aber ansonsten würde ich conditional fields sofort einsetzen, anstatt den grossen Weg über panels etc.
Bleibe aber da dran, und schreibe das auch in die Issues, wäre schon die schönste Endlösung.

Momentan löse ich das genauso wie du, Fieldgroups Accordion und CSS gebastel, der Vorteil bei conditional fields ist eben, das verkehrte Eingaben nicht mehr möglich sind.

Grüße Jenna

zwei content_types anzulegen - einen für Verkäufe und einen für Vermietungen.

Dann sind das auch zwei unterschiedliche Eingabemasken und zwei unterschiedliche Edit-Pfade.

Mit einer View lassen sie sich dennoch, soweit dies erforderlich sein sollte, in eine Liste packen.

Dann funktioniert es aber nicht mit node clone, der Sinn hinter einem ContentType ist, das eine vorhandene Node kopiert werden kann, da Objekte sowohl zum Verkauf als auch zur Vermietung stehen können.

Viele Grüße
Jenna

würde ich keinen Clone erzeugen, sondern eine Referenz setzen.

Artikel, die vermietet sind, haben die Eigenschaft, dass sie hinterher gebraucht zurückkommen, und entweder wieder vermietet werden können, oder billiger verkauft werden.

Deshalb wäre es doch sinnvoll, für beide Fälle die Preise zu hinterlegen, und den eigentlichen Vorgang in einem eigenen content_type zu führen, der eine Referenz auf das Original enthält, und den passenden Preis anzeigen kann.