[PHP] CakePHP console

[Droned]

Ik ben mij vandaag beginnen te verdiepen in CakePHP en het is een handig framework. Nu maak ik echter handmatig de models, views en de controllers aan maar volgens mij bestaat zoals ik lees een optie om dit te doen via een BAKE.

Het probleem is nu dat ze altijd spreken van een Console, maar de vraag is nu waar vind ik die en hoe kan ik de PHP CLI gebruiken op een shared hosting account.

Nu is dit wel op mijn eigen server dus heb ik geprobeert via daar maar dan geraak ik wel in de console maar niet op de juiste manier volgens mij want moet telkens ./cake doen om erin te geraken maar ik wordt er ook weer onmiddellijk uitgesmeten met een boel van fouten. Parameters meegeven lijkt hier ook niet te lukken.

Wat ik ook nog heb geprobeerd is via het path in de browser naar cake.php te gaan in de map console maar zonder resultaat.

Ik ben het internet al een tijdje aan het aflopen en daar zitten ze altijd al in de console, maar zeggen ze niet hoe je hierin kan komen? Iemand die dit soms weet en even kan toelichten?

[frickY]

Met console wordt doorgaans verwezen naar de shell, op windows ook wel bekend als de prompt.
Zwarte achtergrond, witte letters, tekst-based. Dat idee

Je zult moeten inloggen op je server. Doorgaans doe je dit over SSH met een programma zoals Putty. Het is de vraag of je die toegang hebt bij Shared Hosting.

Je zou uiteraard ook een versie van PHP op je lokale pc kunnen installeren en die gebruiken, in plaats van je server. Zie Using PHP from the command line

[ Voor 37% gewijzigd door frickY op 09-01-2010 16:13 ]

[kokx]

Vaak word er aangeraden om frameworks (of het nou CakePHP, Zend Framework of Symfony is) al niet te draaien op shared hosting.

Daarnaast lijkt het mij handiger dat je ontwikkeld op een lokale omgeving (waar je de CLI natuurlijk wel kan bereiken), en later alles te uploaden met FTP.

Sowieso is het ontwikkelen op een productieomgeving niet het slimste wat je kan doen, en bij frameworks is een CLI vaak erg handig (en soms zelfs benodigd).

[Cartman!]

kokx schreef op zaterdag 09 januari 2010 @ 16:39:
Vaak word er aangeraden om frameworks (of het nou CakePHP, Zend Framework of Symfony is) al niet te draaien op shared hosting.

Heb je daar ook een onderbouwing voor?

[Verwijderd]

Cartman! schreef op zaterdag 09 januari 2010 @ 18:26:

Heb je daar ook een onderbouwing voor?

Natuurlijk niet. Het slaat helemaal nergens op.

In de ontwikkelomgeving heb je uiteraard console access. En daar commit je alles naar je versiebeheersysteem. Je kunt waarschijnlijk prima op een lokaal systeem een export daarvan maken en die via FTP of SCP uploaden naar de shared hosting server. Console access is in veel gevallen helemaal nergens voor nodig.

[messi]

Cartman! schreef op zaterdag 09 januari 2010 @ 18:26:
[...]

Heb je daar ook een onderbouwing voor?

