[PHP] Het grote Laravel topic

[Qunix]

Vraagje,

Voor iedere pagina geef ik in de controllers wat specifieke data voor in de template.

PHP:

public function index()
{
    return view('page')->with('data', Model::data());
}

Nu heb ik ook data wat voor alle pagina's beschikbaar moet zijn (voor de header). Hoe kan ik dit het beste aanpakken? Ik gebruik Twig in Laravel.

Moet ik een view class maken en dat overal gebruiken waarbij ik specifieke data optioneel meestuur, en dat gebruiken in de controllers?
Of moet ik wat doen in App\Http\Controllers\Controller.php?

Hoe pakken jullie dit aan? In Blade gaat dit wat makkelijker aangezien je PHP mag gebruiken in de templates. Het is mij nu verboden om een class aan te roepen met zijn functies.

Thanks!

[ Voor 4% gewijzigd door Qunix op 02-11-2015 08:37 ]

[mbarie]

Bij blade templating bestaat er op de view facade de mogelijkheid om een variabele te sharen. Hierdoor is de waarde in elke template-context beschikbaar. Deze methode gebruik ik doorgaans in de constructor van mijn DashboardController (welke enkel binnen scope van ingelogde gebruikers werkt) om een user object beschikbaar te maken in de front end.

PHP:

View::share('var', $var);

Als ik deze pagina over Twig goed interpreteer zal je voor complexe global variables in Twig een extension moeten schrijven.

[ Voor 19% gewijzigd door mbarie op 02-11-2015 08:56 ]

[Qunix]

Dank!

Ik had de manual moeten lezen van https://github.com/barryvdh/laravel-twigbridge.
Daar kan ik global variables meesturen.

[kwaakvaak_v2]

mbarie schreef op maandag 02 november 2015 @ 08:55:
Bij blade templating bestaat er op de view facade de mogelijkheid om een variabele te sharen. Hierdoor is de waarde in elke template-context beschikbaar. Deze methode gebruik ik doorgaans in de constructor van mijn DashboardController (welke enkel binnen scope van ingelogde gebruikers werkt) om een user object beschikbaar te maken in de front end.

PHP:

View::share('var', $var);

Als ik deze pagina over Twig goed interpreteer zal je voor complexe global variables in Twig een extension moeten schrijven.

Nee hoor wat je daar leest is de Symfony2 documentatie.. Nu weet ik niet precies hoe de Laravel versie in de DIC hangt, of dat er een Facade voor is. Maar meestal is het een kwestie van iets als

code:

$twig = $container->get('Twig');
$twig->addGlobal('Name',$value);

Waarbij $twig of Twig_Environment terug geeft.

[naam]

Erhnam schreef op zaterdag 31 oktober 2015 @ 09:09:
Ik merk iets vreemds. Ik heb een simpele route geschreven:

code:

$app->get('/api/fever','FeedController@fever');
$app->post('/api/fever','FeedController@fever');

Als ik nu met een iPhone app probeer de restfull API uit te lezen dan redirect apache of de laravel route engine met een extra slash aan het einde. Zie access.log van apache.

code:

x.x.x.x - - [31/Oct/2015:09:05:26 +0100] "POST /lumen/public/index.php/api/fever/?api HTTP/1.1" 301 218 "-" "Reeder/2.6 CFNetwork/758.1.6 Darwin/15.0.0"
x.x.x.x - - [31/Oct/2015:09:05:26 +0100] "GET /index.php/api/fever?api HTTP/1.1" 200 96 "-" "Reeder/2.6 CFNetwork/758.1.6 Darwin/15.0.0"

De GET in dit geval gaat wel goed, maar de POST dus niet. Iemand enig idee. Zou dit aan de default htaccess liggen of het feit dat ik in de routes.php zowel een get en post doorstuur naar dezelfde controller?

Waarom stuur je zowel GET als POST naar dezelfde methode op een controller? (Los van het probleem wat jij beschrijft) het lijken mij 2 verschillende acties, het lijkt mij logischer om ze dan door te sturen naar een methode als getFever en postFever, zo heb je een duidelijkere scheiding.

[DimitryK]

Dag allemaal,

Ik zit met het volgende probleem. Ben momenteel bezig met het bouwen van een modulaire applicatie in Laravel. Ik heb een Core en Backend module, die altijd aan staan, deze zijn namelijk het hart van de applicatie. De Core module heeft een User model met basis functionaliteit.

Zodra ik een andere module laadt, zoals bijv. Blog. Dan wil ik het User model uitbreiden met de relaties en functies die de Blog module te bieden heeft, zonder het model expliciet uit te breiden als bijv BlogUser.

Ik heb gekeken naar het Decorator pattern, maar dit werkt niet naar behoren. Ik zou dan alsnog met mijn decorator class "Model" moeten extenden, want anders wordt het model niet gehydrate met de juiste properties. In andere woorden, in dat geval zou ik beter een BlogUser kunnen maken...

Vervolgens kwam iemand met de volgende link: http://stackoverflow.com/...e-class-method-at-runtime

Dit komt het dichts in de buurt bij wat ik wil. Ik vraag me dus af of Laravel een native functie heeft waarmee je bijv. via een bind methode een model kunt extenden, zonder het ook echt te extenden.

Heeft iemand suggesties over hoe ik dit het beste kan aanpakken?

Bvd

[Erulezz]

Ik ben een kleine API aan het realiseren in Lumen en ik weet even niet zo goed hoe ik dit efficient in Eloquent kan oplossen. Ik heb het volgende:

Model: Resort

code:

public function webcams()
    {
        return $this->hasMany('App\Webcam');
    }

Eloquent query Controller:

code:

return Resort::where('application_id', $application_id)
                ->active()
                ->where('country_id', $country_id)
                ->select('id','name')
                ->get();

Wat is de beste manier om het onderstaande in Eloquent te fixen? Ik heb het al wel in een simpele raw query maar ik wil graag van Eloquent gebruik maken Dus dat het resultaat zo wordt:

code:

