autoload a class in slim behaves strangely - slim

I developed an Slim-3 application on my local Vagrant (running on Windows) with standard Ubuntu 1604 env.
In my composer.json, I inserted the autoload directive:
"autoload": {
"psr-4": {
"btc\\": "src\btc"
}
}
And in my src\btc folder I created a few classes all with namespace btc declaration at the top of each PHP class files.
In particular, I have an http.php file like this:
namespace btc;
class Http {
const SUCCESS_WITH_OUTPUT = 200;
const SUCCESS_WITH_NO_OUTPUT = 204;
const SUCCESS_POST_WITH_OUTPUT = 201; //CREATED
const FAIL_AUTH = 401;
const BAD_REQUEST = 400;
const FAIL_OTHERWISE = 403;
}
In my routes.php I have this reference:
$output = ['res' => 'Method not implemented', 'status'=>btc\Http::BAD_REQUEST];
This works fine in my local vagrant machine.
===========
Now I cloned the repo to deploy to my production machine.
composer update runs fine.
I ran composer dumpautoload one more time to create the autoload files.
Slim app runs OK in the sense that the routes are correctly mapped.
But it fails saying that class 'btc/Http' not found error.
I think this is due to the btc namespace not automatically loaded.
Did I miss anything here?
Thanks for your help.

I have located the error that caused this strange behavior: case sensitivity.
As my Linux Vagrant machine is running on Windows, it does NOT care about cases. So http.php and Http.php is the same.
But in a pure Linux env, these two are different.
Changed to Http.php and everything goes fine.

Please use a / for all paths in composer.
Example:
"autoload": {
"psr-4": {
"btc\\": "src/btc/"
}
}
Then run composer update.

Related

Issue with installing Facebook CTF

I am trying to install Facebook CTF from https://github.com/facebook/fbctf
Following the instructions, I execute ./extra/provision.sh -m prod -s $PWD
All goes well, until it gets to the section where it runs grunt. It's hitting this code in a javascript file
const proto = Object.defineProperties(() => {}, {
...styles,
level: {
enumerable: true,
get() {
return this._generator.level;
},
set(level) {
this._generator.level = level;
}
}
});
It's balking at the ellipsis in front of styles.
It's giving this error.
...styles,
^^^
SyntaxError: Unexpected token ...
Has anyone run into this error when install fbctf or can spot a Javascript error? Thanks for your help
I'm using the Quick Setup instructions and ran into a similar issue.
I resolved by it upgrading my nodejs version using npm in the instructions below.
https://phoenixnap.com/kb/update-node-js-version
Note: I did the nodejs installation on command line before running the install command.

Fatal error: Uncaught ArgumentCountError: Too few arguments to function TYPO3\CMS\Core\Imaging\IconFactory::__construct()

