Normally, application is bootstrapped after request being created. But in a test environment it happens before creating request.
That leads to socialiteproviders/manager implicitly creating request here, thinking it already exists. This request doesn't get used, and the other one is created after that.
As a result, I can't forge session data with withSession helper. Since it changes session created for latter request. And SocialiteProviders' provider always gets empty session.
If I disable bootstrapping it here, the first error I get is at this line, since application has not being bootstrapped yet.
Who's at fault? And how to fix it? And can you think of any workarounds meanwhile?
P.S. More details here.
Well, if I had to answer who's at fault, I'd say it's socialiteproviders/manager, since it makes an assumption that request is already created when application is being bootstrapped. And here's the solution the way I see it.
To use it you add
{
"type": "vcs",
"url": "https://github.com/x-yuri/Manager"
}
to repositories parameter of composer.json. And do
$ composer require 'socialiteproviders/manager=dev-testing-boot as 2.2.1'
Do note though, using extra repositories slows composer down.
Related
I just got a memory limit error and I solved it in my .ini files. No worries. However, I'd like to put something in my package composer.json to indicated that some minimum memory is required. I know how to specify a php version requirement in composer.json - I'm just wondering if other platform requirements can be added/checked by composer.
Composer can check for software to verify if they are corresponding. But, it doesn't check the system (CPU, memory...). You can specify the requirements in a readme.md file.
You can add in your code the memory limit needed in your script. But, in general, the default memory limit is enough. You may be have loops you can optimize by adding yeld or iterators.
The complete list of properties available in composer.json is very well-documented.
The only one which makes requirements on a user's system is the require section. This can include platform dependencies (also discussed on the "basic usage" page) in the form of virtual packages exposing the version of PHP, its extensions and related libraries, and Composer itself. These are resolved as part of the dependency resolution process, and not when the application runs, although you can enable an additional platform check.
Note that the config section configures the behaviour of Composer itself, not the package, and is marked "root-only" - that is, it will not even be read when another project uses your library. The platform option which you've mentioned is the opposite of a platform requirement: it tells Composer to pretend certain constraints are met even when they are not.
If you want to verify at run-time that a particular configuration is in place, rather than merely documenting it, you can easily write your own using functions such as ini_get. This can either be run as part of initialisation of some relevant object or function, or listed as a file include in the autoload section so that it will always be executed as the application starts up.
UPDATE: Although this is the only working solution provided - please read the comment thread. There are good arguments against this. Also, this requires strong working knowledge of writing and deploying vendor packages. Specifically, you'll want to know how to roll this back when a better solution is posted or the problematic package is fixed.
Add a little php file to your composer project or package.
composer.json
{
...
"autoload": {
...
"files": ["tweak_ini.php"]
}
}
tweak_ini.php
Obviously you'll want to add some logic to make sure you aren't downgrading.
ini_set('memory_limit','1000M');
...
I am working in a controller, the code that I change must stay here. The routes are defined as annotations in the controller.
So, maybe it is not the cause, but whenever I make a change to my code and refresh my page, the first refresh is very slow (the project is huge, many controllers).
After a first refresh, the next ones are quick. So I guess symfony detects the controller has changed and rebuilds the router cache.
This is painful.
How can I temporarily disable re-scanning the whole project for routes ?
Significant delays in dev environment are caused by container re-building. It is actually very good decision from Symfony developers because it allows you to focus on development itself and don't waste time trying to hunt mysterious bugs that will be actually caused by hidden incompatibilities between your code and container contents.
Simplest way to avoid automatic container re-building is to switch to prod environment where Symfony expects you to care about container by yourself. However in this case you will also lose a lot of other convenient tools that are provided by Symfony into dev environment.
There is also slightly harder alternative. Take a look at Kernel::initializeContainer() method, it is responsible for container initialization. As you can see from the code - Symfony checks if container is fresh. It is done by loading .meta files that resides in container and checking if all files listed in them are same as they was at a time of container building. Since this method is quite internal - it is not open for simple modifications but you can copy / paste it into your application's container and modify to match your needs. Of course you need to understand that this approach can't be treated as recommended way and unlikely supported by Symfony developers so you have to accept possible consequences, but still - it is possible to implement.
I have two codebases, one running as the primary web app, the other as the old code with legacy pages. Both codebases have their own composer installations, and that is where the problem occurs. When the first codebase has to call the second one, it is just a require secondApp. Both apps have, in requirements for other libraries, pake. The problem comes that Pake has a pake_autoloader function and the second one is noticing that the first already declared it, and throws an exception saying I cannot redeclare it. Both of these apps load Pake as a requirement for other libs. How do I get around the redeclaring issue?
Move both applications into one, and have only one composer.json file. Because by executing code of the "other" application, this really is only one big application.
A different idea would be to clearly seperate the two and only communicate via a defined interface, like making HTTP calls to the other application and using what's being returned.
I'm having auth problems in my new laravel 4 app.
The one odd thing I have noticed and this might be why is that when I do:
var_dump(Hash::check('secret', Hash::make('secret')));
in the DB seeder (where I create my hashed passwords) I get true.
When I run that same command directly in a route, I get false.
Also, when I do a simple:
var_dump(Hash::make('secret'));
directly in the route it is still false.
Is this broken or am I missing something ?
There is something wrong with your install. This is what I get:
Route::get('/', function()
{
var_dump(Hash::make('secret')); // Gives a bcrypt string output
var_dump(Hash::check('secret', Hash::make('secret'))); // Output true
}
Did you do a composer update, and forget to update the app itself? That is the most common cause of Laravel 4 issues at the moment.
This forum post gives a detailed answer on how to update the main L4 app after a composer update.
Edit: I will post the forum stuff here - because you need to be logged in to Laravel forums to see beta section:
If you run composer update and experience problems after doing so, you most
likely need to merge in changes from the application skeleton, which
is the develop branch of laravel/laravel.
If you originally cloned this repository and still share a git history
with it, you can usually merge in changes easily. Assuming your remote
is 'upstream' pointed at this repository, you can do the following:
git fetch upstream
git merge upstream/develop
Alternatively you could cherry pick in individual commits from the develop branch, but I won't cover that here.
If you downloaded the zip distribution originally or removed the
upstream history, you can still resolve your problem manually. Look at
the commits on this branch and make any changes not present in your
application. Usually the breaking changes are simple configuration
changes.
Once Laravel 4 stable has been released the need to do this will be
much less frequent, but these changes can still occur. Keep in mind
that during this beta application breaking changes are very likely to
happen.
Thanks to Kindari for the forum post.
I need to update source files (pull and update from the repository) in my production server, run migrations, and regenerate cached assets.
Is there any mechanism in Symfony 2 to do this safely? Like putting the site into 'maintainance mode' (which should throw a 503) or something?
I've just found a Bundle for Symfony 2, which offers you 2 extra-commands in the console to put your application into maintenance mode.
Here you go: https://github.com/lexik/LexikMaintenanceBundle
I've been trying to decide how I would implement this. On one hand, Symfony2 provides decent prod caching, so if you're not destructively modifying your database schema (removing columns or tables, etc), you can probably get away with just changing the schema, deploying from your repo, then clearing your prod cache. That's how I handle things most of the time.
On the other hand, if you DO want to go into maintenance mode, you'll want a solution that has minimal load on the framework (ie, you probably don't want to fire up the kernel), or you're defeating the purpose anyway: taking the load off the framework while you muck with things.
If it were me, I'd probably write a simple maintenance script that just sets a 503 header, maybe serves up some static html (pregenerated from my site templates) and sends it back to the user, then use some conditional logic in my app.php to use that when I should be in maintenance mode. It's ugly, but it works.
Not sure how to go about this for a bigger site where a user could be in the middle of some kind of transaction (shopping for instance) but for a smaller site could you not just use a .htaccess file (the one in the web directory assuming that is your root) to redirect to some maintenance page instead of into app.php.
I can recommend using deployer (http://deployer.org/) to deploy your Symfony2 application. This way you dont need a maintenance page. The tool ships with a symfony2 and symfony3 template already included.
It generates your assets, warms up the cache and keeps track of your release directories. It's easy to roll back to a previous release also.
there is a "current"-symlink which always points to your current release directory. If a release deployment is complete this link updates to the newly created release directory.
Regarding doctrine migrations you need to write a custom task for that.
Please look at capifony http://capifony.org/
It has excellent support for Symfony2.