[
  {
    "id": 1,
    "name": "Name 1",
    "webcams": 15
  },
  {
    "id": 2,
    "name": "Name 2",
    "webcams": 954
  },

Kan iemand mij hiermee op weg helpen?

[mbarie]

Erulezz schreef op dinsdag 03 november 2015 @ 18:41:
Ik ben een kleine API aan het realiseren in Lumen en ik weet even niet zo goed hoe ik dit efficient in Eloquent kan oplossen. Ik heb het volgende...

Als ik het probleem goed interpreteer staat de oplossing al eerder op deze pagina vermeld . Als je attributen externe data (die buiten de scope van het model zelf valt) toe wil voegen aan je JSON output kan dat zoals vermeld door Deviruchi in "[PHP] Het grote Laravel topic"

[ Voor 40% gewijzigd door mbarie op 04-11-2015 11:19 ]

[Erhnam]

Erulezz schreef op dinsdag 03 november 2015 @ 18:41:
Ik ben een kleine API aan het realiseren in Lumen en ik weet even niet zo goed hoe ik dit efficient in Eloquent kan oplossen. Ik heb het volgende:
Kan iemand mij hiermee op weg helpen?

Voor een mooie Json kan je het beste deze functie gebruiken:

code:

$result = Resort::where('application_id', $application_id)
                ->active()
                ->where('country_id', $country_id)
                ->select('id','name')
                ->get();

return response()->json($result);

[PatrickH89]

Voor een kleine API wellicht niet heel zinvol, maar misschien toch nuttig: http://fractal.thephpleague.com/transformers/

[Barryvdh]

Misschien leuk voor de mensen uit Brabant? Laravel MeetUp in Eindhoven: http://www.meetup.com/Laravel-Eindhoven/events/226490341/

Woensdag 18 november is de eerste MeetUp en ik zal dan zelf ook wat vertellen over packages ed

[Erulezz]

Er is een nieuwe versie van Homestead beschikbaar, o.a. met MySQL 5.7!

Over Homestead gesproken; weet iemand waarom het commando composer global require homestead verdwenen is uit de docs?

[Chris7]

Erulezz schreef op vrijdag 13 november 2015 @ 18:36:
Er is een nieuwe versie van Homestead beschikbaar, o.a. met MySQL 5.7!

Over Homestead gesproken; weet iemand waarom het commando composer global require homestead verdwenen is uit de docs?

Taylor zei ergens dat het voor veel mensen verwarrend was om ook een globaal homestead commando te hebben die in feite hetzelfde deed als Vagrant. Nu is het dus de bedoeling direct vagrant up/resume/destroy etc. direct aan te roepen vanuit de Homestead map. Al kan je er natuurlijk alsnog een globaal alias aan geven.

[CH4OS]

Erhnam schreef op woensdag 04 november 2015 @ 10:33:
[...]


Voor een mooie Json kan je het beste deze functie gebruiken:

code:

$result = Resort::where('application_id', $application_id)
                ->active()
                ->where('country_id', $country_id)
                ->select('id','name')
                ->get();

return response()->json($result);

return $result is dan voldoende, die returned namelijk ook een json op die manier. Of eventueel return Resort::blahblahblah natuurlijk.

[TheRicolaa10]

Aangezien ik graag een framework wilde leren, ben ik begonnen met Laravel omdat ik daar goede verhalen over hoorde. Heb meteen een aantal Laracasts opgepakt en gevolgd. Helaas kom ik er zelf niet meer uit.

Ik heb een controller en een model.

Model:

code:

namespace App\Models;

use DB;
use Illuminate\Database\Eloquent\Model;

class Programma extends Model
{
}

Controller:

code:

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Requests;
use App\Http\Controllers\Controller;
use App\Models\Programma;

class PagesController extends Controller
{
}

Ik krijg deze error, en ik begrijp niet helemaal waarom eerlijk gezegd.


Iemand die me de goede richting op kan wijzen?

[Stroopwafels]

Laravel 5 neem ik aan?
Heb al even niet meer met Laravel gewerkt maar heb je App\Models toegevoegd aan je composer.json bestand (autoload sectie)? Ook composer dump-autoload gedaan?

[TheRicolaa10]

Stroopwafels schreef op maandag 16 november 2015 @ 20:45:
Laravel 5 neem ik aan?
Heb al even niet meer met Laravel gewerkt maar heb je App\Models toegevoegd aan je composer.json bestand (autoload sectie)? Ook composer dump-autoload gedaan?

Laravel 5 inderdaad, ik dacht ergens gelezen te hebben dat hij alles automatisch autoload binnen de app folder?

[DirkZzZ]

TheRicolaa10 schreef op maandag 16 november 2015 @ 20:41:
Aangezien ik graag een framework wilde leren, ben ik begonnen met Laravel omdat ik daar goede verhalen over hoorde. Heb meteen een aantal Laracasts opgepakt en gevolgd. Helaas kom ik er zelf niet meer uit.

Ik heb een controller en een model.

Model:

code:

namespace App\Models;

use DB;
use Illuminate\Database\Eloquent\Model;

class Programma extends Model
{
}

Controller:

code:

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Http\Requests;
use App\Http\Controllers\Controller;
use App\Models\Programma;

class PagesController extends Controller
{
}

Ik krijg deze error, en ik begrijp niet helemaal waarom eerlijk gezegd.
[afbeelding]

Iemand die me de goede richting op kan wijzen?

Onder welke directory staat jouw Programma class?

[TheRicolaa10]

DirkZzZ schreef op maandag 16 november 2015 @ 21:27:
[...]


Onder welke directory staat jouw Programma class?

laravel/app/Models/Programma.php

[dennisschr17]

TheRicolaa10 schreef op maandag 16 november 2015 @ 20:48:
[...]


Laravel 5 inderdaad, ik dacht ergens gelezen te hebben dat hij alles automatisch autoload binnen de app folder?

Dit hangt ervan af hoe je dit in de composer.json specificeerd. Standaard staat hierin:

JavaScript:

"autoload": {
        "classmap": [
            "database"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },

Dit betekend dat in de app directory de mapnamen de namespaces bepalen (psr-4 standaard), waarbij de namespace begint met App\. Bestanden in app/Controllers moeten dus de namespace App\Controllers hebben.

Andere soorten betekenen iets anders. "classmap" betekend volgens mij dat de naam van de class ook de naam van het bestand moet zijn.

[DirkZzZ]

TheRicolaa10 schreef op maandag 16 november 2015 @ 21:31:
[...]


laravel/app/Models/Programma.php

Dan zou het gegeven de code welke hier gepost is moeten werken. Als je de code op github kan,mag en wil gooien dan zou ik best even willen kijken voor je.

[afraca]

Ik heb een bug report gemaakt op Github over een routing issue, maar Graham Campbell blijft hem maar sluiten omdat hij het probleem niet begrijpt

https://github.com/larave...35#issuecomment-158348668

Barry, heb jij niet wat rechten daar om dat even OPEN te houden?

edit: I stand corrected... PEBKAC

[ Voor 6% gewijzigd door afraca op 20-11-2015 12:32 ]

[Erhnam]

Ik heb een vraag. Via mijn controllers roep ik alle views aan en stuur ik de data mee. Echter zou ik in mijn master.blade template in het top menu ook gebruik willen maken van dynamische content. Deze include ik namelijk in alle views. Hoe kan ik vanuit mijn master blade template de data uit een controller ophalen?

[Stroopwafels]

Erhnam schreef op dinsdag 01 december 2015 @ 13:31:
Ik heb een vraag. Via mijn controllers roep ik alle views aan en stuur ik de data mee. Echter zou ik in mijn master.blade template in het top menu ook gebruik willen maken van dynamische content. Deze include ik namelijk in alle views. Hoe kan ik vanuit mijn master blade template de data uit een controller ophalen?

Ik zou hiervoor een view composer gebruiken.
http://laravel.com/docs/5.1/views#view-composers

[frietsje]

Dag mensen,

inmiddels ben ik een tijdje bezig met laravel en het bevalt me prima

Nu heb ik een project dat op een shared server gaat draaien (ja, dat is een andere discussie )
Op de server heb ik de mappenstructuur dus aangepast:

• Laravel (app, bootstrap etc)
• Public_html (wat normaal in public van laravel zit)

Dit werkt prima zo, en de scheiding van de core laravel bestanden buiten de public map is natuurlijk prima.

Echter, op mijn (lokale) ontwikkelomgeving heb ik het nog op de normale manier staan. Niet echt ideaal dus met syncen. Tevens wil ik de boel via git gaan beheren tussen lokaal en server.

Is het handig om lokaal dan ook dezelfde structuur aan te houden, en hoe verander ik dat zonder de al bestaande git/composer etc in de war te schoppen? Gewoon alles vanuit de laravel folder draaien?

[PatrickH89]

Als je Git wilt gebruiken zul je lokaal wel op dezelfde manier moeten werken. Composer zul je altijd vanuit de directory moeten draaien waar de composer.json in staat.

[_Moe_]

@frietsje: Kan je op je shared server de publieke map niet wijzigen?

[Chris7]

frietsje schreef op woensdag 16 december 2015 @ 14:57:

Is het handig om lokaal dan ook dezelfde structuur aan te houden, en hoe verander ik dat zonder de al bestaande git/composer etc in de war te schoppen? Gewoon alles vanuit de laravel folder draaien?

Ja, het is handig dit lokaal ook te doen, je wilt zou weinig mogelijk verschillen tussen lokaal en online. Je zou het misschien zoals hier kunnen doen, maar dan zonder de extra subfolder onder public_html. Daarbij verander je in feite dus de locatie van je /public map. Composer bestanden blijven gewoon in de laravel map, zoals je nu ook al hebt.

Overigens @ shared server, bij bijvoorbeeld Digital Ocean heb je al een server voor 5$ per maand.

[frietsje]

Ik denk niet dat ik de shared folder kan wijzigen, maar wellicht dat op den duur toch de site gaat verhuizen naar een andere server. Dan ga ik het lokaal inderdaad ook even zo instellen thnx

[Barryvdh]

frietsje schreef op vrijdag 18 december 2015 @ 11:57:
Ik denk niet dat ik de shared folder kan wijzigen, maar wellicht dat op den duur toch de site gaat verhuizen naar een andere server. Dan ga ik het lokaal inderdaad ook even zo instellen thnx

Heb je wel SSH toegang? Kan je geen symlink maken?

[frietsje]

Barryvdh schreef op vrijdag 18 december 2015 @ 18:41:
[...]

Heb je wel SSH toegang? Kan je geen symlink maken?

Het kan soms zo makkelijk zijn

[Erulezz]

Laravel 5.2

https://twitter.com/laravelphp/status/678993007903813632

laravelphp: World, meet Laravel 5.2: https://t.co/wv8nQjAhe7 💖

Heeft er iemand al een 5.1 installatie overgezet naar 5.2?

[mbarie]

Wilde het doen, maar composer faalde bij het binnenhalen van 5.2 omdat bepaalde classes niet geresolved konden worden. Over een paar dagen weer eens proberen .

[mbenjamins]

Erulezz schreef op dinsdag 22 december 2015 @ 13:13:
Laravel 5.2

https://twitter.com/laravelphp/status/678993007903813632


[...]


Heeft er iemand al een 5.1 installatie overgezet naar 5.2?

Ik heb het geprobeerd maar kreeg allemaal errors.
Ik denk dat nog niet alle packages is bijgewerkt voor Laravel 5.2.

[Barryvdh]

mbenjamins schreef op woensdag 23 december 2015 @ 08:48:
[...]

Ik heb het geprobeerd maar kreeg allemaal errors.
Ik denk dat nog niet alle packages is bijgewerkt voor Laravel 5.2.

Ik ben er ook nog niet aan toegekomen. De meeste al wel, maar ze hebben toch weer wat dingen aangepast (filters verwijderd, events zijn objecten nu ed). Maar de populairste zouden moeten werken op 5.2

[Chris7]

mbenjamins schreef op woensdag 23 december 2015 @ 08:48:
[...]

Ik heb het geprobeerd maar kreeg allemaal errors.
Ik denk dat nog niet alle packages is bijgewerkt voor Laravel 5.2.

Wel de upgrade guide gevolgd? Het is niet zomaar een drop-in die je kan toepassen op een bestaande installatie, is zoals Barry zegt wel een en ander gewijzigd.

[ Voor 16% gewijzigd door Chris7 op 23-12-2015 11:25 ]

[Barryvdh]

Chris7 schreef op woensdag 23 december 2015 @ 11:24:
[...]

Wel de upgrade guide gevolgd? Het is niet zomaar een drop-in die je kan toepassen op een bestaande installatie, is zoals Barry zegt wel een en ander gewijzigd.

En net alle 'lists(..)' veranderd naar 'lists(..)->toArray()', kunnen we nu alles weer veranderen naar 'pluck(..)->toArray()'. Had dan gewoon die lists() laten staan

[Erulezz]

Ben nu een project aan het overzetten naar 5.2. De Illuminate\Html werkt al niet meer vanwege het volgende:

The service container's bindShared method has been deprecated in favor of the singleton method.

LaravelCollective\Html is nu wel bijgewerkt voor 5.2 en dat werkt ook. Alleen ik wil nu mijn config/app.php bijwerken zoals die op GitHub staat en nu is de Input Facade daar weer uit verdwenen. Als ik die terugplaats werkt het weer. Volgens mij wordt het tijd om van alle Forms gewoon standaard HTML te maken want misschien zit ik hier met 5.3 weer mee te klooien. Soms snap ik alle keuzes niet maar goed

//

Hoe handelen jullie Form Model binding af in views zonder de FormFacade?

[ Voor 6% gewijzigd door Erulezz op 23-12-2015 17:56 ]

[Anoniem: 111703]

Barryvdh schreef op woensdag 23 december 2015 @ 11:30:
[...]


En net alle 'lists(..)' veranderd naar 'lists(..)->toArray()', kunnen we nu alles weer veranderen naar 'pluck(..)->toArray()'. Had dan gewoon die lists() laten staan

Geniaal, met name omdat ze ditzelfde geintje met de release van L5.1 ook zoiets geflikt hadden. Nu dus weer hetzelfde gedoe.

Mooi framework, goede ideeën. Verschrikkelijke volatiliteit in de code waardoor ze nog steeds niet semver kunnen doen. Echt jammer, want daardoor is elke minor update aan het framework even "eng" als een major update.

[Barryvdh]

Anoniem: 111703 schreef op zondag 27 december 2015 @ 18:02:
[...]


Geniaal, met name omdat ze ditzelfde geintje met de release van L5.1 ook zoiets geflikt hadden. Nu dus weer hetzelfde gedoe.

Mooi framework, goede ideeën. Verschrikkelijke volatiliteit in de code waardoor ze nog steeds niet semver kunnen doen. Echt jammer, want daardoor is elke minor update aan het framework even "eng" als een major update.

Ja daar refereerde ik dus aan inderdaad

[sander0]

Anoniem: 111703 schreef op zondag 27 december 2015 @ 18:02:
[...]


Geniaal, met name omdat ze ditzelfde geintje met de release van L5.1 ook zoiets geflikt hadden. Nu dus weer hetzelfde gedoe.

Mooi framework, goede ideeën. Verschrikkelijke volatiliteit in de code waardoor ze nog steeds niet semver kunnen doen. Echt jammer, want daardoor is elke minor update aan het framework even "eng" als een major update.

Ik geef je niet helemaal ongelijk, maar er is een reden dat L5.1 een LTS release is. Zodat je zonder problemen de komende tijd bij L5.1 kunt blijven.

[kwaakvaak_v2]

Barryvdh schreef op woensdag 23 december 2015 @ 11:30:
[...]


En net alle 'lists(..)' veranderd naar 'lists(..)->toArray()', kunnen we nu alles weer veranderen naar 'pluck(..)->toArray()'. Had dan gewoon die lists() laten staan

Dat soort 'gedoe' is één van de belangrijkste redenen waarom ik voor zakelijke toepassingen hier intern een negatief advies heb gegeven over Laravel.

[adis]

kwaakvaak_v2 schreef op maandag 28 december 2015 @ 12:13:
[...]


Dat soort 'gedoe' is één van de belangrijkste redenen waarom ik voor zakelijke toepassingen hier intern een negatief advies heb gegeven over Laravel.

Idd die autocratie zonder onderbouwing

[Cartman!]

sander0 schreef op maandag 28 december 2015 @ 09:35:
[...]


Ik geef je niet helemaal ongelijk, maar er is een reden dat L5.1 een LTS release is. Zodat je zonder problemen de komende tijd bij L5.1 kunt blijven.

Dan begrijp je semantic versioning niet, een 5.2 zou in principe niks mogen breken.

[Erhnam]

Wat is een nette manier om global variables te kunnen gebruiken in alle controllers en views zonder vanuit iedere controller eerst het te moeten aanroepen. Ideaal zou ik de config settings (Theme, taal, administratie email, etc.) uit de database willen halen om ze daarna overal te kunnen gebruiken. Hoe doen jullie dit?

[Siebsel]

Check de docs eens: https://laravel.com/docs/5.2/views

Zowel "View composers" als "Sharing Data With All Views" zijn van toepassing

[Barryvdh]

Cartman! schreef op maandag 28 december 2015 @ 12:55:
[...]

Dan begrijp je semantic versioning niet, een 5.2 zou in principe niks mogen breken.

Alleen volgt Laravel geen SemVer.

[Cartman!]

Barryvdh schreef op maandag 28 december 2015 @ 13:01:
[...]

Alleen volgt Laravel geen SemVer.

Dat is nogal opvallend dan in een tijd waarbij vrijwel alle frameworks en libraries werken met semver. Ze leggen t probleem van versioning daarmee volledig bij de gebruiker en dan krijg je vanzelf scheve gezichten. Voor mij ook een reden om t geheel minder serieus te nemen.

[ Voor 6% gewijzigd door Cartman! op 28-12-2015 13:15 ]

[Barryvdh]

Cartman! schreef op maandag 28 december 2015 @ 13:07:
[...]

Dat is nogal opvallend dan in een tijd waarbij vrijwel alle frameworks en libraries werken. Ze leggen t probleem van versioning daarmee volledig bij de gebruiker. Voor mij ook een reden om t geheel minder serieus te nemen.

Tja, voordeel is dat ze wat makkelijker 'onlogische' dingen gewoon deprecaten en daarna eruit halen. lists() is bijv. deprecated in 5.2, verwijderd in 5.3, wat je dus een jaar geeft om aan te passen. Andere wijzigingen, zoals collections ipv array teruggeven, of key preservation bij bepaalde methods, kunnen achteraf een stuk logischer zijn. Maar met SemVer zou je daar een stuk langer aan vast zitten.

Ze hebben voor de 'zakelijke toepassingen' dus juist die LTS versie (5.1) gereleased, zodat je 2 jaar bug fixes/3 jaar security updates hebt.

Daarnaast zijn de meeste updates niet erg ingrijpend, dus als je het nodig hebt kan je gewoon de upgrade guide volgen: https://laravel.com/docs/5.2/upgrade

[Cartman!]

Barryvdh schreef op maandag 28 december 2015 @ 13:17:
[...]

Tja, voordeel is dat ze wat makkelijker 'onlogische' dingen gewoon deprecaten en daarna eruit halen. lists() is bijv. deprecated in 5.2, verwijderd in 5.3, wat je dus een jaar geeft om aan te passen.

Je moet dus extreem goed opletten met je dependencies omdat ze negeren wat de rest van de industrie doet. Daarnaast, als je echt onlogische dingen erin hebt zitten hadden ze er misschien wat langer over na moeten denken

Andere wijzigingen, zoals collections ipv array teruggeven, of key preservation bij bepaalde methods, kunnen achteraf een stuk logischer zijn. Maar met SemVer zou je daar een stuk langer aan vast zitten.

Semver zegt helemaal niks over tijd, het staat je vrij om regelmatig nieuwe major versies uit te brengen (kijk bijv naar Chrome).

Ze hebben voor de 'zakelijke toepassingen' dus juist die LTS versie (5.1) gereleased, zodat je 2 jaar bug fixes/3 jaar security updates hebt.

Dat is zeker netjes maar dat wijzigt niks aan het feit dat het nogal onhandig is dat ze zo zwaar wegen aan versienummers en daarmee afwijken van de rest.

Daarnaast zijn de meeste updates niet erg ingrijpend, dus als je het nodig hebt kan je gewoon de upgrade guide volgen: https://laravel.com/docs/5.2/upgrade

Ik vind dat flink wat wijzigingen voor een "minor" version. Persoonlijk ben ik zeer gecharmeerd van hoe Symfony dit oplost met hun Backwards Compatibility Promise

[ Voor 3% gewijzigd door Cartman! op 28-12-2015 13:40 ]

[Erhnam]

Siebsel schreef op maandag 28 december 2015 @ 12:58:
Check de docs eens: https://laravel.com/docs/5.2/views

Zowel "View composers" als "Sharing Data With All Views" zijn van toepassing

Werkt het dan ook in alle controllers? Ik was meer op zoek naar constants vanuit de database.. Zoek wel even verder. Dank!

[Barryvdh]

Extreem goed opletten is ook een beetje overdreven, je moet gewoon 5.1.x laten staan zolang je 5.1 wil gebruiken.
En inderdaad, je kan elk half jaar een major version uitbrengen ipv minor, maar dat heeft precies hetzelfde effect. Ik denk ook dat ze het niet expres doen om mensen te irriteren.

Het lijkt me daarnaast ook een stuk moeilijker om een framework met duizenden gebruikers en tientallen componenten zowel cutting-edge te houden, regelmatig nieuwe features toe te voegen én BC te houden.

Respect voor Symfony dat het hen wel lukt om redelijk BC te blijven, maar als ik af en toe wat issues kijkt, moeten ze zich wel in wat moeilijke bochten wurmen om dat zo te houden, wat er weer voor zorgt dat een feature niet doorgevoerd wordt, of minder omslachtig.

Maargoed, je hoeft het niet gebruiken. Ze pretenderen nergens wel SemVer te gebruiken en geven duidelijk aan hoelang ze wel support geven. Dus als voor jou Symfony beter is, kan je dat gebruiken.

[Chris7]

Mja, ik zie het probleem niet zo met de versienummers. Sure, semver is tegenwoordig veel gebruikt, maar lang niet ieder product gebruikt het ook. Daarnaast is het vooral iets met de verwachtingen van gebruikers: een 2.0 versie zal wel dingen breken als ik nu 1.x heb. Dat er bij Laravel ook dingen veranderen in "minor" releases is hoe zij hun versienummering doen. Als je dat weet (en dat is vrij duidelijk) dan is het verder geen probleem.

Cartman! schreef op maandag 28 december 2015 @ 13:39:
[...]

Je moet dus extreem goed opletten met je dependencies omdat ze negeren wat de rest van de industrie doet. Daarnaast, als je echt onlogische dingen erin hebt zitten hadden ze er misschien wat langer over na moeten denken

Dit snap ik niet, je hoeft alleen voor Laravel op te letten, elke andere dependency die je hebt is daarvan toch onafhankelijk? En "extreem goed opletten" is ook wel te nuanceren, dat impliceert voor mijn gevoel dat je niet zomaar een composer update zou kunnen draaien, terwijl dat niet het geval is. De standaard Laravel installatie zet je niet zomaar over naar een nieuwe versie, dat moet je zelf handmatig doen. En tussen versies veranderen dingen, maar dan volg je de upgrade guide en ben je in een kwartiertje klaar (valt over het algemeen reuze mee).

Semver zegt helemaal niks over tijd, het staat je vrij om regelmatig nieuwe major versies uit te brengen (kijk bijv naar Chrome).

Wat ik daarbij grappig is dat veel gebruikers daar ook weer over zeuren, met name bij Firefox kom ik het regelmatig tegen. "Waarom moeten ze nou al naar versie 40, er verandert toch niet zo veel". Waarbij ik me af vraag of die browsers ook strikt semver volgen, in principe is een nieuwe feature geen breaking change dus zou het prima een minor release kunnen zijn. Maar ze hebben er voor gekozen gewoon telkens het versienummer op te hogen.

Er zijn verschillende meningen wat betreft de versienummering, ik vind het niet zo'n belangrijk onderwerp . Het is vooral iets met verwachtingsmanagement bij de gebruiker, maar of het nou 5.2 heet of 6.0 zal mij worst wezen. Als een product (niet per se een library, kan ook een programma zijn) zich maar niet zomaar bijwerkt naar een versie die dingen breekt maar ik daar zelf voor moet kiezen vind ik het prima.

[Cartman!]

Stel er staat ergens een plugin/provider die Laravel 5.1 wil zou ik verwachten dat ie ook op 5.2 werkt maar daar kun je die niet van op aan dus moet je daar veel meer bij opletten dan als ze wel semver zouden volgen, het houdt dus niet enkel op bij het versienummer van Laravel zelf.

Blijkbaar zal bij Firefox ook een BC break zijn, zij zullen vast wel weten hoe het werkt daar lijkt me (zelfde geldt voor Google Chrome).

Dit is slechts 1 van de redenen waarom ik Laravel altijd links heb laten liggen en waarschijnlijk ook zal blijven doen, het kan me gewoon nog steeds niet overtuigen.

Semver is wat mij betreft onderdeel van een bepaalde manier van werken net als coding standards bijvoorbeeld. Het zou gewoon veel handiger zijn als iedereen t zelfde doet. Dat laatste betekent niet dat het altijd zo is als ik het wil maar daar wen je meer dan snel genoeg aan.

[ Voor 20% gewijzigd door Cartman! op 28-12-2015 14:35 ]

[adis]

Chris7 schreef op maandag 28 december 2015 @ 14:19:

[...]


Dit snap ik niet, je hoeft alleen voor Laravel op te letten, elke andere dependency die je hebt is daarvan toch onafhankelijk? En "extreem goed opletten" is ook wel te nuanceren, dat impliceert voor mijn gevoel dat je niet zomaar een composer update zou kunnen draaien, terwijl dat niet het geval is. De standaard Laravel installatie zet je niet zomaar over naar een nieuwe versie, dat moet je zelf handmatig doen. En tussen versies veranderen dingen, maar dan volg je de upgrade guide en ben je in een kwartiertje klaar (valt over het algemeen reuze mee).


[...]

Hier kan ik niet helemaal mee eens zijn. Steeds meer libraries gebruiken ook Laravel componenten. Dus je kan zelfs niet zomaar vanuit gaan dat je de dependencies kan updated en Laravel op een bepaalde versie laten staan.

Gelukkig kan composer helpen (update ongedaan maken) anders was het drama helemaal compleet..

[Barryvdh]

Kaartjes zijn weer te koop, nu nog met korting!
http://laracon.eu/2016/

[CH4OS]

Is er een handige / snelle manier om de sessies van een specifieke gebruiker te verwijderen en daarmee dus geforceerd uit te loggen, als de user bijvoorbeeld verwijderd wordt? Ik kom zo op het eerste oog niets bruikbaars tegen voor Laravel 5.1.

[Barryvdh]

CptChaos schreef op dinsdag 19 januari 2016 @ 14:32:
Is er een handige / snelle manier om de sessies van een specifieke gebruiker te verwijderen en daarmee dus geforceerd uit te loggen, als de user bijvoorbeeld verwijderd wordt? Ik kom zo op het eerste oog niets bruikbaars tegen voor Laravel 5.1.

Dat zit wel in Laravel 5.2 volgens mij, daar wordt bij de session database driver ook het user_id opgeslagen nu. Je kan wel de remember_token verwijderen, maar dat is alleen voor het inloggen met cookies, niet direct.

Je kan natuurlijk wel checken of je user object bestaat in een filter/middleware (of bepaalde flag wel/niet heeft), en anders de gebruiker geforceerd uitloggen.

[CH4OS]

Jep, Laravel 5.2 heeft het wel, maar ik heb mijn app nog niet geupdate naar 5.2, ik begreep de upgrade guide geloof ik anders dan aanvankelijk bedoeld werd.

EDIT: Toch maar weer even gekeken naar upgraden naar Laravel 5.2, ik krijg nu deze error:

Problem 1
- Installation request for symfony/dom-crawler ~3.0 -> satisfiable by symfony/dom-crawler[3.0.x-dev, 3.1.x-dev, v3.0.0, v3.0.0-BETA1, v3.0.1].

Terwijl ik in de require-dev, volgens de handleiding, de twee packages heb opgenomen:

code:

    "require-dev": {
        "fzaninotto/faker": "~1.4",
        "mockery/mockery": "0.9.*",
        "phpunit/phpunit": "~4.0",
        "phpspec/phpspec": "~2.1",
        "symfony/dom-crawler": "~3.0",
        "symfony/css-selector": "~3.0"
    },

Geen idee dus, wat ik nu mis waardoor het niet werkt?

EDIT2:
Heb het gok ik al gevonden... Moet Laravel zelf dan natuurlijk nog wel op Laravel 5.2 zetten...

Al heb ik nu wel de bekende bug met de post-update-cmd en de clear-compiled opdracht.

[Symfony\Component\Debug\Exception\FatalThrowableError]
Fatal error: Class 'Illuminate\Routing\ControllerServiceProvider' not found

EDIT3: Ah, daar had ik even in de documentatie overheen gelezen, die class is er met Laravel 5.2 niet meer. Upgraden is voltooid!

[ Voor 91% gewijzigd door CH4OS op 19-01-2016 15:43 ]

[mclegodude]

Is het normaal dat ik bij een schone install, de storage/* en de bootstrap/cache map moet chmodden naar 777? als ik dat niet doe (helemaal geen aanpassing) krijg ik een 500.
als ik de logs map alleen naar 777 doe krijg ik een Whoops pagina met een file permission denied error...

777 vind ik een beetje eng tbh...

[Barryvdh]

mclegodude schreef op vrijdag 22 januari 2016 @ 00:02:
Is het normaal dat ik bij een schone install, de storage/* en de bootstrap/cache map moet chmodden naar 777? als ik dat niet doe (helemaal geen aanpassing) krijg ik een 500.
als ik de logs map alleen naar 777 doe krijg ik een Whoops pagina met een file permission denied error...

777 vind ik een beetje eng tbh...

Directory Permissions
After installing Laravel, you may need to configure some permissions. Directories within the storage and the bootstrap/cache directories should be writable by your web server or Laravel will not run. If you are using the Homestead virtual machine, these permissions should already be set.

Ze moeten schrijfbaar zijn door de webserver (en je cli user). Dus je kan ze ook aan de www-data of apache oid groep toevoegen.

[mclegodude]

Oké, doe ik dat, Thanks

[Erulezz]

$request->format(); werkt hier niet helemaal lekker. Ik krijg echt altijd "html" terug terwijl de accept request headers toch echt "image/webp,image/*,*/*;q=0.8" zijn. Als ik dit handmatig doe;

code:

$request->header('Accept');

Dan krijg ik wel de juiste headers terug, maar volledig. Doe ik wat verkeerd met die request->format() of werkt dat niet zo? Deze manier werkt ook prima maar als ik gewoon html,json of image als header kan terugkrijgen kan ik het net wat mooier verwerken.

//

De default response van $request->format() is ook html zie ik nu ( https://laravel.com/api/5...equest.html#method_format ), dus ik krijg via die manier niks terug.

[ Voor 15% gewijzigd door Erulezz op 03-02-2016 16:23 ]

[Dannisi]

Ik heb een bizar probleem met Laravel 5.1
Ik draai Apache 2.4 op Windows 10 met de DocumentRoot in D:\www
Daarin heb ik meerdere Laravel projecten, laten we ze project1 en project2 noemen. Soms krijg ik errors in de laravel.log van project2:

code:

[2016-02-05 03:17:51] local.ERROR: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'project1.media' doesn't exist in D:\www\project2\vendor\laravel\framework\src\Illuminate\Database\Connection.php:319

En dat klopt, want die tabel bestaat idd niet in project1, maar hoe komt project2 aan die database naam?
Ik heb NIKS van project1 naar project2 gekopieerd, gewoon netjes een nieuw Laravel project gemaakt. En dit gebeurt ook soms, niet bij elke pagina, of elke keer bij deze query.

[TheNephilim]

Hmmm, alleen de homestead box upgraden is niet genoeg. Moet ik ook de homestead scripts zelf updaten om PHP7 te kunnen gebruiken?

[Chris7]

TheNephilim schreef op vrijdag 05 februari 2016 @ 10:04:
Hmmm, alleen de homestead box upgraden is niet genoeg. Moet ik ook de homestead scripts zelf updaten om PHP7 te kunnen gebruiken?

https://laravel.com/docs/5.1/homestead#upgrading-to-php-7 ?

[TheNephilim]

Chris7 schreef op vrijdag 05 februari 2016 @ 15:34:
[...]


https://laravel.com/docs/5.1/homestead#upgrading-to-php-7 ?

Moet je dat nog doen met de laatste versie? PHP 7 is nu standaard toch?

[Chris7]

TheNephilim schreef op vrijdag 05 februari 2016 @ 15:46:
[...]

Moet je dat nog doen met de laatste versie? PHP 7 is nu standaard toch?

Ja, voor nieuwe installaties wel, maar zo te zien moet je om je huidige installatie te upgraden de Homestead repository opnieuw clonen (dan krijg je dus een nieuwe Vagrantfile), waarbij je dus een nieuwe box krijgt.

[patricks8]

Hallo allemaal,

Voor een nieuw project ben ik opzoek naar een package die permissies heeft die per gebruiker in te stellen zijn (dus zonder rol als admin etc...). Nu ben ik het internet aan het afstruinen, maar kom eigenlijk alleen maar packages tegen die permissies koppelen aan een rol en een rol koppelen aan een gebruiker.
Weten jullie een beschikbare package of zal ik dit zelf moeten ontwikkelen?

[Janoz]

Zolang je meerdere rollen aan een gebruiker kunt koppelen is er toch geen probleem? Desnoods neem je dan 1 permissie per rol. Dan heb je precies het effect wat jij wilt.

[gamer13]

patricks8 schreef op maandag 08 februari 2016 @ 13:41:
Hallo allemaal,

Voor een nieuw project ben ik opzoek naar een package die permissies heeft die per gebruiker in te stellen zijn (dus zonder rol als admin etc...). Nu ben ik het internet aan het afstruinen, maar kom eigenlijk alleen maar packages tegen die permissies koppelen aan een rol en een rol koppelen aan een gebruiker.
Weten jullie een beschikbare package of zal ik dit zelf moeten ontwikkelen?

Met bijvoorbeeld Sentinel (Sentry) kun je permissies voor zowel groepen als gebruikers instellen.

[patricks8]

Janoz schreef op maandag 08 februari 2016 @ 13:44:
Zolang je meerdere rollen aan een gebruiker kunt koppelen is er toch geen probleem? Desnoods neem je dan 1 permissie per rol. Dan heb je precies het effect wat jij wilt.

Maar dat is een beetje omslachtig . Dus als er een alternatief is, wil ik deze graag gebuiken. Anders zal het de manier worden zoals jij bedoeld inderdaad

[Janoz]

Ik denk eerder dat je eis zelf eerder voor veel omslachtigheid zorgt. Uiteindelijk zul je zien dat veel permissies altijd samen gebruikt gaan worden waardoor je die toch vaak beiden toe gaat kennen. (Denk aan het "Wijzigen van X', over het algemeen zal dat vaak in combinatie met de permissie "Lezen van X" gaan) waardoor die tussenliggende laag toch eigenlijk helemaal niet zo onhandig is.

[patricks8]

Dat ben ik wel met je eens. Normaal gebruik ik dat ook. Maar degene voor wie ik het project doe, wil graag per gebruiker de permissies kunnen instellen. Maar ik denk dat ik maar moet overtuigen om rollen te gaan gebruiken.

[ Voor 18% gewijzigd door patricks8 op 08-02-2016 14:13 ]

[gamer13]

patricks8 schreef op maandag 08 februari 2016 @ 14:12:
Dat ben ik wel met je eens. Normaal gebruik ik dat ook. Maar degene voor wie ik het project doe, wil graag per gebruiker de permissies kunnen instellen. Maar ik denk dat ik maar moet overtuigen om rollen te gaan gebruiken.

Wat vaak wel gebeurt is dat je initieel dus een gebruiker toekent aan een rol/groep, waarna je de rechten per gebruiker nog eens kan fine-tunen.

[CH4OS]

Misschien een stomme vraag, maar is Sentinel ook te gebruiken enkel om groups / permissions te regelen voor users? Dat is althans het enige wat ik zou willen gebruiken van Sentinel, maar zo te lezen vangt Sentinel ook het registratie / activation proces af, wat ik in mijn webapp eigenlijk niet wil (en toch al (anders) heb). En Reminders of Persistances (?) hoef ik niet. Ook die tabellen zie ik dan liever verdwijnen uit de database. Die kan ik met de hand wel verwijderen, dat is geen probleem, maar ik hoop dat ik dan niet ergens tegenaanloop.

[ Voor 32% gewijzigd door CH4OS op 08-02-2016 23:22 ]

[TJVB]

@Patricks8, ik bedacht me ineens dat ik iets in mijn bookmarks had staan. Misschien is dit handig: https://github.com/spatie/laravel-permission

[Krilo_89]

Dannisi schreef op vrijdag 05 februari 2016 @ 04:32:
Ik heb een bizar probleem met Laravel 5.1
Ik draai Apache 2.4 op Windows 10 met de DocumentRoot in D:\www
Daarin heb ik meerdere Laravel projecten, laten we ze project1 en project2 noemen. Soms krijg ik errors in de laravel.log van project2:

code:

[2016-02-05 03:17:51] local.ERROR: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'project1.media' doesn't exist in D:\www\project2\vendor\laravel\framework\src\Illuminate\Database\Connection.php:319

En dat klopt, want die tabel bestaat idd niet in project1, maar hoe komt project2 aan die database naam?
Ik heb NIKS van project1 naar project2 gekopieerd, gewoon netjes een nieuw Laravel project gemaakt. En dit gebeurt ook soms, niet bij elke pagina, of elke keer bij deze query.

Kan het zijn dat je cache bestanden gedeeld zijn? Ik weet bijv. van CakePHP sites, dat wanneer deze op dezelfde server staan en je niets aan je corefiles aanpast, dan worden cache files aangemaakt met myapp_ als prefix. Wanneer je 2 sites hebt met dezelfe prefix, dan gaat dit fout en krijg je errors op verkeerde sites te zien etc.
Waarschijnlijk moet jij ergens je prefix voor je cache nog aanpassen, daarom krijg je errors te zien van de andere site.

-edit-
Dit dus: http://laravel-recipes.co.../using-a-cache-key-prefix

[ Voor 3% gewijzigd door Krilo_89 op 09-02-2016 12:11 ]

[Dannisi]

Die staan idd allebei op

code:

'prefix' => 'laravel',

Ik ga dat eens testen, bedankt

[Matis]

Ik heb een stukje legacy dat mijn laravel website nog op de oude manier benaderd: index.php?projName=PROJECT_NAME&version=VERSION_NUMBER
Dit resulteert in een kale index pagina, zonder css en js.

Ik probeer deze get af te vangen en te routen naar de juiste controller:

PHP:

Route::get('project/{pname}/version/{vname}', [
    'as' => 'versionShow',
    'uses' => 'VersionController@show'
]);

Hiervoor heb ik de volgende Route geregistreerd in de routes.php

PHP:

Route::get('index?projName={pname}&version={vname}', 'VersionController@show');

Ik krijg geen match op de route en het script valt gewoon door de files heen. Ook het spelen met de volgorde van de route(s) brengt geen soelaas.
Wie kan mij de gouden tip geven?

[gamer13]

Een route in laravel maakt niet gebruik van de query string. De query string komt namelijk in de \Input::get() terecht, wat je in je controller kunt gebruiken.

[Scotix]

Je zou het in je index route kunnen opvangen;

PHP:

Route::get('/', function(){
if(Input::get('projName') && Input::get('version')){
// redirect naar je controller
}
});

[Scotix]

Nou, schiet mij maar lek! Het lijkt er op dat ik alles heb uitgesloten (?) maar dit blijft fout gaan.

Ik heb een Laravel app (5.1.28);

dev omgeving:
php 5.6.13
mysql 5.6.19

productie omgeving:
php 5.6.16
mysql 5.5.27

MySQL:

CREATE TABLE testquestions (  
  id bigint(20) UNSIGNED NOT NULL,  
  testquestiongroup_id bigint(20) NOT NULL,  
  description varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,  
  type varchar(255) COLLATE utf8_unicode_ci NOT NULL,  
  created_at timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',  
  updated_at timestamp NOT NULL DEFAULT '0000-00-00 00:00:00'  
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

De database content is op de dev en productie omgeving precies hetzelfde.

Maar dan draai ik de volgende code;

PHP:

$question = new Question();  
$question->testquestiongroup_id = $questiongroup->id;  
$question->save();

Wat gaat er goed; er wordt een nieuwe database row toegevoegd in de testquestions-table.
Wat gaat er niet goed; de ID welke in het $question object wordt geplaatst is verkeerd. Elke keer wordt er een verkeerde ID in geplaatst, het rare is dat dit wel steeds dezelfde ID is.
Maar dit gebeurt alleen op de productie omgeving. Op de dev omgeving gaat dit goed.

En dan het rare; ik draai de volgende code na $question->save()

PHP:

var_dump($question);  
var_dump(\DB::getPdo()->lastInsertId());

lastInsertId() geeft de goede ID terug en $question->id heeft weer de verkeerde ID.

[Thijmen]

Scotix schreef op vrijdag 12 februari 2016 @ 10:56:
Nou, schiet mij maar lek! Het lijkt er op dat ik alles heb uitgesloten (?) maar dit blijft fout gaan.

Ik heb een Laravel app (5.1.28);

dev omgeving:
php 5.6.13
mysql 5.6.19

productie omgeving:
php 5.6.16
mysql 5.5.27

MySQL:

CREATE TABLE testquestions (  
  id bigint(20) UNSIGNED NOT NULL,  
  testquestiongroup_id bigint(20) NOT NULL,  
  description varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,  
  type varchar(255) COLLATE utf8_unicode_ci NOT NULL,  
  created_at timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',  
  updated_at timestamp NOT NULL DEFAULT '0000-00-00 00:00:00'  
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

De database content is op de dev en productie omgeving precies hetzelfde.

Maar dan draai ik de volgende code;

PHP:

$question = new Question();  
$question->testquestiongroup_id = $questiongroup->id;  
$question->save();

Wat gaat er goed; er wordt een nieuwe database row toegevoegd in de testquestions-table.
Wat gaat er niet goed; de ID welke in het $question object wordt geplaatst is verkeerd. Elke keer wordt er een verkeerde ID in geplaatst, het rare is dat dit wel steeds dezelfde ID is.
Maar dit gebeurt alleen op de productie omgeving. Op de dev omgeving gaat dit goed.

En dan het rare; ik draai de volgende code na $question->save()

PHP:

var_dump($question);  
var_dump(\DB::getPdo()->lastInsertId());

lastInsertId() geeft de goede ID terug en $question->id heeft weer de verkeerde ID.

Je maakt je tabellen niet aan met migraties? Je hebt namelijk geen auto increment op je ID.

[Scotix]

Jawel, ik maak ze aan met migration files, en er zit wel auto increment op. Raar dat de tabel dump die niet mee neemt.
De ID wordt wel goed aangemaakt in de database, maar wordt niet goed gereturned naar mijn model object.

[Glasya]

Snel vraagje,

Wanneer ik bij mijn ajax post gebruik maak van een named route, hoe krijg ik dan de url parameters mee?

Onderstaande, zonder parameters werkt prima:

_{$.ajax({
url: '{{ route('my.named.route') }}',
type: 'post',
data: {'_token':'{{ csrf_token() }}', 'foo':'bar'},
success: function(response)
{
// do something
}
});}


Onderstaande gaat mis (syntax error, unexpected '}'):

_{$.ajax({
url: '{{ route('my.named.route', ['{{ \Request::segment(5) }}']) }}',
type: 'post',
data: {'_token':'{{ csrf_token() }}', 'foo':'bar'},
success: function(response)
{
// do something
}
});}


En dit werkt ook niet (Use of undefined constant id - assumed 'id'):

_{var id = '{{ \Request::segment(5) }}';
$.ajax({
url: '{{ route('my.named.route', [id]) }}',
type: 'post',
data: {'_token':'{{ csrf_token() }}', 'foo':'bar'},
success: function(response)
{
// do something
}
});}


Wat wel werkt zijn de volgende varianten.

De eerste werkt alleen voor routes met een enkele parameter, welke ik uit de url kan halen met segment, indien ik naar de functie een waarde stuur, bv function bla(id) dan kan ik id niet uitlezen binnenin de {{ route() }}

_{$.ajax({
url: '{{ route('my.named.route', 'param1') }}',
type: 'post',
data: {'_token':'{{ csrf_token() }}', 'foo':'bar'},
success: function(response)
{
// do something
}
});}


Dit werkt ook, maar ook hierbij geld dat ik geen function waardes kan gebruiken binnenin de route declaratie.

_{$.ajax({
url: '{{ route('my.named.route', ['waarde 1', 'waarde 2']) }}',
type: 'post',
data: {'_token':'{{ csrf_token() }}', 'foo':'bar'},
success: function(response)
{
// do something
}
});}

[patricks8]

Goedemorgen,

In mijn laravel applicatie wil ik graag gebruik maken van sterke wachtwoorden met minimaal 8 tekens lang, 1 kleine letter, 1 hoofdletter, 1 cijfer en 1 speciaal teken. De volgende tekenset is dus toegestaan:
abcdefghijklmnopqrstuvwxyz!@#$%^&*()-+<>ABCDEFGHIJKLMNOP1234567890.

Ik krijg het alleen niet voor elkaar om de speciale tekens om te zetten naar een regex die laravel begrijpt. Kunnen jullie mij hierbij helpen of een voorbeeld geven hoe ik de speciale tekens in een regex kan zetten?

[Chris7]

Glasya schreef op zaterdag 13 februari 2016 @ 22:14:
Snel vraagje,

patricks8 schreef op zondag 14 februari 2016 @ 09:33:
Kunnen jullie mij hierbij helpen

Quote uit de topicstart:

Barryvdh schreef op zaterdag 07 februari 2015 @ 17:25:
Het is niet de bedoeling om hier problemen voor te leggen. Daar moet nog steeds een los topic voor aangemaakt worden!

Dit is een algemeen discussietopic, geen vraagbaak . Tip: zet code in [code] tags, dan heb je zelfs syntax highlighting als je de taal opgeeft .

Trouwens @patricks8, dat is een hele algemene regex vraag die niets met Laravel te maken heeft. Denk niet dat je een zinnig antwoord gaat krijgen, zal meer "poets eerst je regex-kennis maar op" worden.

[Erhnam]

patricks8 schreef op zondag 14 februari 2016 @ 09:33:
Goedemorgen,

In mijn laravel applicatie wil ik graag gebruik maken van sterke wachtwoorden met minimaal 8 tekens lang, 1 kleine letter, 1 hoofdletter, 1 cijfer en 1 speciaal teken. De volgende tekenset is dus toegestaan:
abcdefghijklmnopqrstuvwxyz!@#$%^&*()-+<>ABCDEFGHIJKLMNOP1234567890.

Ik krijg het alleen niet voor elkaar om de speciale tekens om te zetten naar een regex die laravel begrijpt. Kunnen jullie mij hierbij helpen of een voorbeeld geven hoe ik de speciale tekens in een regex kan zetten?

Hier staat een voorbeeld van wat je nodig hebt:

http://stackoverflow.com/...-password-validation-rule

[ Voor 18% gewijzigd door Erhnam op 14-02-2016 11:57 ]

[Creepy]

De vraag van patricks8 is inderdaad een "gewone" regexp vraag, de vraag van Glasya heeft ook niks met Laravel specifiek te maken maar is een javascript / ajax vraag. Beide horen in elk geval niet in dit topic thuis, zoals Chris7 ook al aangeeft. Dit is een discussie topic en geen vragen/helpdesk topic. Open voor je vraag gewoon een eigen topic, doe dat op de juiste plek (javascript vragen horen niet in PRG ) en let op de Quickstart zodat je je topic van de juiste informatie voorziet.

[patricks8]

Thanks voor de reply en ik zal er de volgende keer opletten om zelf een topic aan te maken .

[Glasya]

Evenals Patricks8 zal ik er op letten in de toekomst een eigen topic te starten, echter wil ik Creepy er toch op attenderen dat mijn vraag, hoewel het een ajax vraag betreft in dit geval wel degelijk gerelateerd is aan Laravel doordat ik juist de helper functie route() wil utiliseren in de url parameter van de ajax post.

Ik had mijn vraag ook reeds op het forum van laracasts gepost maar kreeg daar geen bevredigend antwoord, vandaar dat ik mijn heil elders zocht, maar helaas tot op heden zonder succes.

[Barryvdh]

Glasya schreef op maandag 15 februari 2016 @ 11:07:
Evenals Patricks8 zal ik er op letten in de toekomst een eigen topic te starten, echter wil ik Creepy er toch op attenderen dat mijn vraag, hoewel het een ajax vraag betreft in dit geval wel degelijk gerelateerd is aan Laravel doordat ik juist de helper functie route() wil utiliseren in de url parameter van de ajax post.

Ik had mijn vraag ook reeds op het forum van laracasts gepost maar kreeg daar geen bevredigend antwoord, vandaar dat ik mijn heil elders zocht, maar helaas tot op heden zonder succes.

Die link van Ernham werkte niet? Bijv. door die minimaal 3 in minimaal 4 van de 5 te matchen. https://3v4l.org/2Snc6

Erhnam schreef op zondag 14 februari 2016 @ 11:55:
[...]

Hier staat een voorbeeld van wat je nodig hebt:

http://stackoverflow.com/...-password-validation-rule

Om het bij Laravel te houden, kan je een custom validation rule maken: https://laravel.com/docs/...n#custom-validation-rules

Bijv zo:

PHP:

Validator::extend('password', function($attribute, $value, $parameters, $validator) {
    $pattern = '/^.*(?=.{4,})(?=.*[a-zA-Z])(?=.*[0-9])(?=.*[\d\X])(?=.*[!$#%]).*$/';
    return preg_match($pattern, $value);
});

Dan kan je gewoon in je rules 'password' gebruiken.
Maar er zijn ook vast wel functies/libraries te vinden die de strength van een password kunnen bepalen. En met de custom validations hoef je niet alles in 1 regex te proppen, maar je kan ook 5 kleine regexes of checks doen..

[Matis]

Scotix schreef op donderdag 11 februari 2016 @ 11:59:
Je zou het in je index route kunnen opvangen;

PHP:

Route::get('/', function(){
if(Input::get('projName') && Input::get('version')){
// redirect naar je controller
}
});

Ik was je nog vergeten te bedanken voor je terugkoppeling. Ik heb het inderdaad op deze manier opgelost.

---

Als laatste ben ik nog op zoek naar een manier om de data van de oude server (en dus oude database model) om te zetten naar de nieuwe, op Laravel / Eloquent gebaseerde, modellen.
Feitelijk zoek ik naar een seeder die de data vanaf de oude server pulkt en hem seed in de nieuwe ORM.

Is dit een acceptabele manier van werken of een enorme bad practice?

[Scotix]

Matis schreef op dinsdag 16 februari 2016 @ 16:16:
[...]

Ik was je nog vergeten te bedanken voor je terugkoppeling. Ik heb het inderdaad op deze manier opgelost.

---

Als laatste ben ik nog op zoek naar een manier om de data van de oude server (en dus oude database model) om te zetten naar de nieuwe, op Laravel / Eloquent gebaseerde, modellen.
Feitelijk zoek ik naar een seeder die de data vanaf de oude server pulkt en hem seed in de nieuwe ORM.

Is dit een acceptabele manier van werken of een enorme bad practice?

Graag gedaan!

Je zou dit in een migration file kunnen verwerken.
https://laravel.com/docs/5.2/migrations

Oude database tabellen via de DB class aanroepen en de data in je nieuwe models knallen.

[Creepy]

Modbreak:

Blijkbaar was ik toch niet duidelijk genoeg. Dit topic is bedoeld als discussie over Laravel, niet om je problemen/vragen met/over Laravel op te laten lossen. Maar nadat ik heb aangegeven dat dit geen helpdesk topic is, zie ik toch weer vragen voorbij komen die in een eigen topic horen en mensen die de vragen beantwoorden. Dat is erg aardig maar niet de bedoeling. Ik heb heel weinig zin om dit topic dicht te moeten zetten, maar als er dit soort vragen voorbij blijven komen, dan laten jullie me geen andere keus. Problemen en vragen horen in een eigen topic.

[CH4OS]

Als je bezig gaat met cron binnen Laravel even een kleine tip; soms moeten cronjobs voor sommige OS'en onder een user draaien, je zet dan dus niet

code:

* * * * * php /path/to/artisan schedule:run >> /dev/null 2>&1

in een cronjob, maar

code:

* * * * * <USERNAME_HIER> php /path/to/artisan schedule:run >> /dev/null 2>&1

Heeft mij net een half uur van mijn leven gekost om daar achter te komen, op Debian...

[ Voor 16% gewijzigd door CH4OS op 16-03-2016 13:09 ]

[8088]

Dat is alleen nodig als je handmatig een bestand aanmaakt in /etc/cron.d. Met crontab als de user die 'm uit moet voeren, hoeft dat niet:

user@host# crontab -e

of

root@host# crontab -e -u user

[Barryvdh]

Opletten met wijzigingen in Composer: https://github.com/laravel/laravel/pull/3687

[CH4OS]

Hoe zat het het volgende ook weer met Eloquent relations:

Ik heb twee tabellen, en een koppeltabel, drie in totaal dus. Nu ben ik even op zoek naar de Eloquent functie / relation om dus bijvoorbeeld results op te halen aan de hand van het user id, of van een ander ID, die dus middels de koppeltabel gerelateerd worden aan elkaar. Is dat hasManyThrough()?