Editing bootstrap.php to customize Dotenv behaviour - php

I'm not satisfied by the Symfony Dotenv default behaviour, because I would like to have i.e. a .env.override which would override existing environment values.
So I would like to add the following code in config/bootstrap.php
$envLocal = dirname(__DIR__).'/.env.override';
if (file_exists($envLocal)) {
(new Dotenv(false))->overload($envLocal);
}
Is it a problem to edit this file (config/bootstrap.php)? Can it be erased by future Symfony updates?

You can modify bootstrap.php to your heart's content.
The file is created when you run create-project symfony/skeleton, but it's part of your application files (it's not a dependency), so it's your responsibility to maintain it, and use it as you see fit.
Actually, if you upgraded your application to a version of Symfony that expected a different behaviour of bootstrap.php (or public/index.php, or (bin/console) you may need to update these files (among others).

Related

How to use one module in two different application/project in yii2

I have module created in the basic project of yii2 and now i want to access or use that module another project/application of mine....
How can I achieve this.
please help me out here.
To use module in different apps there are 3 things you need.
The module must not be dependent on classes from core project. For any class that needs to be implemented by core project the module should define interface and depend on that interface instead of class itself.
The module should use different namespace than app and autoloader must know how to load classes from that namespace. (more about that later)
You have to add module in your config in same way you've added it in first project.
The points 1 and 3 are pretty much self-explaining. If are not sure how to add module in config see the yii2 guide.
Now back to the second point. While naive way of copying module over to second project would work it will turn maintaining the module into nightmare because each change would have to be done in each copy of module. So it's better to keep the code of module in one place and make it available for each project. There are multiple ways of doing that.
If you want to, you can turn your module into extension and make it publicly available through packagist as it was suggested by M. Eriksson in comments. After that you would simply add your extension through composer as any other dependency.
Composer also allows you to define and use private repositories if you don't want to publish your module at packagist. See composer documentation for more details.
The most trivial way is to simply put the code into separate folder outside of project. If you do that, you have to make sure that autoloaders in your projects are capable of finding the files locations to load classes. There are two options how to do that. In any case you will want to avoid conflicts with namespaces used by your project, that's why you need to use different namespace.
Let's assume that you've put your module files into folder /path/to/modules/myModule and all classes in your module belongs to namespace modules\myModule. You have to make sure that your webserver can access that folder and that it can run php scripts there.
First option is to use Yii's autoloader. That autoloader uses aliases to look for classes. If you add #modules alias and point it to /path/to/modules folder, the Yii autoloader will try to look for any class from modules\* namespace in /path/to/modules folder. You can add the alias in your config file (web.php, console.php or any other config file you use):
return [
// ...
'aliases' => [
'#modules' => '/path/to/modules',
// ... other aliases ...
],
];
The second option is to use project's composer.json file to set autoloader generated by composer to load your classes.
{
"autoload": {
"psr-4": {
"modules\\": "/path/to/modules"
}
}
}
You can find more info about this in composer's documentation.
Don't forget to run composer dump-autoload after you change autoload settings in your composer.json file to update the generated autoloader.

Opcache preloading and missing App_KernelProdContainer.preload.php

After following the documentation, my new OPCache settings are like this:
opcache.preload_user=www-data
opcache.preload=/var/www/vhosts/.../httpdocs/.../var/cache/prod/App_KernelProdContainer.preload.php
opcache.memory_consumption=1024
opcache.interned_strings_buffer=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
By default, inside var/cache/prod folder there is a file named srcApp_KernelProdContainer.preload.php.
After deleting /cache folder & restarting PHP-FPM, App_KernelProdContainer.preload.php is not created.
Should I rename App_KernelProdContainer.preload.php to srcApp_KernelProdContainer.preload.php or am I missing something else?
No, you shouldn't add this file directly to your PHP settings, since as you discovered it makes the whole thing very brittle. You should also not rename it or anything, since it's generated automatically.
What Symfony does in latter versions is create a "preload" file.
The Symfony 4 flex recipe includes this one.
<?php
if (file_exists(dirname(__DIR__).'/var/cache/prod/srcApp_KernelProdContainer.preload.php')) {
require dirname(__DIR__).'/var/cache/prod/srcApp_KernelProdContainer.preload.php';
}
if (file_exists(dirname(__DIR__).'/var/cache/prod/App_KernelProdContainer.preload.php')) {
require dirname(__DIR__).'/var/cache/prod/App_KernelProdContainer.preload.php';
}
On Symfony 5.1+ you have something like this.
Notice that what this file requires the preload script conditionally. This way, if it doesn't exist, it won't just kill the PHP interpreter.
If you do not currently have this file; you can create it manually, or just copy it from the recipe.
Add this file to your opcache.preload settings on php.ini, not the generated preloading script directly.

CakePHP 3.0 / DebugKit Plugin Element Override

I am trying to override the template file for the environment panel in the CakePHP 3.0 DebugKit. The file is located at
app/vendor/cakephp/debug_kit/src/Template/Element/environment_panel.ctp
According to the docs, placing my own file at
app/src/Template/Plugin/cakephp/debug_kit/Element/environment_panel.ctp
should automagically display my template instead of the plugin's, however, my file is being ignored. I've tried leaving out the cakephp directory, and using camel case for the vendor/plugin names. What am I doing wrong?
After two more hours of experimentation I found the correct path:
app/src/Template/Plugin/DebugKit/Element/environment_panel.ctp
To clarify the confusion I had: the debug kit is not considered a composer/vendor-type plugin mentioned in the docs I linked in the question, so it doesn't need the ../cakephp/.. intermediate directory.
Additionally, the directory needed to be CamelCased instead of copied verbatim from the vendor directories.
ALSO: in apparent conflict with the Element docs, you CAN override a plugin element without setting the ['plugin' => false] option.

How to configure tcpdf when installing with Composer?

Our legacy PHP code includes tcpdf (https://github.com/tecnickcom/TCPDF) as part of the code base.
I am trying to move it out to a vendor folder, so I added Composer to the project, added TCPDF to composer.json and updated.
But the config/tcpdf_config.php file is modified in our code base (custom PDF author name etc.), and rightfully so, according to the docs: http://www.tcpdf.org/installation.php
Now, I'm not sure it's a good idea to modify vendor/tecnick.com/tcpdf/config/tcpdf_config.php because it might be overwritten by Composer any time I update. Also, there is not a word about Composer in the tcpdf docs.
What is the right solution to configure tcpdf (or any third-party library used through Composer, for that matter) while allowing Composer updates?
The way you are supposed to inject your configuration is to define all the constants first before ever touching the first TCPDF class.
Make sure to also set the constant K_TCPDF_EXTERNAL_CONFIG to true. This will prevent the autoconfiguration to search for the file you were talking about. (See line 60 of this file here: http://sourceforge.net/p/tcpdf/code/ci/master/tree/tcpdf_autoconfig.php)
This is well hidden in the documentation, but I found this: http://www.tcpdf.org/doc/code/example__019_8php.html
How to override TCPDF config using Composer
Copy the original tcpdf_config.php somewhere to your project, for example src/tcpdf_config.php.
Add define('K_TCPDF_EXTERNAL_CONFIG', true); at the beginning of your config copy and modify the rest of the config to your needs.
Edit your composer.json and add/update autoload section:
...
"autoload": {
...
"files": [
"src/tcpdf_config.php",
...
]
}
...
Regenerate the composer autoloader using composer dump-autoload.

Can I customize the Magento app/code/core folder without affecting future upgrades?

I found a guide on how to add new attributes to users, it explains that for this operation I must modify some files in the app / code / core / Mage directory (the directory that contains Magento’s modules).
But if i make some changes in that folder will this affect future upgrades?
Will an upgrade will delete my changes?
Should I limit the changes only to my modules to not have problems with updates?
You can also make a copy of the file in app/code/local/ with the same directory structure as the file has under app/code/core/. File under local will override those under core and will not be affected by upgrades.
For example:
app/code/local/Mage/Checkout/Block/Onepage/Billing.php
will override:
app/code/core/Mage/Checkout/Block/Onepage/Billing.php
and will not be overwritten by upgrades. Note that this will only work for Block and Model files.
You can also override files through custom modules with the config.xml file, although this is a bit more advanced.
Yes, changes such as these will be overwritten.
If you have such changes, try to:
keep core changes to a minimum
document any changes you make
report the issues on the Magrnto web site so that the changes can be replicated for everyone else
Controllers would work as well if you enable that Module in local space
local vs core controller

Categories