Symfony 1.4 I get the wrong values in app.yml - plugins

Obviously it is not that simple. Let's start from the beginning: I'm working on a shared project and yesterday I've been asked to add the plugin mgI18n. I followed the readme file step by step, but when it came down to run the command line to create the table used by the plugin, I got this:
database "" does not exists
I searched it, and I found out that sfConfig::get('app_mgI18nPlugin_connection'); returned an empty value. It was weird, because I've done every step right, setting the value in my app.yml and clearing symfony cache, so I logged sfConfig::getAll(); and found out that the only values for 'app_' stored here were the ones from the file app.yml in the plugin folder of kdDoctrineGuardFacebookConnectPlugin. I've already tried removing that file and clearing the cache, obtaining only to lose these values.
Here is the file contents:
project/apps/frontend/config/app.yml
all:
#other values
facebook:
appId: yyy
secret: yyy
cookie: true
script_lang: fr_FR
perms: email
mgI18nPlugin:
connection: doctrine
cultures_available:
fr: Français
en: English
it: Italiano
de: Deutsch
project/plugins/kdDoctrineGuardFacebookConnectPlugin/config/app.yml
all:
facebook:
appId: xxx
secret: xxx
cookie: true
script_lang: fr_FR
perms: email
and this is what I get when I log sfConfig::getAll(); :
array('app_facebook_appId' => 'xxx',
'app_facebook_secret' => 'xxx',
'app_facebook_cookie' => true,
'app_facebook_script_lang' => 'fr_FR',
'app_facebook_perms' => 'email',
)
Why the values for the main app.yml are not loaded? How do I correct this behaviour?
Thank you all in advance for your help, if you need more specifics I'll glady add them