After following the composer installation guide for v10 of typo3. I pointed apache vhost to the public folder. Once I navigate to the index.php location in the browser, I get this error
Fatal error: Uncaught ArgumentCountError: Too few arguments to function
TYPO3\CMS\Core\Imaging\IconFactory::__construct()
0 passed in /home/user/projects/typo3/public/typo3/sysext/core/Classes/Utility/GeneralUtility.php
on line 3423
and exactly 2 expected in
/home/user/projects/typo3/public/typo3/sysext/core/Classes/Imaging/IconFactory.php:71
It looks like a dependency injection problem. Please can anybody help with this error
For me this issue occured after moving an existing project from a server into DDEV (which is similar to changing the path/URL by a vhost config). My guess is it has to do with changed paths/URLs in cached files. This is how I solved it:
A) Manually delete all cached files:
t3project$ rm -rf public/typo3temp/*
t3project$ rm -rf var/*
B) Also I had to change the ownership of some autogenerated folders/files to my current user (sudo chown -R myuser:myuser t3project/), then I was able to use the "Fix folder structure" tool in "Environment > Directory Status", now everything was working fine again. Not sure if the last step is helpful for you, as it might be only related to my case where certain folder/files had a wrong owner as they was copied.
I had the same problem today and it occured because I was XClass'ing one of the Core Classes and used GeneralUtility::makeInstance(IconFactory::class) in this code.
The fix is to use DI in this class, just as you suggested. Also flush all caches afterwards to rebuild the DI container.
From this:
class CTypeList extends AbstractList
{
public function itemsProcFunc(&$params)
{
$fieldHelper = GeneralUtility::makeInstance(MASK\Mask\Helper\FieldHelper::class);
$storageRepository = GeneralUtility::makeInstance(MASK\Mask\Domain\Repository\StorageRepository::class);
...
To this:
class CTypeList extends AbstractList
{
protected StorageRepository $storageRepository;
protected FieldHelper $fieldHelper;
public function __construct(StorageRepository $storageRepository, FieldHelper $fieldHelper)
{
$this->storageRepository = $storageRepository;
$this->fieldHelper = $fieldHelper;
}
public function itemsProcFunc(&$params)
{
$this->storageRepository->doStuff();
$this->fieldHelper->doStuff();
...
For future reference for others:
This can also happen in own extensions when the Core uses GeneralUtility::makeInstance on your classes. (e.g. in AuthenticationServices).
The trick here is to make these DI services public like so:
(in extension_path/Configuration/Serivces.yaml)
services:
_defaults:
autowire: true
autoconfigure: true
public: false
Vendor\ExtensionName\Service\FrontendOAuthService:
public: true
Here's documentation for it:
https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/DependencyInjection/Index.html#knowing-what-to-make-public
I had this error because i used the Services.yaml file in one of my extensions, but did not configure it correct.
More infos about the file itself can be found here
Since the file is responsible for the dependency injection, small mistakes e.g. in namespaces lead to the above mentioned error.
To locate the error you can uninstall extensions with a Services.yaml.
When you have found the file/extension, you have to check if all Namespaces in the Classes Directory are correct.
This means:
All filenames are correct regarding the Class they contains
All Namespaces in the files are correct for path and filename
The Namespace can be found via composer. So the extension have to be installed via composer or must have an entry in the autoload list of composer.json

TYPO3 tutorial extension, controller does not exist

I'm trying to get started with TYPO3 extensions and was following this tutorial to get to see the basics.
In the backend everything works fine, but on the front end I get an error:
Oops, an error occurred! Code: 20170209104827c3b58d58 -
{"exception":"exception 'ReflectionException' with message 'Class
Tx_Inventory_Controller_InventoryController does not exist'
My files are exactly the same as in the tutorial. I have no idea what is causing this. I assume I made some dumb mistake with namespaces, but they seem to be all correct.
The controller class can be found below and is located in typo3conf/ext/inventory/Classes/Controller/
<?php
namespace \MyVendor\Inventory\Controller;
use \TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
use \TYPO3\CMS\Core\Utility\GeneralUtility;
use \MyVendor\Inventory\Domain\Model\Repository\ProductRepository;
class InventoryController extends ActionController {
public function listAction() {
$productRepository = GeneralUtility::makeInstance(ProductRepository::class)
$products = $productRepository->findAll();
$this->view->assign('products', $products);
}
}
?>
When developing a new extension in a composer installed TYPO3 V9 (here: 9.4) the autoload part has to be added to the central root composer.json. Found it here (German). Following the steps in the OPs mentioned tutorial leads to a core exception:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1278450972:
Class MyVendor\StoreInventory\Controller\StoreInventoryController does not exist.
Reflection failed.
As long as the extension is not installed via composer, e.g because it's newly developed, composer does not find the appropriate composer.json file in the extensions directory. Hence TYPO3 does not find any classes in the new extensions Classes directory. To resolve the issue the autoload configuration has to be added to the root composer.json. Just put the following lines into composer.json within the installations base directory:
{
"repositories": [
{ "type": "composer", "url": "https://composer.typo3.org/" }
],
...
"autoload": {
"psr-4": {
"MyVendor\\StoreInventory\\": "public/typo3conf/ext/store_inventory/Classes/"
}
}
}
Then regenerate the autoload configuration:
composer dumpautoload
You possibly have to clear the cache as well in the backend.
It looks like your class is not autoloaded. If you don't use composer to make your autoload, take a look in your typo3conf/autoload/autoload_classmap.php file.
You should find an entry corresponding to your file. You will see if you have a path error.
Remove backslashes - try with
<?php
namespace MyVendor\Inventory\Controller;
use TYPO3\CMS\Extbase\Mvc\Controller\ActionController;
use TYPO3\CMS\Core\Utility\GeneralUtility;
use MyVendor\Inventory\Domain\Model\Repository\ProductRepository;
class InventoryController extends ActionController {
public function listAction() {
$productRepository = GeneralUtility::makeInstance(ProductRepository::class)
$products = $productRepository->findAll();
$this->view->assign('products', $products);
}
}
Ensure you add Vendorname to extension key, when you register your plugin, see ext_tables.php and write 'MyVendor.'.$_EXTKEY instead of $_EXTKEY like
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerPlugin(
'MyVendor.'.$_EXTKEY,
'List',
'The Inventory List'
);
I had exactly the same problem - it happens if Typo3 installation is done by composer. To solve this problem see this page of the docs.
Try to add autoload in your ext_emconf.php (replace 'Vendor\\Extensionkey\\') and uninstall and install your extension again (to rebuild PHP autoload information)
'autoload' =>
array (
'psr-4' =>
array (
'Vendor\\Extensionkey\\' => 'Classes',
),
),
'_md5_values_when_last_written' => 'a:0:{}',
'suggests' => array(
),

Class 'mPDF' not found in Yii2

I have problem with my page on server.
I'm using yii2 framework and mPDF;
All configured according to the instructions: http://www.bsourcecode.com/yiiframework2/create-pdf-files-using-mpdf-in-yiiframework-2-0/
Page work on localhost on Windows and Xampp
When I try run page on Debian 8 I have error:
Class 'mPDF' not found
Configuration: http://www.bsourcecode.com/yiiframework2/create-pdf-files-using-mpdf-in-yiiframework-2-0/
function in php:
public function actionCreatepdf()
{
$request = Yii::$app->request;
$generate_table = $request->post();
$mpdf = new mPDF;
$mpdf->WriteHTML($this->renderPartial('view_pdf', ['data'=>$data]));
$mpdf->Output('data.pdf', 'D');
exit;
}
I have no idea what I'm doing wrong, it's not running on Debian
I had this issue when migrating from Ubuntu (php 5.6) to CentOS 7 (PHP 7.1)
The easiest thing to do, without manually editing the composer file was to change the use/import in the controller:
//use mPDF; #Php 5.6
use Mpdf\Mpdf; #Php 7.0
Solved! As mentioned before it was due to capital cases.
I used following and it is now working on CENTOS 7 (probably similar on most Linux versions)
<?php
namespace app\controllers;
use Yii;
//use mPDF; Note this line is Commented out
use mpdf;
And then use it as follows:
public function actionIndex(){
$model = new Mpdf();
$model->SetHeader('header');
$model->WriteHTML("PDF contents");
$model->SetFooter('footer');
$model->Output('MyPDF.pdf', 'D');
exit;
}
In my case which i just resolved, adding
'mPDF\' => array($vendorDir . '/mpdf') to autoload_psr4.php required me to namespace most of the class files in ../mpdf/classes using the line
namespace mPDF;
Also among the errors i fixed was changing include to include_once to prevent php from seeing some classes as duplicate declaration despite the presence of class_exists() test

uWSGI + virtualenv 'No module named site'

So this seems to be a really common problem with this setup, but I can't find any solutions that work on SO. I've setup a very new Ubuntu 15.04 server, then installed nginx, virtualenv (and -wrapper), and uWSGI (via apt-get, so globally, not inside the virtualenv).
My virtualenv is located at /root/Env/example. Inside of the virtualenv, I installed Django, then at /srv/www/example/app ran Django's startproject command with the project name example, so I have vaguely this structure:
-root
-Env
-example
-bin
-lib
-srv
-www
-example
-app
-example
manage.py
-example
wsgi.py
...
My example.ini file for uWSGI looks like this:
[uwsgi]
project = example
plugin = python
chdir = /srv/www/example/app/example
home = /root/Env/example
module = example.wsgi:application
master = true
processes = 5
socket = /run/uwsgi/app/example/example.socket
chmod-socket = 664
uid = www-data
gid = www-data
vacuum = true
But no matter whether I run this via uwsgi --ini /etc/uwsgi/apps-enabled/example.ini or via daemon, I get the exact same error:
Python version: 2.7.9 (default, Apr 2 2015, 15:37:21) [GCC 4.9.2]
Set PythonHome to /root/Env/example
ImportError: No module named site
I should note that the Django project works via the built-in development server ./manage.py runserver, and that when I remove home = /root/Env/example the thing works (but is obviously using the global Python and Django rather than the virtualenv versions, which means it's useless for a proper virtualenv setup).
Can anyone see some obvious path error that I'm not seeing? As far as I can tell, home is entirely correct based on my directory structure, and everything else in the ini too, so why is it not working with this ImportError?
In my case, I was seeing this issue because the django app I was trying to run was written in python 3 whereas uwsgi was configured for python 2. I fixed the problem by:
recompiling uwsgi to support both python 2 and python 3 apps
(I followed this guide)
adding this to my mydjangoproject_uwsgi.ini:
plugins = python35 # or whatever you specified while compiling uwsgi
For other folks using Django, you should also make sure you are correctly specifying the following:
# Django dir that contains manage.py
chdir = /var/www/project/myprojectname
# Django wsgi (myprojectname is the name of your top-level project)
module = myprojectname.wsgi:application
# the virtualenv you are using (full path)
home = /home/ubuntu/Env/mydjangovenv
plugins = python35
As #Freek said, site refers to a python module.
The error claims that python cannot find that package, which is because you have specified python_home to the wrong location.
I've encountered with the same problem and my uwsgi.ini is like below:
[uwsgi]
# variable
base = /home/xx/
# project settings
chdir = %(base)/
module = botservice.uwsgi:application
home = %(base)/env/bin
For this configuration uwsgi can find python executable in /env/bin but no packages could be found under this folder. So I changed home to
home = %(base)/env/
and it worked for me.
In your case, I suggest digging into home directive and point it to a location which contains both python executable and packages.
The site module is in the root of django.
First check is to activate the virtualenv manually (source /root/Env/example/bin/activate, start python and import site). If that fails, pip install django.
Assuming that django is correctly installed in the virtualenv, make sure that uWSGI activates the virtualenv. Relevant uWSGI configuration directives:
plugins = python
virtualenv = /root/Env/example
and in case you have error importing example.wsgi:
pythonpath = /srv/www/example/app/example