PHP webshop uploaden naar webhost

[Verwijderd]

Hallo lezers,

Een tijdje geleden ben ik begonnen met het maken van een webshop, dit met hulp van Slim, Twig en Illuminate database (geïnstalleerd met composer). Op de localhost doet alles het prima, maar nu wil ik de website graag uploaden naar mijn web host. Hier lukt het me niet om de website werkend te krijgen.

Ik heb de bestanden geüpload, vervolgens ga ik naar website.com/pubic en dan gaat het mis, waar het op de localhost wel werkt werkt het op de web host niet.

Weet iemand hoe ik dit probleem op kan lossen?

Met vriendelijke groet,
Mark Hatyema

[ Voor 4% gewijzigd door Verwijderd op 03-01-2018 18:59 ]

[PageFault]

Wat gaat er exact mis????

[Verwijderd]

PageFault schreef op woensdag 3 januari 2018 @ 19:02:
Wat gaat er exact mis????

Een HTTP ERROR 500

[Deef_K]

Heb je lokaal geen database gehad waarin je nu naar verwijst? Met andere woorden de database bestaat niet?

[Boomster]

Zijn alle doorlinks wel goed?
Heb je geen verwijzingen meer staan naar 'localhost' ?

[Room42]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:05:
[...]


Een HTTP ERROR 500

Dit is een server error (500). Dan moet je dus in de error_log bij je provider kijken wat de betreffende fout is.

[ Voor 6% gewijzigd door Room42 op 03-01-2018 19:09 ]

[Ruubster]

Wellicht eenvoudiger om even debugging aan te zetten online, voor nu. Dan kun je ook zien wat er fout gaat. Ik gok namelijk dat op de server in PHP het weergeven van foutmeldingen uitstaat. Kan op meerdere manieren, als je een php.ini ergens hebt staan daarin 'display_errors = On' instellen, of in je index.php onderstaande regel zetten:

ini_set('display_errors', 1);

Edit: Als het geen PHP fout is, dan wat @Room42 zegt, zijn er ergens logboeken die je kunt inzien? Error 500 is zoeken naar een spel in een hooiberg, net zoiets als "mijn auto is kapot". Kan van alles zijn.

Oh en display_errors weer uitzetten nadat alles werkt!!

[ Voor 26% gewijzigd door Ruubster op 03-01-2018 19:15 ]

[Room42]

Ruubster schreef op woensdag 3 januari 2018 @ 19:12:
[...] Error 500 is zoeken naar een spel in een hooiberg, net zoiets als "mijn auto is kapot". Kan van alles zijn.

In de browser wel, ja. Maar in de Apache error log wordt gewoon netjes vermeldt wat er precies misging met die 500. Dat is meestal informatie die je niet je klanten wilt tonen. Vandaar dat je display_errors ook uitzet op een productieomgeving... Maar dan heb je nog steeds je logfiles

[ Voor 25% gewijzigd door Room42 op 03-01-2018 19:18 ]

[Ruubster]

Room42 schreef op woensdag 3 januari 2018 @ 19:16:
[...]

In de browser wel, ja. Maar in de Apache error log wordt gewoon netjes vermeldt wat er precies misging met die 500. Dat is meestal informatie die je niet je klanten wilt tonen. Vandaar dat je display_errors ook uitzet op een productieomgeving... Maar dan heb je nog steeds je logfiles

Ja daar ben ik het mee eens, als hij bij de logs kan. Anders moet ie elke keer de logs op gaan vragen bij de hostingpartij. Het is een eerste installatie, lijkt me dan makkelijker om even display_errors aan te zetten zodat je ook niet telkens op en neer springt maar gewoon gelijk ziet in de browser.

Sowieso uitzetten op productie uiteindelijk, ben het met je eens dat je een error niet aan je klanten wilt weergeven. En voor kwaadwillig gebruik. Maar voor nu lijkt het mij eenvoudiger om het even aan te zetten, kan toch geen kwaad?

Op een live site zou ik hem ook nooit aanzetten hoor, als klanten er ook echt gebruik van maken

Nu ik erover nadenk, je zou display_errors zelfs nog op IP adres aan kunnen zetten, zodat alleen jouw ip het ziet. Maar dat is wel een smerige oplossing he....