In het geval van CakePHP zit er wel een kern van waarheid in. Hoewel CakePHP prima werkt op een gemiddeld shared hosting pakket, raden de makers aan om niet zo de hele applicatie folder in de webroot te plempen, maar alleen de public map. De overige folders zou je eigenlijk buiten de webroot moeten houden (zie ook: http://book.cakephp.org/view/34/Production ). Bij de meeste standaard shared webhosters zijn dit soort configuraties echter niet zo makkelijk te doen.

Overigens ben ik van mening dat je console alleen in production nodig hebt voor background tasks. Het "baken" van models / controllers / views moet je gewoon lokaal doen en dan deployen met capistrano / de php variant daarvan.

[Verwijderd]

messi schreef op zaterdag 09 januari 2010 @ 18:39:

In het geval van CakePHP zit er wel een kern van waarheid in. Hoewel CakePHP prima werkt op een gemiddeld shared hosting pakket, raden de makers aan om niet zo de hele applicatie folder in de webroot te plempen, maar alleen de public map. De overige folders zou je eigenlijk buiten de webroot moeten houden (zie ook: http://book.cakephp.org/view/34/Production ). Bij de meeste standaard shared webhosters zijn dit soort configuraties echter niet zo makkelijk te doen.

Het "buiten de webroot" verhaal is sowieso overrated. Het belangrijkst is dat je zorgt dat je gewoon zorgt dat bepaalde directories niet geserveerd mogen worden. Dat kan net zo goed door wat directives in een .htaccess te zetten.

Overigens ben ik van mening dat je console alleen in production nodig hebt voor background tasks. Het "baken" van models / controllers / views moet je gewoon lokaal doen en dan deployen met capistrano / de php variant daarvan.

Dat lijkt mij inderdaad ook.

[kokx]

Cartman! schreef op zaterdag 09 januari 2010 @ 18:26:
[...]

Heb je daar ook een onderbouwing voor?

Ten eerste heb je de reden die messi geeft. En inderdaad, dat kun je oplossen met wat .htaccess gegoochel.

Daarnaast heb je nog het performance probleem, je eigen server heeft veel voordelen over een shared hosting. Zo kun je zorgen voor fatsoenlijke cache implementaties (bijvoorbeeld APC of memcached). Ook een opcode cache kan de snelheid flink verbeteren. Iets wat toch al snel ontbreekt bij shared hosting, zeker als je een framework gebruikt.

[CodeCaster]

@kokx: ik zie even de link met cache-framework-shared hosting en het onmogelijk zijn van de combinatie niet. In vrijwel iedere, zo niet alle php-configuraties kan een cache worden geïmplementeerd, en een framework is in de meeste gevallen niets anders dan een verzameling php-bestanden.

Mis ik iets?

[ Voor 8% gewijzigd door CodeCaster op 09-01-2010 23:24 ]

[Verwijderd]

Nee hoor, hij probeert alleen zijn ass te redden nadat hij een uitspraak deed die nergens op sloeg aangezien hij is gebaseerd op ongefundeerde aannames.

[Cartman!]

Verwijderd schreef op zaterdag 09 januari 2010 @ 18:31:
[...]

Natuurlijk niet. Het slaat helemaal nergens op.

Precies maar ik hoopte op een mooi verhaal

[kokx]

CodeCaster schreef op zaterdag 09 januari 2010 @ 23:23:
@kokx: ik zie even de link met cache-framework-shared hosting en het onmogelijk zijn van de combinatie niet. In vrijwel iedere, zo niet alle php-configuraties kan een cache worden geïmplementeerd, en een framework is in de meeste gevallen niets anders dan een verzameling php-bestanden.

Mis ik iets?

Ik heb nergens gezegd onmogelijk . Het word echter aangeraden om geen shared hosting te gebruiken.

@Cheetah, Cartman!: Tuurlijk, het is mogelijk. Echter, ZF gebruikt bijvoorbeeld vaker dan eens meer dan 16MB aan php-geheugen, wat al lastig is bij een aantal webhosts. Daarnaast weet ik uit eigen ervaring dat frameworks gewoon meer serverkracht vergen dan 'normale' php applicaties. Hierdoor zijn ze vaak op shared hosting traag. Dus raad ik mensen altijd aan om geen shared hosting te gebruiken, zeker als je een MVC framework als ZF gebruikt.

[styxit]

Je moet eerst het commando 'cake' aan je shell of prompt toevoegen. Op de site van cakephp staan screencasts van hoe je dat doet.

http://cakephp.org/screencasts

De videoplayer werkt bij mij niet, weet niet of dat bij iedereen is, maar dit zijn de directe links:
Windows: http://ia340902.us.archiv...windows_console_setup.mov

*nix: http://www.archive.org/do...nix/nix_console_setup.mov

Overigens lijkt het me dat je dit soort dingen, zoals 'bake', alleen binnen je testomgeving gaat doen, aangezien je bake alleen gebruikt tijdens het ontwikkelen van nieuwe dingen.

[Verwijderd]

kokx schreef op zondag 10 januari 2010 @ 03:26:

@Cheatah, Cartman!: Tuurlijk, het is mogelijk. Echter, ZF gebruikt bijvoorbeeld vaker dan eens meer dan 16MB aan php-geheugen, wat al lastig is bij een aantal webhosts. Daarnaast weet ik uit eigen ervaring dat frameworks gewoon meer serverkracht vergen dan 'normale' php applicaties. Hierdoor zijn ze vaak op shared hosting traag. Dus raad ik mensen altijd aan om geen shared hosting te gebruiken, zeker als je een MVC framework als ZF gebruikt.

En ik heb genoeg jaren professionele ervaring als webdeveloper én als serverbeheerder om te kunnen zeggen dat dat onzin is.

Trage applicaties ontstaan meestal als mensen niet kunnen programmeren of hun werk niet kunnen optimaliseren. Als frameworks veel trager zijn, bedoel je daar dan mee dat de ontwikkelaars van die frameworks ook niet kunnen programmeren?

En als een shared hosting omgeving traag is, heeft dat meestal te maken met budget. Als je voor een dubbeltje op de eerste rang wilt zitten, heb je een goede kans dat je niet krijgt wat je verwacht. Maar om nou meteen alle shared hosting weg te willen strepen? Ik denk dat je daar dan blijkbaar wat te weinig ervaring mee hebt. Er zijn ook genoeg hostingbedrijven die shared hosting wel redelijk op de rit hebben.

[wackmaniac]

Om kokx toch een klein beetje gelijk te geven; de diverse frameworks zijn niet altijd opgezet met pure snelheid in gedachte, maar meestal met gebruikersgemak en flexibiliteit. Als ik een pagina zou klussen die per pagina alles in 1 bestand heeft staan, is deze wellicht sneller dan wanneer ik ZF of Cake oid gebruik. Echter, zal dat snelheidsverlies behoorlijk op te vangen zijn met een goede cache.

[kokx]

Verwijderd schreef op zondag 10 januari 2010 @ 09:37:
[...]

En ik heb genoeg jaren professionele ervaring als webdeveloper én als serverbeheerder om te kunnen zeggen dat dat onzin is.

Trage applicaties ontstaan meestal als mensen niet kunnen programmeren of hun werk niet kunnen optimaliseren. Als frameworks veel trager zijn, bedoel je daar dan mee dat de ontwikkelaars van die frameworks ook niet kunnen programmeren?

En als een shared hosting omgeving traag is, heeft dat meestal te maken met budget. Als je voor een dubbeltje op de eerste rang wilt zitten, heb je een goede kans dat je niet krijgt wat je verwacht. Maar om nou meteen alle shared hosting weg te willen strepen? Ik denk dat je daar dan blijkbaar wat te weinig ervaring mee hebt. Er zijn ook genoeg hostingbedrijven die shared hosting wel redelijk op de rit hebben.

Het probleem is dat 9/10 mensen die shared hosting gebruiken, voor een dubbeltje op de eerste rang willen zitten. Tuurlijk, er zijn wel shared hosts waar dit beter geregeld is, maar ten eerste moet je die maar vinden, en ten tweede zijn die vaak niet veel goedkoper dan de vele VPS-hosts die te vinden zijn.

Over het 'niet kunnen programmeren' van framework developers: als je puur naar snelheid gaat kijken, zou je daar gelijk in hebben. Frameworks doen qua snelheid een aantal minder slimme dingen. Zoals het aanmaken van gigantisch veel objecten en het includen van enorm veel bestanden.

Frameworks zijn eigenlijk ook helemaal niet bedoeld voor je homepage, maar meer voor de grotere websites. Websites waar men de resources heeft voor fatsoenlijke servers. Waar het echt wat uitmaakt dat development-tijd ingekort word tegenover de verhoogde server kosten.

[Raynman]

kokx schreef op zondag 10 januari 2010 @ 13:18:
[...]

Frameworks zijn eigenlijk ook helemaal niet bedoeld voor je homepage, maar meer voor de grotere websites. Websites waar men de resources heeft voor fatsoenlijke servers. Waar het echt wat uitmaakt dat development-tijd ingekort word tegenover de verhoogde server kosten.

Je homepage zal vast ook niet zoveel bezoekers te verwerken hebben als zo'n grotere website. En dan kun je prima een framework gebruiken om bijv. in beperkte vrije tijd wat meer voor elkaar te krijgen, of om wat nieuws te leren.

Het slaat misschien niet helemaal nergens op, maar ik denk wel dat je onnodige drukte schopt.

Ik heb overigens in het verleden wel wat goedkope shared hosting gehad bij een paar bedrijfjes, en daar kon ik meestal wel dingen buiten de webroot plaatsen.

[kwaakvaak_v2]

kokx schreef op zondag 10 januari 2010 @ 13:18:
[...]


Over het 'niet kunnen programmeren' van framework developers: als je puur naar snelheid gaat kijken, zou je daar gelijk in hebben. Frameworks doen qua snelheid een aantal minder slimme dingen. Zoals het aanmaken van gigantisch veel objecten en het includen van enorm veel bestanden.

Grappig, je preekt zend framework in je sig, maar als ik je reacties lees lijk je precies geen idee te hebben waar je over praat. Meeste frameworks, inclusief zend gebruiken lazy loading, en includen pas bestanden als je ze nodig hebt ipv alles maar te includen voor het geval het nodig mocht zijn.


En het goed inregelen van zend_Cache kun je prima op een shared hosting een site draaien zonder dat je direct memcached nodig hebt, bytecode caching met APC kan helpen maar gewoon filecaching werkt met ZF ook best goed, zolang je maar weet wat je wel en niet wil cachen.

En of je dat nu voor je hobby doet, of voor je werk, dat maakt toch geen bal uit. Het is zeker niet zo dat als een werkgever je betaald om te coden in PHP direct een goede programmeur bent. Sterker nog, ik zie in hobby projecten regelmatig mooiere code voorbij komen dan in sommige draken die ik van 'professionals' zie

[Cartman!]

Kortom, dat je ZF niet op een shared omgeving kunt gebruiken slaat compleet nergens op. Net zoals Cheatah heb ik daar meer dan genoeg professionele ervaring in om dat te kunnen zeggen.

De hosting waar ik prive een paar tientjes per jaar aan kwijt ben daar draait het ook gewoon als een trein dus zelfs het dubbeltje/eerste rang argument blijft zo niet echt staan imo.

ZF is niet het snelste framework maar dat ligt vooral aan de frontcontroller, als wij stresstests uitvoeren ligt het altijd daaraan. Als je goede caching toepast hoeft dat echter helemaal geen belemmering te zijn.

[ Voor 22% gewijzigd door Cartman! op 11-01-2010 09:18 ]