Software kant en klare websites t.b.v. webwinkels?

[Eucalypta]

Wij hebben een website voor een webshop. Momenteel loopt deze over Joomla...maar we zijn op zoek naar andere mogelijkheden omdat wij telkens een webdeveloper nodig hebben voor de aanpassingen en dit loopt nogal in de papieren.

Nu zijn er 'kant en klare' websites te vinden zoals bv Jouwweb...maar deze heeft niet z'n mooie uitstraling en kent zijn beperkingen.

Wix.com heeft daarentegen wel hele mooie versies maar daar krijg je een # in je URL (ook bij betaling). Daarbij is het een .com waar wij op zoek zijn naar een .nl domein

Wij zijn dus op zoek naar zoiets met de uitstraling van Wix.com maar met mogelijkheid tot het uploaden van behoorlijk wat bestanden en dan uiteraard met een schoon .nl domein.

Kunnen jullie tips geven?

Bvd

 

[verandering: titel]

[Richard Theuws]

<3 voor deze discussie in een topic over SaaS oplossingen :)

[jochem8]

Een template kun je zien als dit, bijvoorbeeld:

{{PageTitle}}

Hier wordt de code {{PageTitle}} door het CMS vervangen door de daadwerelijke titel van de pagina.

 

De HTML staat dus in de template, de variabele gegevens, zoals de content, de menu's, etcetera worden in de HTML van het template ingevuld door de {{}} variabelen in dit voorbeeld te vervangen door de achterliggende waardes:

 

</pre>
<ul>
{{Menu.title}}
</ul>
<br><div>
{{Content.title}}
   {{Content.body}}
</div

 

Natuurlijk bepaalt het CMS wel wat er uitgepoept wordt qua code...

Bij een goed CMS dus niet...

 

 

 

In een WordPress template is het:

<?php the_title(); ?>

 

De functieaanroep 'the_title();' is PHP code van het CMS dus PHP / CMS poept de HTML uit :P Semantisch geneuzel...

 

Bedankt voor de toelichting Willem. Ik begon al aan mezelf te twijfelen (nooit doen!) maar het CMS bepaalt dus wel wat en hoe er wat wordt uitgepoept.

[R.I.P. | Peter Bonjernoor]

*zucht*

 

Het CMS plakt de template en de content samen tot een pagina, dus in die zin wel. Echter, de kwaliteit van de HTML komt uit de template, en wordt niet door het CMS bepaald. Is het nou echt zo moeilijk dat te snappen?

 

En de consequentie is dat het te kort door de bocht is door te zeggen dat Joomla altijd mooie HTML oplevert - het zal meestal wel zo zijn, maar dat komt dan doordat er een goed template achter zit.

 

Da's alles wat ik wilde verduidelijken, meer niet.

[jochem8]

Dan zijn we het daar dus over eens.

 

Je definitie over "goed CMS" is ook wat vaag. Kun je dat toelichten? Want een "goed CMS" hangt niet alleen af van welke code er wordt gegenereerd.

[Ward van der Put]

Ik vraag mij ondertussen af of de TS, die nu juist van developer-beslommeringen af wil, wel geholpen is met technische bespiegelingen over de werking en syntaxis van templates, template engines en well formed HTML — hoe goed bedoeld die ook mogen zijn.

 

De huidige opzet voldoet niet voor de TS en daarin zal een ander Joomla-template of een overstap naar WordPress vermoedelijk onvoldoende verbetering brengen. De TS vraagt om een kant-en-klare oplossing en, hoewel je bij zulke oplossingen ook kwalitatieve vraagtekens kunt zetten, vallen zowel Joomla als WordPress dan zeker af. Daar moeten namelijk vroeg of laat toch weer een webdeveloper en een webdesigner aan te pas komen.

 

Los daarvan lijkt HL me niet de plek voor zo'n vakinhoudelijke discussie. Zou die over de werking van raketmotoren gaan, dan had er al een slotje aan gehangen, maar gaat het over template engines, dan kabbelt de welles-nietesdiscussie maar voort.