[ Voor 12% gewijzigd door Ruubster op 03-01-2018 19:27 ]

[Verwijderd]

-

[ Voor 100% gewijzigd door Verwijderd op 19-10-2019 15:09 . Reden: Leeg ivm privacy ]

[Verwijderd]

ik heb een .htaccess bestandje aangemaakt met daarin 'php_value display_errors on'.
Ik krijg nu de volgende error als ik naar de website ga:

[Verwijderd]

Het include path of project root path klopt niet. Hij kan hierdoor een class niet autoloaden.

[AW_Bos]

Verwijderd schreef op woensdag 3 januari 2018 @ 18:58:
Ik heb de bestanden geüpload, vervolgens ga ik naar website.com/pubic en dan gaat het mis, waar het op de localhost wel werkt werkt het op de web host niet.

Sowieso vreemd dat je naar www.domein.nl/public op je site gaat. Met /public in de dirctory-tree wordt de huidige public-direcoty bedoelt waarin jij je bestanden uploadt, en wat er zichtbaar is via de browser.
Dit kan bijvoorbeeld /public_html, /htdocs of /www zijn. De rest hoort daarboven.

Dus de mappen die geen /public zijn, die moet je dus ook niet in je public map-uploaden.

[Ravefiend]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:31:
ik heb een .htaccess bestandje aangemaakt met daarin 'php_value display_errors on'.
Ik krijg nu de volgende error als ik naar de website ga:
[afbeelding]

Ook ff zoeken op "cart\app not found", met results als deze:
https://stackoverflow.com...-class-cart-app-not-found

[Verwijderd]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:37:
Het include path of project root path klopt niet. Hij kan hierdoor een class niet autoloaden.

Destijds heb ik precies dezelfde error gehad op de localhost, ik heb toen na veel proberen de terminal geopend en de command 'composer dumpautoloader -o ' opnieuw uitgevoerd. Hij deed het toen vanuit het niets. Maar hoe doe ik dat op mijn webhost??

[Verwijderd]

De meeste webhosts staan een ssh shell toe, waar je dat kunt uitvoeren.

[AW_Bos]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:55:
[...]


Destijds heb ik precies dezelfde error gehad op de localhost, ik heb toen na veel proberen de terminal geopend en de command 'composer dumpautoloader -o ' opnieuw uitgevoerd. Hij deed het toen vanuit het niets. Maar hoe doe ik dat op mijn webhost??

Die hebben meestal geen composer. Of je moet een eigen server zoals een VPS o.i.d. hebben.
Je kan composer toch ook lokaal installeren, daar je site ontwikkelen, netjes de juiste directory-structuur aanhouden zoals ik net aanhaalde, en als het werkt, de boel uploaden.

Ik neem aan dat je van je hosting hoger dan je public map (webroot) mag komen.

Verwijderd schreef op woensdag 3 januari 2018 @ 19:56:
De meeste webhosts staan een ssh shell toe, waar je dat kunt uitvoeren.

Niet veel voor zover ik weet. En dan is het nog zozeer de vraag of je zomaar programma's mag installeren.

[ Voor 16% gewijzigd door AW_Bos op 03-01-2018 19:57 ]

[Verwijderd]

AW_Bos schreef op woensdag 3 januari 2018 @ 19:42:
[...]

Sowieso vreemd dat je naar www.domein.nl/public op je site gaat. Met /public in de dirctory-tree wordt de huidige public-direcoty bedoelt waarin jij je bestanden uploadt, en wat er zichtbaar is via de browser.
Dit kan bijvoorbeeld /public_html, /htdocs of /www zijn. De rest hoort daarboven.

Dus de mappen die geen /public zijn, die moet je dus ook niet in je public map-uploaden.

Ik ben een simpele html website gewend
waar laat ik al die andere bestanden dan?

[AW_Bos]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:57:
[...]


Ik ben een simpele html website gewend
waar laat ik al die andere bestanden dan?

Dat zeg ik.. daarboven!
Welk control-panel wordt er gebruikt bij je webhosting?

[ Voor 10% gewijzigd door AW_Bos op 03-01-2018 20:00 ]

[Verwijderd]

AW_Bos schreef op woensdag 3 januari 2018 @ 19:57:
Die hebben meestal geen composer.

