I received a project and I'm trying to start it in Docker with NGINX environment. But it seems I have a bug with LiipImagine. The project use Symfony 4 and LIIPImagine version 2.0.x-dev.
A page should display images from cache, exemple of an image URL :
https://localhost:8443/media/cache/live_feed_message/images/live_feed_message/5c486df1a78fe_lama-750389_960_720.jpg
The directory exists with rights :
drwxr-xr-x 2 1000 1000 4069 Jan 23 13:35 live_feed_message
All images are stored in public/images/live_feed_mesage/ and in public/media/cache/live_feed_message/images/live_feed_message the corresponding image doesn't exists.
I figured out that if I use the command from LiipImagine:
php app/console liip:imagine:cache:resolve relative/path/to/image1.jpg
It gives this result :
http://localhost/media/cache/quizz_thumbnail/images/live_feed_message/name_file.jpg
http://localhost/media/cache/quizz_sponsors_icon/images/live_feed_message/name_file.jpg
http://localhost/media/cache/live_feed_message/images/live_feed_message/name_file.jpg
And then the corresponding image exists in cache (public/media/cache/live_feed_message/images/live_feed_message) and the image displays correctly on the page...
In network tab from development console, I checked the response from an HTTP request. And I get this Symfony response:
Unable to write to the "/srv/api/public/media/cache/live_feed_message/images/live_feed_message" directory.
Does someone know what could be the issue ?
Since 2 days I can't resolve this issue, so thanks for your help !
PS: I overrided a route from routing.yaml from the bundle.
In the path there was /resolve and I overrided with this (in fact I deleted /resolve from liip_imagine_filter path):
_liip_imagine:
resource: "#LiipImagineBundle/Resources/config/routing.yaml"
liip_imagine_filter:
path: /media/cache/{filter}/{path}
defaults:
_controller: '%liip_imagine.controller.filter_action%'
methods:
- GET
requirements:
filter: '[A-z0-9_-]*'
path: .+
You should maybe try being more permissive with chmod -R 777 public/images. In local it's not a very big deal, it's in production that you should fine tune your permissions. That would probably clear out your errors and you could go on coding.
An actual permission for production would be 755 IIRC.
Related
I'm using hydra to log hyperparameters of experiments.
#hydra.main(config_name="config", config_path="../conf")
def evaluate_experiment(cfg: DictConfig) -> None:
print(OmegaConf.to_yaml(cfg))
...
Sometimes I want to do a dry run to check something. For this I don't need any saved parameters, so I'm wondering how I can disable the savings to the filesystem completely in this case?
The answer from Omry Yadan works well if you want to solve this using the CLI. However, you can also add these flags to your config file such that you don't have to type them every time you run your script. If you want to go this route, make sure you add the following items in your root config file:
defaults:
- _self_
- override hydra/hydra_logging: disabled
- override hydra/job_logging: disabled
hydra:
output_subdir: null
run:
dir: .
There is an enhancement request aimed at Hydra 1.1 to support disabling working directory management.
Working directory management is doing many things:
Creating a working directory for the run
Changing the working directory to the created dir.
There are other related features:
Saving log files
Saving files like config.yaml and hydra.yaml into .hydra in the working directory.
Different features has different ways to disable them:
To prevent the creation of a working directory, you can override hydra.run.dir to ..
To prevent saving the files into .hydra, override hydra.output_subdir to null.
To prevent the creation of logging files, you can disable logging output of hydra/hydra_logging and hydra/job_logging, see this.
A complete example might look like:
$ python foo.py hydra.run.dir=. hydra.output_subdir=null hydra/job_logging=disabled hydra/hydra_logging=disabled
Note that as always you can also override those config values through your config file.
I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.
I have an incomprehensible problem.
I have used this bundle many times, and I understand the main logic to generate a pdf from a twig view.
But on my two last project i have this kind of error:
Error: Failed to load https://mydomain/bundles/bundle/css/bootstrap.css, with network status code 1 and http status code 0 - Connection refused
Exit with code 1 due to network error: ConnectionRefusedError
I have tried:
HTTP and HTTPS url
chmod 777 on var/cache folder - try acl
disable all parameters of wkhtml
update wkhtml
Disable extends twig view - ihave made a new file with full HTML
Clean controller use assets
filter / absolute_url filter / or web_url variable to prefix assets
On my development environment (Windows), i didn't have any problem.
This problem appeared when I work on production environment, based on Debian 9 with nginx, php 5.6, mariadb 10.0* and letsencrypt certificate.
I can't load any assets for now.
Does anyone have an idea??
Ok i have found a workaround. I use this trick :
create a global variable with this path :
pdf_url: '%kernel.root_dir%/../web'
then i call my assets like this :
<link href="{{ pdf_url}}/bundles/css/bootstrap.css" rel="stylesheet">
Its a not the ebst solution, but its works.
I am trying to configure Alfresco Community 3.3 on a port other than its default port of 8080. I need it to run on 8989. I think I have change all instances of 8080 (where it is mentioned in configuration files) to 8989, and I am able to access Alfresco Explorer okay. So far so good.
But, when I try to access http://localhost:8989/share I get the following error
java.io.IOException: Unable to test document path:
alfresco/site-data/configurations/slingshot.site.configuration.xml in
remote store: alfresco due to error: 404
The files I have changed are as follows:
tomcat/conf/server.xml
tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/file-severs.xml
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/repository.properties
tomcat/webapps/alfresco/WEB-INF/classes/alfresco/subsystem/sysAdmin/default/sysadmin-parameter.properties
tomcat/webapps/alfresco/wsdl/access-control-service.wsdl
tomcat/webapps/alfresco/wsdl/administration-service.wsdl
tomcat/webapps/alfresco/wsdl/action-service.wsdl
tomcat/webapps/alfresco/wsdl/authentication-service.wsdl
tomcat/webapps/alfresco/wsdl/authoring-service.wsdl
tomcat/webapps/alfresco/wsdl/classification-service.wsdl
tomcat/webapps/alfresco/wsdl/content-service.wsdl
tomcat/webapps/alfresco/wsdl/dictionary-service.wsdl
tomcat/webapps/alfresco/wsdl/repository-service.wsdl
virtual-tomcat/conf/server-minimal.xml
virtual-tomcat/conf/server.xml
Have I missed something obvious?
(Please make no suggestions about upgrading......)
I think you have overdone it.
According to
http://wiki.alfresco.com/wiki/Changing_Default_Port_Configuration
you should only change it in share-config-custom.xml
Change all the files back but share-config-custom.xml
Four are the files to be changed in Alfresco 5.2 in order to set the various ports:
[alfresco-community_instDir]\properties.ini
[alfresco-community_instDir]\tomcat\conf\server.xml
[alfresco-community_instDir]\tomcat\shared\classes\alfresco-global.properties
[alfresco-community_instDir]\tomcat\webapps\share\WEB-INF\classes\alfresco\share-cmis-config.xml
I have problem with my server configuration. I use Apache 2.216, PHP 5.3.3 and wordpress 3.4.2 with Shopperpress. Time to time I receive error "client denied by server configuration: path/to/file" in apache log file. It is path to _tbs.php file, but it is not problem in rights of file, because this file is called 12 times on page for getting thumbs of photos and there is error only several times. I think that it has no connection to concrete photo, because once this photo is displayed corectly and next time same photo produce error.
Do you have any idea what can be reason?
Thank you for all advices.
Viktor
I think thats a problem by the configuration of MaxClients or MaxRequestsPerChild.
Try to restore the default configuration and try it again. If that not works, reinstall Apache and purge the old configuration.
You have given very little information. It is not clear under what conditions do you work (OS, installed modules, Log entrys,...).
WordPress 3.4.2 is very old and safety-relevant. Please update WordPress and your WP-Plugins.
Go to you VHOST-file and replace:
Deny from all
Allow from 127.0.0.0/255.0.0.0
with:
Require all granted
This cause for old Config-Files and newer Apache-Version. Since Apache 2.4.3 a new security feature is added.