[R.I.P. | Peter Bonjernoor]

Dan zijn we het daar dus over eens.

Eindelijk!

 

Je definitie over "goed CMS" is ook wat vaag. Kun je dat toelichten?

In deze context bedoel ik daarmee een CMS dat (zo goed als) volledig afhankelijk is van templates, en waar dus geen HTML in de CMS-code voorkomt.

 

Ik vraag mij ondertussen af of de TS, die nu juist van developer-beslommeringen af wil, wel geholpen is met technische bespiegelingen over de werking en syntaxis van templates, template engines en well formed HTML — hoe goed bedoeld die ook mogen zijn.

Mee eens, ik wilde alleen maar een kleine nuance aanbrengen, maar die ging helaas in eerste instanties verloren.

 

[J S]

In deze context bedoel ik daarmee een CMS dat (zo goed als) volledig afhankelijk is van templates, en waar dus geen HTML in de CMS-code voorkomt.

 

Wat een onzin, bijna elk CMS genereert HTML code, simpelweg de vervangen door "CMS-code"

 

Wordpress gaat hier erg ver in, die zorgt er bijv. voor dat achter css bestanden een ?v=3.0 is, wat vaak afgeraden wordt voor browser caching.

 

Een ander ding waar ik zelf erg in geloof is dat het CMS, JUIST de code aanpast, en de code optimaliseert daar waar mogelijk. Bijv alle whitespace uit css bestanden halen en dit als cache bestand wegschrijven. Ook in HTML zal alle onnodige whitespace (enters tabs extra spaties) verwijderd moeten worden.

 

Hier is een voorbeeld van wordpress dat heel veel extra resources inlaad door alle plugins ( die door het CMS worden opgezet)

 

 

Nu denk ik juist dat wordpress als CMS dit zou moeten oplossen door dit vooraf in 1 javascript en 1 css bestand te zetten (eenmalig) en op te slaan in een cache bestand volledig geoptimaliseerd.

 

 

En voor de TS raad ik juist wel aan om weer een webdeveloper op te zoeken, wellicht had je een slechte ervaring met de vorige? En zorg er gewoon voor dat je een goede service krijgt, een goede website verdient zich zelf terug namelijk, dus waarom juist daar bezuinigen?

 

[willemj]

TS is al een tijdje weg geloof ik en dit is het zoveelste anti-WordPress bericht - waar ik op zich geen bezwaar tegen heb maar dan wel met valide argumenten - dus (toch) een off-topic bericht:

 

Wordpress gaat hier erg ver in, die zorgt er bijv. voor dat achter css bestanden een ?v=3.0 is, wat vaak afgeraden wordt voor browser caching.

Bron?

 

Die toevoeging '?v=3.0' is prima te gebruiken voor browser caching. Je kunt het css bestand een 'expire date' ver in de toekomst geven (zelfs zonder enige vorm van hervalidatie) Verander je nu iets aan het css bestand dan verander je het versienummer en zal de browser, omdat het een nieuwe uri is, altijd de nieuwe versie laden.

 

Google raadt het gebruik ook aan (bron)

 

 

[Bob de webbouwer]

WordPress voegt standaard geen versienummer toe aan de stylesheet hoor, ik heb al tig WordPress sites opgeleverd en daar staat nergens een versienummer van de stylesheet in de code.

[Branko Collin]

Als moderators dit offtopic gesteggel over de details van een WordPress-site niet naar een aparte draad willen verhuizen, is het dan niet beter hem helemaal af te sluiten? Ik denk niet dat iemand iets opschiet met het gewelles-nietes van een stel computerspecialisten.

[R.I.P. | Peter Bonjernoor]

Een ander ding waar ik zelf erg in geloof is dat het CMS, JUIST de code aanpast, en de code optimaliseert daar waar mogelijk. Bijv alle whitespace uit css bestanden halen en dit als cache bestand wegschrijven. Ook in HTML zal alle onnodige whitespace (enters tabs extra spaties) verwijderd moeten worden.