Eh.. composer is gewoon PHP. Die kun je dus zelf erop zetten, daarvoor hoeft niets geinstalleerd te worden verder.

Niet veel voor zover ik weet. En dan is het nog zozeer de vraag of je zomaar programma's mag installeren.

Eh, ik ken zo uit mijn hoofd geen enkele webhoster waar je géén SSH krijgt. Alleen als je gaat rommelen met cheap-ass gratis hosting uit het buitenland, krijg je dat soort dingen.

Of byet dat ook heeft, durf ik niet te zeggen. Maar zelfs dan is het niet perse nodig. Je kunt je composer opdracht ook in een shell_exec in php kwijt. Dat werkt in 99,9% van de gevallen prima.

[AW_Bos]

Verwijderd schreef op woensdag 3 januari 2018 @ 20:03:
[...]
Eh.. composer is gewoon PHP. Die kun je dus zelf erop zetten, daarvoor hoeft niets geinstalleerd te worden verder.

Hm.... je hebt gelijk. Dat is mij nog nooit opgevallen. Ik heb het destijds op Windows met de executable geinstalleerd. Dan verwacht je toch anders. Maar je hebt er ongetwijfeld wel SSH voor nodig op Linux.

Cheap webhostings in Nederland zullen het ook niet hebben, maar laten we het op de gerenommeerde houden zoals Antagonist die het wel ondersteund. Die werken trouwens ook met geïsoleerde containers voor alle processen van je user. Maar dat terzijde

Maar composer is naar mijn mening vooral handig op een ontwikkel-server. Dus of je het op je hosting nodig hebt, is een tweede.

[ Voor 8% gewijzigd door AW_Bos op 03-01-2018 20:08 ]

[Verwijderd]

Composer heeft in principe niets te zoeken op een productieserver. Klopt. Maar ja. Als de devver zelf niet de kennis heeft paden goed te zetten.. (niet vervelend bedoeld)

[Verwijderd]

AW_Bos schreef op woensdag 3 januari 2018 @ 19:58:
[...]

Dat zeg ik.. daarboven!
Welk control-panel wordt er gebruikt bij je webhosting?

de map public staat nu in de public_html directory, de rest staat er allemaal keurig boven zoals jij zei.
staat allemaal op haytema.com nu, maar nu de error nog..

[AW_Bos]

Een kwestie van je pad in je index controleren. Desnoods even als extraatje echo'en, zodat je ziet waar PHP de classes zoekt.

[Verwijderd]

Ik kom er maar niet uit, iemand nog tips/hulp?

Alvast bedankt,

[Room42]

Vergelijk je lokale omgeving met de webserver. Hoe zag je lokale omgeving eruit? Hoe verhoudt zich dat tot je provider?

En... check je logs!

[Verwijderd]

Room42 schreef op woensdag 3 januari 2018 @ 22:35:
Vergelijk je lokale omgeving met de webserver. Hoe zag je lokale omgeving eruit? Hoe verhoudt zich dat tot je provider?

En... check je logs!

Alles is identiek aan elkaar, de log geeft dezelfde error als op de pagina zelf.

[Room42]

Nouja, identiek... Op je lokale omgeving doet ie het wel, toch? Anders zie ik het probleem niet

Anyway, maak nog even een bestandje aan (bijvoorbeeld phpinfo.php) met daarin het onderstaande. Plaats deze op beide omgevingen en vergelijk ze. Post de output niet online. Verwijder het bestand ook weer naderhand.

PHP:

phpinfo();

Wat je verder kunt controleren is of er nog een config.php is die je moet aanpassen naar de productieomgeving.

[DJMaze]

Verwijderd schreef op woensdag 3 januari 2018 @ 19:57:
Ik ben een simpele html website gewend

En dan begin je gelijk met composer?!?

Persoonlijk heb ik composer in de prullenbak gegooit.
Niet dat composer slecht is, de structuur is ruk.
Elk package zijn eigen autoloader, volledige git repo, etc.
En wat doen al die "/tests/" en weet niet wat allemaal voor bestanden op een live server?

Extreem voorbeeld Akeneo PIM:
Met alle niet "live" code: 179 MiB
Zonder alle niet "live" code: 139 MiB
Geheugen gebruik: 3 GiB

