Just start editing new project based on Yii 2. I am used to Yii 1.
Just for test, added string echo 'test'; to the file frontend/config/bootstrap.php.
Then I saw this string on my website. So then I removed it from frontend/config/bootstrap.php.
Unfortunately, now frontend/config/bootstrap.php contains the test string again. I tried to remove the string several times,
but it appears again and again after 5 minutes of my operation. Why?
I tried to clear Yii cache by the console, it did not help
It sounds like you would benefit from reading up on Yii 2 environments and configs.
The init command is used to initialize an environment. What it really does is copy everything from the environment directory over to the root directory where all applications are.
Essentially, files you may be editing are actually the result of Yii copying to the production location. Be sure to edit the correct set of config files and then rerun the init command.
https://www.yiiframework.com/extension/yiisoft/yii2-app-advanced/doc/guide/2.0/en/structure-environments
Related
I've been working on this for several days now and I'm at the point of pulling my hair out.
Goal: to deploy Slim4 on my LAMP server within a specific subdirectory and accessible via a simple URL.
Structure:
There are several instances of my web app on the server and the setup should be replicated for all of them; the structure is straight forward:
/var/www/company1.com/app
this "app" folder contains the main index.php of the website, as well as other various folders. Eg. /var/www/company1.com/app/index.php => https://company.com/index.php
there is a folder called "api" within which I want to load Slim4. I don't really mind how this folder is structured and how deep it goes. I'm working on basis that this is where the composer file goes.
the end result should be that the customer can access the api by calling https://company1.com/api
I'm using the openapi-generator and the Pet Store yaml file.
Running:
openapi-generator-cli generate -i petstore.yaml -g php-slim4 -o /var/www/company1/api/
I've then run composer install and setup the config.inc.php file as described in the instructions.
However when I navigate to http://company1.com/api I am greeted with the same issue every time:
404 Not Found Type: Slim\Exception\HttpNotFoundException Code: 404 Message: Not found. File: /var/www/company1.com/app/api/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php Line: 91 Trace: #0 /var/www/company1.com/app/api/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php(58): Slim\Middleware\RoutingMiddleware->performRouting() #1 /var/www/company1.com/app/api/vendor/slim/slim/Slim/MiddlewareDispatcher.php(147): Slim\Middleware\RoutingMiddleware->process()
it goes on...!
I can't figure this problem out.
This issue seems to be quite common as there are a lot of posts about it, so I'm convinced I've missed something very simple.
I have tried the following:
Setting the base path
$app->setBasePath("/api");
Creating a /public/ folder and moving the index.php file there, then creating two different .htaccess files, based on these instructions:
https://akrabat.com/running-slim-4-in-a-subdirectory/
using basepath as per its instructions
https://github.com/selective-php/basepath
None of it seems to work! What am I doing wrong?
I have been able to successful load the Slim4 Skeleton application, however I want to use the openapi-generator so that I can have it automatically prepare all the php files based on my openapi yaml spec.
Any thoughts on tips would be greatly appreciated!
EDIT: Question title changed. The original question title was: Using a relative URL in a Vue app that works in both production and development, but this turned out not to be the cause of my problem (see comments below).
I've tried so many things and all I want to do is use a single relative url in a JavaScript fetch() method and have it run consistently in both development and production without having to change lots of config files or webpack settings.
In a nutshell I want to fetch() a get-users.php file which resides in the same directory as the app — nothing fancy or complicated — just a php file that gets some data from a mysql database on the same host.
I can make it work in development, but then it fails in production (npm run build), OR I can get it working in production but then it fails in development (npm run serve). The reason it fails is essentially because the relative url in production is the root of the dist folder, but the relative url in development is the root of the vue project folder — is that correct?. So in development for example I can use fetch(public/get-users.php) which works perfectly, but then in production the dist folder doesn't contain a public folder so I get a 404 error. I can manually copy and paste the public folder to the dist folder after each build, but this just seems like an unnecessary extra step.
Part of the problem is that I don't fully understand where a file like get-users.php should reside. I don't mind if I have to put it in the public or static folders, but when I do that it fails in production because of the example above. Could someone please explain the role of the public folder in a Vue CLI app please? Does it do something under the hood that I don't fully understand? Am I missing something obvious? It seems like such a trivial task to make this work but I'm banging my head against the wall here! Please help! :)
If you're using vue cli then all you need is to put your get-users.php file inside the public folder and access this file without public prefix like this:
fetch('get-users.php')
This will work as expected for both dev and prod environments because during the build step webpack will copy all static assets from the public to the dist folder.
I'm looking through the documentation, but I'm not seeing any option to change the working directory used when running tests.
I'm using PhpUnit as it's included in Laravel. I want to be able to run vendor/bin/phpunit from my project's root directory, and have it run using the /public directory as the working directory.
I tried running ../vendor/bin/phpunit from the /public, but since the phpunit.xml file isn't in the public directory and I don't want to specify my config file path every time, that won't work.
Is there something I can add to my phpunit.xml file to tell it to run tests using the /public directory as the "cwd" (current working directory)?
Based on the feedback I received in the comments and the documentation, I determined the following:
It's probably not possible to change the cwd that phpunit uses by default (well, it's possible in PhpStorm, but not the command line without writing some kind of wrapper script)
Code that depends on being run from a specific directory is not a good idea.
What I had was some code in one of my classes like this:
$var = file_get_contents("../some_file.json");
This works fine -- until you try to add unit tests. The web server runs using the /public directory as the cwd, while phpunit will run using the root directory.
Rather than trying to force phpunit to always use a particular cwd (/public), I decided it's probably best to remove relative paths from the code that rely on a consistent cwd. So the line above becomes:
$var = file_get_contents(base_path("some_file.json"));
I didn't want to change production code that was already working just to get some tests in place, but this change seemed insignificant enough. (and it's an improvement anyway)
Well, you'd have to do the actual chdir in PHP, but you can define a bootstrap script in the XML (<phpunit bootstrap="./bootstrap.php">) and have that change the working directory.
Alternatively, you can put a setUpBeforeClass function into your test class that changes the working directory.
My project is two Laravel applications in one folder. Why two separate applications instead of one? I have good reasons. Anyway, for example, every time I want to change the app name in the config (config/app.php) I go and edit the .env file in both directories (of the two applications) and then execute artisan config:cache to update the cached config.
It's not much of a task or anything, but it's a bad design I believe. So, I am looking for a way to take the values shared between these two application out to a separate file. And have these application load this file and override/apply the values inside it to the app configuration.
So, now I have a config.php in the root directory (which holds the other two apps in /app1 and /app2). And inside each app's AppServiceProvider I call the config.php and loop through the values and set each using Config::set(..., ...).
This worked for me well, but of course changing the values loaded in the \Config package doesn't change the values that were fetched from it earlier to this point. For example app()->environment() returns the value set in the config/app.php, not the new value introduced in the global config.php. That's because the App library asked for the env property before I could override it!
So, what I want your help with is: you either tell me about a more smart/standard way to achieve 1 config for 2 apps setup. Or tell me where to put the code that overrides the app config with the new values from my global config.php (currently I put the code in register() in App\Providers\AppServiceProvider)
You can share env settings by removing one of .env files and make a symlink to the other file instead of a common file. In this case if you change a file, both applications get changed values.
I have a server that runs quite a few Drupal sites. Some of these are older and running Drupal 5, while some are newer and running Drupal 6. We're also beginning to implement Drupal 7.
Our organization uses one standard Website Administration password that we distribute internally only to our employees for maintenance of these websites. This may or may not be the best security practice, but it is how we do things at this time. Please assume that this won't change.
The problem we have is that when we have employee turnover, we must change this password and apply the change to every site we run in order to make sure that the employee cannot deface any of our clients' sites. This is more critical for firings, but we also do it for resignations as a best practice.
In the past, I ran a basic PHP script that used mysql_list_dbs on our Database server to iterate through every database and change the pass field of the users table where the name = admin. BasicallY:
while ($row = mysql_fetch_object(mysql_list_dbs($sql_connection))) {
mysql_query("UPDATE users SET pass=MD5('$newpassword') WHERE name='admin'", $row->Database);
}
This worked perfectly fine but it has two problems:
It's hacky and I hate hacky stuff. I'd rather do things that make use of the "official way" of doing things
Drupal 7 uses a different hashing system than D5 and D6 did, so this won't work for Drupal 7 sites. Now I have to check first that the existing value of pass matches the hash of the old password before updating so that I don't accidentally break a Drupal 7 site. In the meantime, I haven't yet figured out how to implement this for Drupal 7 sites.
So I'm looking for an alternative solution. I really think that I need to use a bash script that either iterates through Virtual Hosts from httpd.conf or uses find or something and one way or another, cd's into every site install directory inside very installation platform's "sites" folder (we have a pretty messy setup*) and runs drush upwd admin --password=$newpassword
This would be completely platform independent and would allow Drupal to define what happens when the password is changed.
I realize that Aegir may actually be a good solution for this, but we're not ready to implement Aegir quite yet, and I'm looking for more of a quick and dirty intermediate solution. I appreciate any input you might have.
*Just a sample of our messy setup:
/www
/cliena
/drupal-5.x
/sites
/clienta.com <-- contains settings.php for Client A
/clientb
/drupal-5.x <-- contains old code base for Drupal 5 site that's been migrated I shoudld probably have my drush/bash script ignore these sections....
/drupal-6.x <-- contains code base for current Drupal 6 site
/sites
/clientb.com <-- contains settings.php for Client B
/clientc
/drupal-6.x
/sites
/default <-- contains settings.php for clientc.com
/sub1.clientc.com <-- contains settings.php for sub1.clientc.com
/sub2.clientc.com <-- contains settings.php for sub2.clientc.com
/sub3.clientc.com <-- contains settings.php for sub3.clientc.com
/client_sites
/drupal-5.x
/sites
/clientd.com <-- contains settings.php for clientd.com
/cliente.com <-- contains settings.php for cliente.com
/clientf.com <-- contains settings.php for clientf.com
... and so forth... you get the picture. a Migration to Aegir is in order, but it'll take a while to clean this up.
you could improve and continue writing this script bellow...
for FILE in $(find /www -type f -name system.module); do
C_PATH=`dirname $FILE`
C_VERSION=`grep "define('VERSION'," $FILE | awk -F "'" {'print $4'}`
print "--- DEBUG --- "
print "Current path: $C_PATH"
print "Current version: $C_VERSION"
# Your logic here...
done
[]'s
Felipe
The script of Felipe looks good, i adopted it, to deal with the multi-site-installations and drush. In my setup it found every site in my installation. Please try it with a not-so-destructive drush command first:
PASSWORD='secret'
for FILE in $(find /www/ -type f -name settings.php); do
PATH=`dirname $FILE`
echo "Changing password for: $PATH"
drush -r $PATH upwd admin --password=$PASSWORD
done
Felipe and Nebel54 both gave me great starts. I ended up working mostly off of Nebel's, but still had to make some modifications. I found two problems with your script, Nebel.
1) It seems that "PATH" is a reserved word. When I tried to use it as a variable, it didn't work right. So I changed it to "DPATH".
2) It seems that passing the -r parameter to drush isn't sufficient. When I used that, it told me that I needed a higher bootstrap level to run my command. So I had to do a CD to the $DPATH before executing my drush command.
For testing I executed the sql-connect command first because that just outputs the sql connection string for review and doesn't make any changes. I'm about to run the password update now. Here's my final script:
PASSWORD='newpass'
for FILE in $(find /www/ -type f -name settings.php); do
DPATH=`dirname $FILE`
cd $DPATH
echo "Changing password for: $DPATH"
drush upwd admin --password=$PASSWORD
done