Je hebt me niet helemaal begrepen, geloof ik. Ik bedoel dat er in een CMS eigenlijk nergens iets als echo "

$title"; voor zou mogen komen - dat moet in een template staan. En dan natuurlijk niet op die specifieke manier.

[Eucalypta]

Ten eerste even een kleine verontschuldiging voor mijn ontzettend late reactie! Er kwamen wat persoonlijke omstandigheden tussen...daarna in de vergetelheid geraakt.

In ieder geval allemaal heel erg bedankt voor jullie reacties...wel ben ik het met o.a. Ward eens dat het nu te technisch wordt.

Ik dacht, misschien wat simplistisch, dat de regels voor een goed functionerende website vaststaan, net zoals vast staat dat 1 en 1, 2 is en dat er om die reden veel programma's zijn die zouden kunnen afvallen omdat ze niet meer voldoen aan de huidige normen.

 

Het CMS beheer is het probleem dan ook niet, dat kunnen we prima zelf. Maar het ging zich erom dat je dan toch vaak een beroep moet doen op een developer. En uit jullie reacties blijkt wel dat de ene developer een heel ander antwoord kan geven dan de andere...

Het is dan ook behoorlijk lastig om als leek de goede developer eruit te halen.

[R.I.P. | Peter Bonjernoor]

Ten eerste even een kleine verontschuldiging voor mijn ontzettend late reactie! Er kwamen wat persoonlijke omstandigheden tussen...

Kan gebeuren, dat soort dingen gaan voor!

 

...dat er om die reden veel programma's zijn die zouden kunnen afvallen omdat ze niet meer voldoen aan de huidige normen.

Het ligt maar net aan de eisen die je stelt. Je noemde zelf in je openingspost bijvoorbeeld WIX, en dat houdt in mijn beleving in dat je weinig eisen stelt. WIX is geinig voor een website waar je prive wat dingetjes online wilt zetten, maar professioneel zou ik er ver van wegblijven.

 

En uit jullie reacties blijkt wel dat de ene developer een heel ander antwoord kan geven dan de andere...

Ach ja, meningen...en de meeste developers zijn dan ook nog eens rete-eigenwijs! ;)

 

[Eucalypta]

Eigenwijs is goed ;D ;D ;D Ik hou daar wel van!

Mijn eisen omtrent Wix zijn volgens mij verkeerd begrepen.

Wix voldoet inderdaad totaal niet, temeer omdat zelfs bij betaling er ergens in je URL een # wordt tussen geplaatst. Dat is uiteraard rampzalig wanneer men professioneel bezig is.

 

Ik ben zelf met meerdere sites bezig en ik heb er 1 laten ontwikkelen die echt helemaal zo is ingericht dat ik alles zelf kan aanpassen en waarbij de betreffende developer zichzelf eigenlijk buitenspel zet. Maar dat loopt uiteraard tevens flink in de papieren...

 

We blijven voorlopig dus gewoon bij Joomla en onze developer vooral ook omdat onze webshop het eigenlijk goed doet. Dus wat dat betreft hebben we geen klagen...gelukkig.

Het was eigenlijk meer dat we een manier zochten om niet telkens een beroep hoeven te doen op de developer.

[Tonino]

Tja, wat is steeds? Bedoel je dan een product toevoegen, prijs wijzigen of iets dergelijks of een betaalmethode toevoegen, layout wijzigen of functionaliteit toevoegen?

 

Eerste moet je zelf goed kunnen doen, 2de is het waarschijnlijk beter als er iemand bij is die weet hoe je een backup maakt en terugzet.

 

[Eucalypta]

Nee, een product toevoegen of tekst e.d. kunnen we uiteraard allemaal zelf. Het CMS is dus geen probleem. Het ging zich inderdaad meer om functionaliteit e.d. Maar we zijn er inmiddels dus wel uit. Toch bedankt voor je reactie!