Het is goed dat je meer doet dan een "simpele html website" maar begin dan netjes met 2 simpele autoloaders

PHP:

<?php
set_include_path('.'
    .PATH_SEPARATOR.'.'.DIRECTORY_SEPARATOR.'vendor'
    .PATH_SEPARATOR.get_include_path()
);
if ('/' === DIRECTORY_SEPARATOR) {
    // Default FAST lowercase detection
    spl_autoload_extensions('.php');
    spl_autoload_register();
    // Slower case-sensitive standard "everyone" uses
    spl_autoload_register(function($name){
        if ($file = stream_resolve_include_path(strtr($name, '\\', '/') . '.php')) {
            include_once $file;
        }
    });
} else {
    // Slower buggy Windows OS
    // Because people on Windows OS are case-insensitive and produce bugs when uploading to POSIX
    // So the strpos() verifies case-sensitive to prevent errors when uploading from Win32 to POSIX
    spl_autoload_register(function($name){
        if ($file = stream_resolve_include_path($name . '.php') && false !== strpos($file, $name)) {
            include_once $file;
        } else {
            $name = strtolower($name);
            if ($file = stream_resolve_include_path($name . '.php') && false !== strpos($file, $name)) {
                include_once $file;
            }
        }
    });
}

En plaats Twig "src/*" als /vendor/Twig/ (je hebt immers alleen de "src" map nodig, de "lib" map is oldschool)
En plaats Illuminate/Database als /vendor/Illuminate/Database/
etc,

Sleek, snel en duidelijk wat je echt nodig hebt voor je website.
Op deze manier rol ik zelf websites uit.
Ok, in de basis is dit iets meer werk maar je kan (als je POSIX gebruikt en NIET Windoes) symlinks maken.
Zo heb ik WEL een composer voor het beheer en updaten van alle packages.
Vervolgens heb ik in een project op mijn PC:

code:

ln -s /home/USER/composer/vendor/Twig/src /home/USER/public_html/PROJECT/vendor/Twig
ln -s /home/USER/composer/vendor/Illuminate/Database /home/USER/public_html/PROJECT/vendor/Illuminate/Database

Ik zeg NIET dat je het zo moet doen, maar het heeft mij in ieder geval nog nooit een 500 Error opgeleverd
Vroeger toen ik nog Windows gebruikte wel hoor, had ik bijvoorbeeld ergens ILluminate getypt, uploaden naar Linux server en hoppa, stuk

[ Voor 17% gewijzigd door DJMaze op 04-01-2018 13:06 . Reden: Fix autoloader code voor Windows ]

[NMe]

DJMaze schreef op donderdag 4 januari 2018 @ 01:05:
[...]

En dan begin je gelijk met composer?!?

Alsof Composer zo'n grote learning curve heeft? Even composer req whatever/package tikken en het werkt gewoon direct, zonder zelf na te hoeven denken over dependencies en compatibility.

Persoonlijk heb ik composer in de prullenbak gegooit.
Niet dat composer slecht is, de structuur is ruk.
Elk package zijn eigen autoloader, volledige git repo, etc.
En wat doen al die "/tests/" en weet niet wat allemaal voor bestanden op een live server?

[...snip...]

In je hele verhaal is dit eigenlijk je enige argument, ruimte op de schijf. En da's nogal een zwak argument want Composer haalt talloze zorgen uit je nek. Komt er een nieuwe versie van je framework uit maar is een van je gebruikte dependencies nog niet compatible? Geen probleem, je kan nog steeds al je packages updaten zonder er erg hard over na te denken, gewoon na de update je unit tests runnen en een paar keer klikken en je weet vrijwel zeker dat 't allemaal gewoon werkt. Zonder Composer moet je zelf uit gaan zoeken welke dependencies je hebt bij elk gebruikt package, en bij het upgraden van de ene package moet je checken of alles dat daarvan afhankelijk is (of andersom...) compatible is met die nieuwe versie.

Composer niet gebruiken is leuk voor als je nooit van plan bent je vendorcode te updaten. Voor daadwerkelijk praktisch gebruik is 't vrijwel onmisbaar in het huidige PHP-landschap.