If I understood you well you are in a command line task context (some sfTask). Symfony tasks by default do not run in application context. In most cases just call your task as
./symfony namespace:name --application=frontend
and you will have your configs.
If it is your own task just add it an option with default value in your configure method:
$this->addOptions(array(
new sfCommandOption('application', null, sfCommandOption::PARAMETER_REQUIRED, 'The application name', 'frontend'),
...
)
Plugin settings are loaded correctly, because plugins are configured per project not application (you enable them in ProjectConfiguration, not generated frontendConfiguration class)

Related

Hashed file names using Rollup

I am fairly new to bundlers and rollup specifically. What is the best way to conditionally hash file names in rollup.config.js when building for production, while at the same time saving the index.html to reference the new .css and .js hashed versions?
I see this in the docs, but I guess I don't know how to conditionally set these options based on dev/prod settings?
output: {
sourcemap: true,
format: 'iife',
name: 'app',
file: 'public/build/bundle.js'
// entryFileNames : 'bundle[hash].js
},
or is using rollup-plugin-hash a better solution?
still not sure what the best practice would be for updating the index.html
(and what does the manifest file option provide?)
You can use a plugin like #rollup/plugin-html to generate a html file that references the hashed filenames.
It is also possible to use the rollup-plugin-manifest to generate a JSON file that will contain these hashed filenames.
This is useful when you can't generate the HTML using rollup for some reason.
Since the Rollup config file is just Javascript, you can include some if statements that return different results based on the dev/prod settings.
const isProduction = process.env.NODE_ENV === 'production';
export default {
output: {
sourcemap: true,
format: 'iife',
name: 'app',
entryFileName: isProduction ? 'bundle[hash].js' : 'public/build/bundle.js',
dir: './',
}
};

How to clear the OPcache on a BasicAuth protected environment with typo3/surf?

On a TYPO3 project I'm working the Production/Staging (or Production/Dev, or any other) environment is protected by HTTP BasicAuth (basic access authentication).
The instance get's deployed via typo3/surf.
At some point typo3/surf must create a temporary php file, which can be accessed
later: after the switch was done and the new deployment is reachable via the frontend.
How can I configure typo3/surf to access the previously generated OPcache clearing script via the frontend on a BasicAuth protected environment?
Configuring typo3/surf to reset the PHP OPcache1
Four steps are basically necessary to configure the OPcache clearing/reset script:
Set task options for \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask
Add task \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask the an early stage (e.g. package but definitely before transfer)
Set task options for \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask
Add task \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask after stage switch
Here are the necessary snippets for your onInitialize function2 within your deployment configuration script:
Set task options for the "Create Script Task":
Since the "Respect WebDirectory" patch, the path to the script must not to be configured manually as it automatically uses the right WebDirectory path (which is set via options beforhand).
If you are using an older typo3/surf version or you have any special requirement you can set option scriptBasePath to set the absolute path to the resulting file:
# In this example, I have to set the absolute path for the resulting php file.
# Since the deployment run in GitLab CI I get the path to the root of the project's GIT
# repository via the environment variable `CI_PROJECT_DIR`. Since the path to the webDirectory
# inside the GIT repository is `<GitRepoRootFOlder>/app/web` I add it manually and concatenate
# it as final string for the option `scriptBasePath`:
$workflow->setTaskOptions(\TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask::class, [
'scriptBasePath' => \TYPO3\Flow\Utility\Files::concatenatePaths([getenv('CI_PROJECT_DIR'), '/app/web']),
]);
Set task options for the "Execute Task":
At this point, we provide username and password
$workflow->setTaskOptions('TYPO3\\Surf\\Task\\Php\\WebOpcacheResetExecuteTask', [
'baseUrl' => $application->getOption('baseUrl'),
'stream_context' => [
'http' => [
'header' => 'Authorization: Basic '.base64_encode("username:password"),
],
],
]);
Activate both Tasks:
$workflow->beforeStage('transfer', \TYPO3\Surf\Task\Php\WebOpcacheResetCreateScriptTask::class, $application)
->afterStage('switch', \TYPO3\Surf\Task\Php\WebOpcacheResetExecuteTask::class, $application);
This answer shows only the necessary parts for the OPcache reset process!
Please check also the TYPO3 CMS deployment configuration example in the official documentation.
Footnotes
1 This answer is based on typo3/surf GIT branch dev-master, version 2.x
2 Example where to place the mentioned snippets:
$deployment->onInitialize(function () use ($deployment, $application) {
/** #var SimpleWorkflow $workflow */
$workflow = $deployment->getWorkflow();
# the mentioned snippets have to be placed next to your existing configuration
});

How to change the logfile path of phantomjs through selenium?

i ran into a problem that seems to be a bug in selenium but maybe someone can hint me to a solution anyway.
A similar question has been asked 11 months ago see: How can I change logfile path of phantomjs with selenium?
but it was not solved.
I'm using Selenium::Remote::Driver in Perl to connect to selenium. My code looks like this:
my $driver = new Selenium::Remote::Driver(
'remote_server_addr' => 'localhost',
'port' => "4444",
'browser_name' => 'phantomjs',
extra_capabilities => {
'phantomjs.cli.args' => ['--webdriver-logfile=/tmp/phantomjsdriver.log']
}
);
I found out that the phantomjs devs have integrated the parameter phantomjs.cli.args to pass parameters through to phantomjs. The parameters show up but unfortunately are added to the default parameters.
See the logfile of selenium:
10:20:29.207 INFO - Creating a new session for Capabilities [{platform=ANY, javascriptEnabled=true, acceptSslCerts=true, phantomjs.cli.args=[--webdriver-logfile=/tmp/phantomjsdriver.log], browserName=phantomjs, version=}]
10:20:29.208 INFO - executable: /usr/local/node/bin/phantomjs
10:20:29.208 INFO - port: 5710
10:20:29.208 INFO - arguments: [--webdriver-logfile=/tmp/phantomjsdriver.log, --webdriver=5710, --webdriver-logfile=/phantomjsdriver.log]
10:20:29.208 INFO - environment: {}
PhantomJS is launching GhostDriver...
Unable to open file '/phantomjsdriver.log'
On the 4th line you can see that my argument was passed but the default '--webdriver-logfile=/phantomjsdriver.log' is also part of the arguments.
I tried also to set the loglevel to NONE but it tries to open the logfile anyways.
Lastly i tried to start phantomjs with a config file but i couldn't figure out the config option for the logfile and i'm not sure that would help.
My selenium server runs as a daemon if that is important.
Any help is appreciated!
Have a nice day
Have you tried using new_from_caps method for full control of your driver instance? Using this option no defaults are assumed by the constructor.
e.g.
my $driver = Selenium::Remote::Driver->new_from_caps(
desired_capabilities => {
'browserName' => 'phantomjs',
'phantomjs.cli.args' => ['--webdriver-logfile=/tmp/phantomjsdriver.log']
}
);
See doc here: https://metacpan.org/pod/Selenium::Remote::Driver#new_from_caps

Using ftp-deploy with load-grunt-tasks causes errors

I've split my Gruntfile into multiple files using load-grunt-tasks but seem to get an error when using ftp-deploy. I've tried some different things, but I reason that the hyphen (-) in the "ftp-deploy" might cause problems.
I'm getting the following error:
Running "ftp-deploy:theme" (ftp-deploy) task
Verifying property ftp-deploy.theme exists in config...ERROR
>> Unable to process task.
Warning: Required config property "ftp-deploy.theme" missing. Use --force to continue.
When running:
grunt "ftp-deploy:theme" --verbose
My ftp-deploy script looks as follows:
# FTP DEPLOY
# -------
module.exports =
'ftp-deploy':
theme:
auth:
host: 'host.com'
port: 21
authKey: 'key'
src: 'drupal/sites/all/themes/theme_name'
dest: 'www/host.com/sites/all/themes/theme_name'
I've tried running it without incapsulating it inside the "theme:" object which works, but is essentially not what I want to do as I have different folders I want to transfer.
Any ideas to what a solution might be?
I found the answer myself.
'ftp-deploy':
Should of course not be included in the file.

Getting moodle version info, no admin access

Is there a way to obtain version info for a moodle site using only "teacher" level access? It seems as though this ability was removed in versions 1.9.7 and above. I'm trying to automate the process of uploading tests and having the version info would be rather handy.
In order to see the current version of moodle you just need to read this file:
http://yourmoodlesite/lib/upgrade.txt
Here's more information about it:
https://github.com/moodle/moodle/blob/MOODLE_29_STABLE/lib/upgrade.txt
Sorry, these instructions may seem somewhat obscure, but it's the only way I could find to get the version of Moodle with only "teacher" level access.
As a teacher, you should be able to create a backup of any of your courses (though this capability may have been removed in the Moodle you're using). Backups are just zip files, but instead have a .mbz extension. If you change this extension to .zip, you'll be able to extract the zip. With the zip extracted, open "moodle_backup.xml", in there you should find the "moodle_release" item somewhere near the top, giving you the version of Moodle used to create the backup.
Being a TA, I didn't want to mess around with backups which sounds weird but given my unique position, reasonable (to me).
On the implementation of moodle I use, with TA privilege, a link to moodle docs is present at the bottom of the page and if you open this link, it takes you to the moodle docs page with moodle_url/moodle_version/___.
Maybe this is peculiar to my system, but I believe it's a default setting thing.
The most dirty way to do so when no admin or file access, is doing differs from public files between versions. As example, index.php file can be 1024Kb lenght on v1.x and 1033Kb lenght on version 1.2.
Also, check for existance/non existance of a set of files is a common way (css, html, js, icon, etc)
I will edit this again if i find a specific solution.
First edit:
For versions 19 or above, you can check version direcly from readme.txt file at https://github.com/moodle/moodle/blob/MOODLE_19_STABLE/README.txt
If you don't even have an account on the instance, you may still be able to find out the version. Any authentication errors in the API will return an error message of the form:
[{
"error":true,
"exception":{
"message":"Course or activity not accessible.",
"errorcode":"requireloginerror",
"link":"https:\/\/moodle.example.com\/",
"moreinfourl":"http:\/\/docs.moodle.org\/36\/en\/error\/moodle\/requireloginerror"
}
}]
And the moreinfourl contains an approximate version number (in this case 3.6). For me, this page was requested when I visited the login page for the instance - a POST request to
https://moodle.example.com/lib/ajax/service.php?sesskey=JQrdIcgMn4&info=core_fetch_notifications
My helper function here:
https://gist.github.com/tigusigalpa/af051a9112512b1b0369572b5dbea2fd
function checkMoodleVersion($version, $checkfor = 'all', $compare = '<=') {
global $CFG;
$versions = [
'3.1' => [
'version' => '2016052300',
'release' => '3.1'
],
'3.2' => [
'version' => '2016120500',
'release' => '3.2'
],
'3.3' => [
'version' => '2017051500',
'release' => '3.3'
],
'3.4' => [
'version' => '2017111300',
'release' => '3.4'
],
'3.5' => [
'version' => '2018051700',
'release' => '3.5'
],
'3.6' => [
'version' => '2018120300',
'release' => '3.6'
]
];
switch ($checkfor) {
case 'all':
if (isset($versions[$version]['version'])) {
return version_compare($versions[$version]['version'], $CFG->version, $compare) &&
version_compare($version, $CFG->release, $compare);
}
break;
case 'version':
case 'release':
if (isset($versions[$version][$checkfor])) {
return version_compare($versions[$version][$checkfor], $CFG->$checkfor, $compare);
}
break;
}
return false;
}
Not by default as this could be used to harvest out of date moodle sites.
You could create a script to do this fairly easily, eg:
<?php
require_once('config.php');
echo 'Version: '.$CFG->version;
echo 'Humand readable release: '.$CFG->release;