My plugin configuration looks like this;
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin('Orbit.Navigator', 'mission', [
\Orbit\Navigator\Controller\SpaceXController::class => 'cpt, cpr, shuttle',
\Orbit\Navigator\Controller\Conf\FlightController::class => 'pressure,target,timer',
\Orbit\Navigator\Controller\Conf\WeatherController::class => 'mav,hub',
]);
I have this setup,
10 = USER_INT
10 {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = Navigator
pluginName = mission
vendorName = Orbit
switchableControllerActions {
SpaceX{
1 = shuttle
}
}
}
The request lands in the shuttleAction() method in SpaceXController. After processing, How do I FORWARD it to timerAction() in FlightController?
Using;
$this->forward('timer', 'Flight', $this->request->getControllerExtensionName(), $this->request->getArguments());
acts like $_POST and results in;
(1/2) #1278450972 TYPO3\CMS\Extbase\Reflection\Exception\UnknownClassException
Class does not exist. Reflection failed.
Using;
$this->redirect('timer', 'Flight', $this->request->getControllerExtensionName(), $this->request->getArguments());
acts like $_GET (redirects to another page) and page throws an error complaining of "too many redirects".
Am able to forward to another action in the same Controller but how do I forward to another action in another Controller?
So it turns out that switchableControllerActions is being deprecated for the very reasons mentioned above. It override the original configuration of plugins at runtime. But am thankful I won't be relying on that setting. Although the deprecation notice mentions this, it further states that they're removing it for not adhering to it's paradigm for plugins. To quote from the deprecation notice thusly,
switchableControllerActions have been marked as deprecated and will
be removed in one of the next major versions of TYPO3, probably
version 11.0 or 12.0.
switchableControllerActions are used to override the allowed set of
controllers and actions via typoscript or plugin flexforms. While this
is convenient for reusing the same plugin for a lot of different use
cases, it’s also very problematic as it completely overrides the
original configuration defined via
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin.
switchableControllerActions therefore have bad implications that
rectify[sic] their removal.
First of all, switchableControllerActions override the original
configuration of plugins at runtime and possibly depending on
conditions which contradicts the idea of
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin being the
authoritative way to define configuration.
Using the same plugin as an entry point for many different
functionalities contradicts the idea of a plugin serving one specific
purpose. Switchable controller actions allow for creating one central
plugin that takes care of everything.
Source: Deprecation: #89463 - Deprecate switchableControllerActions
I for one completely agree it's a good move.
There's a way around it that is made possible by TYPO3's capacity for multiple plugin definitions in the extension configuration file (ext_localconf.php) of a single extension. With that, one can define a dedicated plugin for any individual action needed in TypoScript or FlexForm.
I have been using Eloquent as a standalone package in Slim Framework 2 successfully.
But now that I want to make use of Illuminate\Support\Facades\DB since I need to show some statistics by getting the info from 2 tables and using a Left Join and a Counter from the database like this:
use Illuminate\Support\Facades\DB;
$projectsbyarea = DB::table('projects AS p')
->select(DB::raw('DISTINCT a.area, COUNT(a.area) AS Quantity'))
->leftJoin('areas AS a','p.area_id','=','a.id')
->where('p.status','in_process')
->where('a.area','<>','NULL')
->orderBy('p.area_id');
I get the following error:
Type: RuntimeException
Message: A facade root has not been set.
File: ...\vendor\illuminate\support\Facades\Facade.php
Line: 206
How can I solve it?
So far I have found out, in this link that I need to create a new app container and then bind it to the Facade. But I haven't found out how to make it work.
This is how I started the rest of my Eloquent and working fine:
use Illuminate\Database\Capsule\Manager as Capsule;
$capsule = new Capsule();
$capsule->addConnection([
'my' => $app->config->get('settings'),
/* more settings ...*/
]);
/*booting Eloquent*/
$capsule->bootEloquent();
How do I fix this?
Fixed
As #user5972059 said, I had to add $capsule->setAsGlobal();//This is important to make work the DB (Capsule) just above $capsule->bootEloquent();
Then, the query is executed like this:
use Illuminate\Database\Capsule\Manager as Capsule;
$projectsbyarea = Capsule::table('projects AS p')
->select(DB::raw('DISTINCT a.area, COUNT(a.area) AS Quantity'))
->leftJoin('areas AS a','p.area_id','=','a.id')
->where('p.status','in_process')
->where('a.area','<>','NULL')
->orderBy('p.area_id')
->get();
You have to change your code to:
$Capsule = new Capsule;
$Capsule->addConnection(config::get('database'));
$Capsule->setAsGlobal(); //this is important
$Capsule->bootEloquent();
And at the beginning of your class file you have to import:
use Illuminate\Database\Capsule\Manager as DB;
I have just solved this problem by uncommenting $app->withFacades(); in bootstrap/app.php
Had the same issue with laravel 8. I replaced
use PHPUnit\Framework\TestCase;
with:
use Tests\TestCase;
Try uncommenting in app.php $app->withFacades();
Do not forget to call parent::setUp(); before.
fails
public function setUp(): void {
Config::set('something', true);
}
works
public function setUp(): void {
parent::setUp();
Config::set('something', true);
}
One random problem using phpUnit tests for laravel is that the laravel facades have not been initialized when testing.
Instead of using the standard PHPUnit TestCase class
class MyTestClass extends PHPUnit\Framework\TestCase
one can use
class UserTest extends Illuminate\Foundation\Testing\TestCase
and this problem is solved.
I got this error after running:
$ php artisan config:cache
The solution for me was to delete the /bootstrap/cache/config.php file. I'm running Laravel 5.5.
The seems to arise in multiple situation, and not just about facades.
I received the following message while running tests using PHPUnit v.9.5.4, PHP v.8.0.3 and Lumen v. 8.2.2:
PHP Fatal error: Uncaught RuntimeException: A facade root has not
been set. in path_to_project/vendor/illuminate/support/Facades/Facade.php:258
And that happened although I had apparently already configured my app.php to enable facades ($app->withFacades();), still I received this error message whenever I tried to run tests using Illuminate\Support\Facades\DB. Unfortunately, none of the other answers helped me.
This error was actually been thrown due to my configs in phpunit.xml, which didn't point to my app.php file, where I actually enabled facades.
I just had to change
<phpunit (...OTHER_PARAMS_HERE) bootstrap="vendor/autoload.php">
to
<phpunit (...OTHER_PARAMS_HERE) bootstrap="bootstrap/app.php">
Hope it helps.
wrong way
public function register()
{
$this->app->bind('Activity', function($app)
{
new Activity;
});
}
right way 👍
public function register()
{
$this->app->bind('Activity', function($app)
{
return new Activity;
});
}
---------------------------------- don't forget return
Upgrade version for php, I encountered this error while calling the interface.
$ php artisan config:cache
Deleting the /bootstrap/cache/config.php file is a very effective way.
In my project, I managed to fix this issue by using Laravel Dependency Injection when instantiating the object. Previously I had it like this:
$class = new MyClass(
new Client(),
env('client_id', 'test'),
Config::get('myapp.client_secret')
);
The same error message happened when I used Laravel env() and Config().
I introduced the Client and env in the AppServiceProvider like this:
$this->app->bind(
MyClass::class,
function () {
return new MyClass(
new Client(),
env('client_id', 'test')),
Config::get('myapp.client_secret')
);
}
and then instantiated the class like this:
$class = app(MyClass::class);
See more from https://laravel.com/docs/5.8/container .
In my case, for a while a ran a PHP project in PHP version 8, and that time I used some PHP 8 features like param definition and method's multiple return type declarations supported by only PHP 8 and above. When I downgraded from PHP 8 to PHP 7.4 I faced this issue. After removing the return types and param hinting the problems are gone.
Tested on Laravel 8.78
tests/bootstrap.php
<?php
use Illuminate\Foundation\Bootstrap\RegisterFacades;
use Illuminate\Foundation\Bootstrap\LoadConfiguration;
require_once __DIR__ . '/../vendor/autoload.php';
$app = require_once __DIR__ . '/../bootstrap/app.php';
(new LoadConfiguration())->bootstrap($app);// <------- Required for next line
(new RegisterFacades())->bootstrap($app);// <------- Add this line
Here is yet another instance of this error, happened to me after upgrading Laravel 8 to 9.
I had feature tests with a #dataProvider to supply data to those tests. Some of the data supplied by the data provider methods came from an application service. It was being initialised like this:
/**
* #dataProvider myDataProvider
*/
public function testSomeStuff(...)
{
...
}
public function myDataProvider()
{
$myService = app(Service::class); // This is trouble
return [
['test1_data' => $myService::SOME_CONSTANT],
[...],
...
];
}
This worked under Laravel 8, but not in Laravel 9. All other solutions listed in this SO thread were checked and were correctly set up.
The problem is that the application is not being inititialised until after the data provider method is run. It was presumably initialised before this stage in the Laravel 8 install. So app(Service::class) was failing due to it using facades internally.
One workaround could be to force the application to initialise earlier, in the data provider function: $this->createApplication(). I would not recommend this due to potential side effects of the test parts running in the wrong order, though it does appear to work when I tried it.
Best solution is to avoid accessing any part of the application functionality in the data provider methods. In my case it was easy to replace $myService::SOME_CONSTANT with MyService::SOME_CONSTANT after making sure those constants were public.
Hopefully this will help somebody suddenly hitting this problem running feature tests after a Laravel 9 upgrade.
If you recently upgrade Laravel on Homestead & VirtualBox environment or do not find any reason that causing please be sure your Vagrant is up to date.
Referance
I had Taylor lock this thread. The past several replies have restated the solution, which is to Upgrade to Virtualbox 6.x, the thread is locked to prevent other issues that are not related from being dogpiled on here.
#melvin's answer above works correctly.
In case someone is wondering about it, the mistake people do is to choose Yes when VSCode asks them if they are making a Unit Test. Remember, Unit Tests should really be unit tests, independent of other application features (models, factories, routes; basically anything that would require the Laravel app to be fired up). In most scenarios, people really actually want to make Feature Tests and therefore should answer No to the above question. A feature test inherits from Tests\TestCase class (which takes care of firing up Laravel app before running the test) unlike unit tests that inherit from the class PHPUnit\Framework\TestCase which use just PHPUnit and are therefore much faster.
credit with thanks to #Aken Roberts's answer here.
From Laravel Documentation: Generally, most of your tests should be feature tests. These types of tests provide the most confidence that your system as a whole is functioning as intended.
i see everyone using this:
Doctrine_Manager::getInstance()
when i do this, its error is:
Class 'Doctrine_Manager' not found
how do i load this ?so that i can start get instances from doctrine manager?
i want to load this:
$con = Doctrine_Manager::getInstance()->connection();
$st = $con->execute("...............");
$result = $st->fetchAll();
where can autoload this , so i can call the getInstance() function from anywhere?
thanks...
Doctrine_Manager is part of version 1.2, not 2. If you are actually using 1.2, you need to let the autoloader know to load classes under the Doctrine_ prefix.
To do so, add this to your application configuration file...
autoloaderNamespaces.Doctrine = "Doctrine_"
You also need to ensure the doctrine classes can be found on the include path. If they aren't in your "library" folder or otherwise part of the include_path directive, add this...
includePaths.Doctrine = "/path/to/Doctrine-1.2/lib"
I think you might be looking for the EntityManager?
If so, here you can find a tutorial how to configure.
Also there is a library call Bisna for integrating ZF+Doctrine2, here is a good tutorial video for configuring it
How can i call joomla 'Simple Picture Slideshow' plugin in any joomla component. Have any solution?
Thanks
Best way to call content plugins in Joomla! 1.5 and above is just use:
$text = JHTML::_('content.prepare', $text);
http://docs.joomla.org/Triggering_content_plugins_in_your_extension
You can call any event of plugin which is defined in that plugin.
$dispatcher = JDispatcher::getInstance();
$data = array($argu1, $argu2); // any number of arguments you want
return $dispatcher->trigger($eventName, $data);
In Joomla, plugins are not called in the typical sense, they are triggered by various events. The plugin listens for the particular event that triggers it. In this case, you would need to look and see what even Simple Picture Slideshow listens for, then add that trigger to your component. The only way to guarantee that a plugin will be triggered all the time is have it listen for one of the global system events, these happen regardless of the code in the component, they happen at the framework level. If a plugin is triggered by a non-global event, then you would need to either change the plugin or add the event to every component you want using the plugin.
Global system event reference - http://docs.joomla.org/Reference:System_Events_for_Plugin_System
Plugin reference - http://docs.joomla.org/Plugin
This question is specifically for Content plugin of joomla.
You can trigger any plugin event in your component.
Here is an example to trigger content plugin onPrepareContent event.
$content = new stdClass;
$content->text = 'Your content body with proper tag or
content wich you want to replace.
For example: {loadmodule mod_login}';
$atricle = array();
JPluginHelper::importPlugin('content');
$dispatcher = JDispatcher::getInstance();
JDispatcher::getInstance()->trigger(
'onPrepareContent',
array(
&$content,
&$atricle,
null
)
);
Or if you want to trigger only specific plugin for your component, then you can use,
JPluginHelper::importPlugin('content', 'loadmodule');
Second argument is name of the plugin which you want to use.
Similarly, you can call user plugin event in your component.
JPluginHelper::importPlugin('user', 'contactcreator');
JDispatcher::getInstance()->trigger(
'onUserAfterSave',
array(
$user,
$isnew,
$success,
$msg
)
);
i wanted to support multilingual structure for my work i used the following lines
$controller=Zend_Controller_Front::getInstance();
$router=$controller->getRouter();
$languageRouter=new Zend_Controller_Router_Route(":lang/:module/:controller/:action", array("lang"=>"en","module"=>"default","controller"=>"index","action"=>"index"),
array("lang"=>"[a-zA-Z]{2}"));
$router->addRoute("default",$languageRouter);
it works fine http://localhost/zend/public/en set the lang param to en and call default module
but the problem is that when i use url like this http://localhost/zend/public/en/anything
where anything isn't module it still show the default module how to prevent that???
after the answer of takeshin i added this function to the bootstarp file and now it works as i want it
protected function _initRoutes()
{
$routeLang=new Zend_Controller_Router_Route(':lang',array('lang'=>'en'),array('lang'=>'[a-z]{2}'));
$front = Zend_Controller_Front::getInstance() /*$this->getResource('frontcontroller')*/;
$router = $front->getRouter();
$routeDefault=new Zend_Controller_Router_Route_Module(array(),$front->getDispatcher(),$front->getRequest());
$routeLangDefault=$routeLang->chain($routeDefault);
$router->addRoute('default',$routeLangDefault);
$router->addRoute('lang',$routeLang);
}
It looks like you have overwritten default module defined in Zend Application by your custom one.
You should chain the routes instead.
The settings you are using means module will 'default' to default , if you didn't it would throw a route not found error - which should throw to appropriate error controller
I'm not sure if I unterstood this correctly, but it looks like it works fine, as it should. If you try to call non existing module, Zend Framework automatically "redirects" to the default module.