Je laatste tip met één shared plek voor alle globale vendor packages is trouwens ook niet bijster handig. Als project A en project B op dezelfde server draaien en A heeft versie 3.0 van een package nodig terwijl B nog afhankelijk is van 2.1 en niet over kan op 3.0 heb je al een probleem, dan kun je één centrale folder alweer niet meer met Composer onderhouden.

[ Voor 9% gewijzigd door NMe op 04-01-2018 01:26 ]

[DJMaze]

@NMe dat wij verschillen van mening is prima.
Elke ontwikkelaar heeft immers zijn eigen voorkeuren (docker, npm, composer, apt, rpm, bower, git submodule, mercurial subrepository, etc.).

Trouwens, als het goed is werk je al met Git or Mercurial en dan is een subtree zo gemaakt.
Die kan trouwens ook locken (net als composer.lock).
Waarom heb je dan überhaupt nog composer nodig als je DCVS het al kan?
Dan heb jij inderdaad één goed argument: dependencies

Daarnaast is mijn verhaal niet alleen "ruimte op de schijf". Er zijn veel meer aspecten in het spel waar ik ook een heel klein deel van vertel.
Zeker als je op shared hosting zit.

Het is dus allemaal gewoon wikken/wegen om te kijken wat werkt voor een project.

[ Voor 32% gewijzigd door DJMaze op 04-01-2018 01:46 ]

[curry684]

Elk package zijn eigen autoloader, volledige git repo, etc.

Huh?

[Hiroj]

Verwijderd schreef op woensdag 3 januari 2018 @ 20:21:
[...]


[afbeelding]

de map public staat nu in de public_html directory, de rest staat er allemaal keurig boven zoals jij zei.
staat allemaal op haytema.com nu, maar nu de error nog..

Meeste hosting partijen vinden het niet zo prettig als jij buiten de public_html folder jouw bestanden upload.
Wanneer jij alles in de public_html zou uploaden, gaat het prima werken.

De /public/ folder zelf (vanuit SlimPHP meegekregen) zou je kunnen verwijderen, nadat je de index.php en .htaccess eruit hebt gehaald en dus in de public_html folder hebt geplaatst. Vergeet dan niet om in index.php de vendor/autoload.php op de juiste manier aan te roepen

Men is er vanuit gegaan wanneer jij de skeleton van SlimPHP gebruikt, dat jij ook volledige toegang hebt tot de server inrichting. Je zou dan bijvoorbeeld zelf /var/www/public/ moeten kunnen instellen in de apache vhost configuratie.

[EvH]

Verwijderd schreef op woensdag 3 januari 2018 @ 22:23:
Ik kom er maar niet uit, iemand nog tips/hulp?

Alvast bedankt,

Zoals werd gesuggereerd:
"Een kwestie van je pad in je index controleren. "

Hoe ziet de inhoud van index.php eruit die je in je public_html map hebt geplaatst?

[MartenvanUrk]

Misschien een kwestie van Windows (Ontwikkelomgeving) > Linux (Webhost) qua paths?

[ Voor 23% gewijzigd door MartenvanUrk op 04-01-2018 08:52 ]

[CyberJack]

Hiroj schreef op donderdag 4 januari 2018 @ 07:53:
[...]

Meeste hosting partijen vinden het niet zo prettig als jij buiten de public_html folder jouw bestanden upload.
Wanneer jij alles in de public_html zou uploaden, gaat het prima werken.

De /public/ folder zelf (vanuit SlimPHP meegekregen) zou je kunnen verwijderen, nadat je de index.php en .htaccess eruit hebt gehaald en dus in de public_html folder hebt geplaatst. Vergeet dan niet om in index.php de vendor/autoload.php op de juiste manier aan te roepen

Men is er vanuit gegaan wanneer jij de skeleton van SlimPHP gebruikt, dat jij ook volledige toegang hebt tot de server inrichting. Je zou dan bijvoorbeeld zelf /var/www/public/ moeten kunnen instellen in de apache vhost configuratie.

Ik draai al jaren een eigen vps dus ik weet niet of hosters echt alleen uploaden in de document root toestaan, maar mocht dat zo zijn zou dit zeer triest zijn.

Het framework, je eigen code maar ook bijvoorbeeld een .git directory en composer.json/lock file worden voor 1 simpele reden buiten de document root gezet: veiligheid. Het niet meer direct kunnen aanroepen van deze bestanden zorgt ervoor dat deze ook niet rechtstreeks te misbruiken zijn.

Als je de structuur van de applicatie moet omgooien (en dus minder veilig maken) omdat je hoster dit niet ondersteund, dan zou ik op zoek gaan naar een andere hoster.

Daarbij heb je de composer.json/lock en een .git directory alleen voor ontwikkeling nodig en niet op een productie omgeving. Als een deployment goed voorbereid wordt heb je composer.phar dus ook niet nodig op productie.

[Hiroj]

CyberJack schreef op donderdag 4 januari 2018 @ 09:36:
[...]


Ik draai al jaren een eigen vps dus ik weet niet of hosters echt alleen uploaden in de document root toestaan, maar mocht dat zo zijn zou dit zeer triest zijn.

Het framework, je eigen code maar ook bijvoorbeeld een .git directory en composer.json/lock file worden voor 1 simpele reden buiten de document root gezet: veiligheid. Het niet meer direct kunnen aanroepen van deze bestanden zorgt ervoor dat deze ook niet rechtstreeks te misbruiken zijn.

Als je de structuur van de applicatie moet omgooien (en dus minder veilig maken) omdat je hoster dit niet ondersteund, dan zou ik op zoek gaan naar een andere hoster.

Daarbij heb je de composer.json/lock en een .git directory alleen voor ontwikkeling nodig en niet op een productie omgeving. Als een deployment goed voorbereid wordt heb je composer.phar dus ook niet nodig op productie.

Hetzelfde hier, voor grootschalige opdrachten die ik mag uitvoeren heb ik ook altijd een aparte VPS voor de klant opgenomen in de offerte. Voorkomt een hoop gedoe bij hostingpartijen.

Maar helaas stuit ik ook wel vaak tegen situaties zoals de TS ook wel (vermoedelijk) zal ervaren, dat de klant absoluut niet weg wil / kan bij de huidige partij en je dus tegen limieten van zo'n partij aanloopt.

[AW_Bos]

Hiroj schreef op donderdag 4 januari 2018 @ 07:53:
[...]

Meeste hosting partijen vinden het niet zo prettig als jij buiten de public_html folder jouw bestanden upload.
Wanneer jij alles in de public_html zou uploaden, gaat het prima werken.

De meeste controlpanels die de hostingbedrijven gebruiken hebben er geen problemen mee.
Het veel gebruikte DirectAdmin backupt gewoon de hele domein, en dus ook instellingen en de hoger gelegen mappen. Sinds de introductievan frameworks is deze werkwijze veel gebruikt.

De hosting die het NIET prettig vindt, moet dan wel behoorlijk verouderd zijn.

Maar een webwinkel zou ik liever een VPS geven. Je wilt niet dat klant 'b' van de hostingprovider op de shared server een groot script draait en de boel vertraagt of onderuit schopt. Als je Magento gebruikt is een VPS zeker aan te raden.

[ Voor 15% gewijzigd door AW_Bos op 04-01-2018 09:57 ]

[Merethil]

AW_Bos schreef op donderdag 4 januari 2018 @ 09:56:
[...]

De meeste controlpanels die de hostingbedrijven gebruiken hebben er geen problemen mee.
Het veel gebruikte DirectAdmin backupt gewoon de hele domein, en dus ook instellingen en de hoger gelegen mappen. Sinds de introductievan frameworks is deze werkwijze veel gebruikt.

De hosting die het NIET prettig vindt, moet dan wel behoorlijk verouderd zijn.

Maar een webwinkel zou ik liever een VPS geven. Je wilt niet dat klant 'b' van de hostingprovider op de shared server een groot script draait en de boel vertraagt of onderuit schopt. Als je Magento gebruikt is een VPS zeker aan te raden.

Bij een VPS hoef je ook niet altijd te verwachten dat je niet op een over-provisioned hostsysteem zit hoor. Heb een tijd lang een VPS bij Contabo gehad, die hebben dikke specs tegen een lage prijs maar waren rete-traag. Reden? Blijkbaar draaien die alles zwaar over-provisioned waardoor je alsnog tegen performance van jaar kruik zit te hikken...

Maar goed, ik prefereer ook een VPS buiten hostingpakketten, al is het maar zodat je er zelf extra tools (monitoring, backups, andere webservers (nginx ipv apache bijvoorbeeld, als dat je voorkeur is), Java/Ruby/Python ipv PHP (bijvoorbeeld bij migratie naar een ander platform, niet dat ik vind dat er iets mis is met PHP verder) en zo door) op kan zetten.

[AW_Bos]

Daarom zou ik altijd het liefste een VPS voor een paar weken eerst op de proef willen gebruiken, als je er een belangrijke site op zet.

[CyberJack]

AW_Bos schreef op donderdag 4 januari 2018 @ 10:42:
Daarom zou ik altijd het liefste een VPS voor een paar weken eerst op de proef willen gebruiken, als je er een belangrijke site op zet.

Bij veel hosters kan je een vps per maand krijgen.
Dat maakt het proberen wel makkelijk.

Nadeel is natuurlijk dat je bij iedere test steeds opnieuw alles moet installeren.
En met een vps ben je zelf verantwoordelijk voor het onderhoud (updates, backups e.d.).
Iets waar bij bij een hosting pakket minder last van hebt.

[ Voor 25% gewijzigd door CyberJack op 04-01-2018 11:09 ]

[Waarnemer]

Ok, alles van je local folder geupload in de /public_html/ folder op je external host.
1). maar heb je ook de database van je localhost geexporteerd en weder geimporteerd op je external host?
2). heb je de configuratie aangepast aan je nieuwe locatie?
3). als er paden zijn opgeslagen in de database, kloppen die met de nieuwe paden
4). zijn alle vereiste Apache en PHP modules aanwezig? speaking of.. zelfde PHP versie enzovoorts???

[AW_Bos]

CyberJack schreef op donderdag 4 januari 2018 @ 11:07:
[...]


Bij veel hosters kan je een vps per maand krijgen.
Dat maakt het proberen wel makkelijk.

Nadeel is natuurlijk dat je bij iedere test steeds opnieuw alles moet installeren.
En met een vps ben je zelf verantwoordelijk voor het onderhoud (updates, backups e.d.).
Iets waar bij bij een hosting pakket minder last van hebt.

Bij een VPS kan je ook een managed-contract afsluiten.
Dan regelt je hosting de updates.

[mcDavid]

Verwijderd schreef op woensdag 3 januari 2018 @ 22:23:
Ik kom er maar niet uit, iemand nog tips/hulp?

Alvast bedankt,

Ja, debuggen. Zoek uit wat er gebeurt op de regel waarvan je die error krijgt. Zoek uit hoe je autoloader werkt. Zoek uit of de paden kloppen. Zonder iets te proberen ga je geen stap verder komen. Wij kunnen ook alleen maar speculeren.

Wat mij direct al triggert is het inconsistente hoofdlettergebruik in de paden, let er dus goed op of dat klopt. Classnames en namespaces zijn in PHP niet case-sensitive, maar paden op een linux-systeem wel. Als die niet overeen komen gaat het autoloaden dus vaak mis.

[Sjoak]

daarom ontwikkeling omgeving gelijk trekken aan serveromgeving, en niet kloten met shared hosting met dit soort applicaties, is leuk als je een wordpressje hebt maar niet als je serieuzere dingen wilt draaien.

[Verwijderd]

Even de bestanden op een rijtje:
Index.php

PHP:

<?php

require __DIR__ . '/../bootstrap/app.php';

$app->run();

app.php

PHP:

 <?php

use Cart\app;
use Illuminate\Database\Capsule\Manager as Capsule;

session_start();

require __DIR__ . '/../vendor/autoload.php';

$app = new App;  //Dit is de error

$capsule = new Capsule;
$capsule->addConnection([
    'driver' => 'mysql',
    'host' => 'localhost',
    'database' => 'werkenaa_webshopdb',
    'username' => 'werkenaa_haytema',
    'password' => '.....',
    'charset' => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix' => ''
    
]);

$capsule->setAsGlobal();
$capsule->bootEloquent();

require __DIR__ . '/../app/routes.php';

autoload.php

PHP:

<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer/autoload_real.php';

return ComposerAutoloaderInitef0e99e009698b025ebca804f0e7eb6c::getLoader();

autoload_real.php

PHP:

<?php

// autoload_real.php @generated by Composer

class ComposerAutoloaderInitef0e99e009698b025ebca804f0e7eb6c
{
    private static $loader;

    public static function loadClassLoader($class)
    {
        if ('Composer\Autoload\ClassLoader' === $class) {
            require __DIR__ . '/ClassLoader.php';
        }
    }

    public static function getLoader()
    {
        if (null !== self::$loader) {
            return self::$loader;
        }

        spl_autoload_register(array('ComposerAutoloaderInitef0e99e009698b025ebca804f0e7eb6c', 'loadClassLoader'), true, true);
        self::$loader = $loader = new \Composer\Autoload\ClassLoader();
        spl_autoload_unregister(array('ComposerAutoloaderInitef0e99e009698b025ebca804f0e7eb6c', 'loadClassLoader'));

        $useStaticLoader = PHP_VERSION_ID >= 50600 && !defined('HHVM_VERSION') && (!function_exists('zend_loader_file_encoded') || !zend_loader_file_encoded());
        if ($useStaticLoader) {
            require_once __DIR__ . '/autoload_static.php';

            call_user_func(\Composer\Autoload\ComposerStaticInitef0e99e009698b025ebca804f0e7eb6c::getInitializer($loader));
        } else {
            $map = require __DIR__ . '/autoload_namespaces.php';
            foreach ($map as $namespace => $path) {
                $loader->set($namespace, $path);
            }

            $map = require __DIR__ . '/autoload_psr4.php';
            foreach ($map as $namespace => $path) {
                $loader->setPsr4($namespace, $path);
            }

            $classMap = require __DIR__ . '/autoload_classmap.php';
            if ($classMap) {
                $loader->addClassMap($classMap);
            }
        }

        $loader->register(true);

        if ($useStaticLoader) {
            $includeFiles = Composer\Autoload\ComposerStaticInitef0e99e009698b025ebca804f0e7eb6c::$files;
        } else {
            $includeFiles = require __DIR__ . '/autoload_files.php';
        }
        foreach ($includeFiles as $fileIdentifier => $file) {
            composerRequireef0e99e009698b025ebca804f0e7eb6c($fileIdentifier, $file);
        }

        return $loader;
    }
}

function composerRequireef0e99e009698b025ebca804f0e7eb6c($fileIdentifier, $file)
{
    if (empty($GLOBALS['__composer_autoload_files'][$fileIdentifier])) {
        require $file;

        $GLOBALS['__composer_autoload_files'][$fileIdentifier] = true;
    }
}

[NMe]

Verwijderd schreef op donderdag 4 januari 2018 @ 16:38:
Even de bestanden op een rijtje:

Leuk en aardig, maar wat heb je nou met de comments gedaan die je intussen hebt gehad? En dan met name de post van mcDavid in "PHP webshop uploaden naar webhost".

[Verwijderd]

mcDavid schreef op donderdag 4 januari 2018 @ 11:24:
[...]


Ja, debuggen. Zoek uit wat er gebeurt op de regel waarvan je die error krijgt. Zoek uit hoe je autoloader werkt. Zoek uit of de paden kloppen. Zonder iets te proberen ga je geen stap verder komen. Wij kunnen ook alleen maar speculeren.

Wat mij direct al triggert is het inconsistente hoofdlettergebruik in de paden, let er dus goed op of dat klopt. Classnames en namespaces zijn in PHP niet case-sensitive, maar paden op een linux-systeem wel. Als die niet overeen komen gaat het autoloaden dus vaak mis.

De boosdoener was inderdaad een hoofdletter, een stom klein foutje. De webshop doet het nu!
Bedankt iedereen!

[DJMaze]

@Verwijderd Je werkt dus blijkbaar op Windows OS?
Kijk eens of je de composer autoloader functionaliteit kan aanpassen met mijn code.
Dan vind je die problemen een stuk sneller.
Je kan ook een bug-report aanmaken bij Composer zodat ze dit Win32 probleem eens gaan oppakken.

Je moet dus wel alles nalopen, en ik hoop dat je geen hoofdletters in de DB gebruikt.
https://dev.mysql.com/doc...ier-case-sensitivity.html

[ Voor 22% gewijzigd door DJMaze op 04-01-2018 22:48 ]