Have done the below mentioned setting for increasing custom variables in piwik---
const MAX_CUSTOM_VARIABLES = 15; in tracker.php in piwik
why I did this is because we don't have console functionality because as per the mentioned
on piwik's site the actual way should be ---
const MAX_CUSTOM_VARIABLES = 15; in tracker.php in piwik
but when I performed the above step it gave me error ./console: No such file or directory
moreover now the problem lies that even editing tracker.php is not working out for me.
This const was removed in Piwik 2.*. There is no possibility to extend the number of custom variables in Piwik 1.*. Please update to the latest Piwik. Then you will be able to adjust the number of custom variables using this command:
./console customvariables:set-max-custom-variables 10
Please remember, that this command alters log_visit, log_link_visit_action and log_conversion tables, so it may take some time to complete.
Related
I am using the oidc-client library to authorize with our own Identity Server 4. It is working fine and I need to extend the login functionality. I'd like to use the OIDC-Parameter "prompt". The parameter is sent correctly to the connect/authorize endpoint. When the Login-Method is called, I am trying to get the AuthorizationContext by calling
var context = await _interaction.GetAuthorizationContextAsync(vm.ReturnUrl);
var prompt = context.PromptModes;
_interaction is an instance of IIdentityServerInteractionService. The PromptModes are always empty. Is this the right way I am trying to access them?
Thank you
It looks like you check the value in an inappropriate place.
The answer for a similar question on Github was:
we have to remove the prompt parameter because we would otherwise run into an endless loop. You could save the parameter in a separate parameter I guess.
Background: Our pagetree doesn't work with language overlays nor with seperate domains for each domain. The different languages are represented by subtrees below the domain.
Pagetree:
example.com (Rootpage + sys_domain)
de
Seite 1
Seite 2
en
Page 1
Page 2
We're using TYPO3, EXT:solr and Solr.
Is it possible to use different Solr cores for different subtrees within a domain in TYPO3?
So far, I found a solution for handling different languages and cores based on TS-Conditions: [globalVar = GP:L = 1]. But that's not our use-case.
Further, I found a 6 years old question which exactly represents the use-case, but doesn't have a positive answer (https://forum.typo3.org/index.php/t/158570/).
Can somebody give me a hint? Is this use-case possible?
Yes, this is possible with version 7 of EXT:solr
Set "Use as Rootpage" on page "de" and page "en"
Remove "Use as Rootpage" on Rootpage, if set (if using EXT:realurl, make sure to set it in the configuration explicitly)
Add the following lines to your AdditionalConfiguration.php
`
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']['sites']['<uid of page "de">']['domains'] = ['your.domain.de'];
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']['sites']['<uid of page "en">']['domains'] = ['your.domain.de'];
Configure the cores on page "de" and "en" in TypoScript constants as you need it
`
plugin.tx_solr {
solr {
scheme = http
host = <your-solr-dhost>
port = 80
path = <your-solr-core>
}
}
Then you need to scheduler tasks to index the site ... one for "de" and one for "en".
Works pretty nice here :-)
From my experience it is most probably not possible.
The reason is, that EXT:solr tools need one common TypoScript configuration which works for both backend and frontend context at the same time.
That is why they choosed to evaluate the TypoScript configuration not based on a frontend request (which would make it possible to differ the configuration on any position in the page tree) but based on pages marked as domain roots.
So, the configuration parser looks for such pages first and then evaluates TypoScript setup at that specific level/point in the tree.
I think your only solution is to make rather deep changes to the machanism described above, which is possible and I made it myself (to exclude some root level pages because I had many of them).
This way you can probably instruct the engine to fetch the TypoScript setup from whatever fixed position in the tree you want.
If you are interested to try this, this will be the class method to extend: ApacheSolrForTypo3\Solr\ConnectionManager::getConfiguredSolrConnections()
I have values in file:
en-us, de-de, es-es, cs-cz, fr-fr, it-it, ja-jp, ko-kr, pl-pl, pt-br, ru-ru, tr-tr, zh-cn, zh-tw.
how can I get this values for one request?
I want to create a query that takes the value of these in turn and writes the variable
This scenario can be achieved using Jmeter component "CSV Data Set Config"
Please refer to below mentioned link:
Jmeter CSV Data Set Config
Hope this will help
Can't comment, not enough karma. In response to above questions your path is probably wrong. If you use a debug sampler to show what path the CSV reader is taking I think you will find it is looking at something like C:/Jmeter/C:/path/to/CSV/file.
Another option for completing this is to use inline CSVRead. In your HTTP request use code like this -
${__CSVRead(etc/filters.csv,0)}${__CSVRead(etc/filters.csv,next)}
etc/filters is the RELATIVE path from Jmeters active running directory. In my case this evaluates to
C:/git/JmeterScripts/etc/filters.csv
In either case, I am sure your problem is that Jmeters active running directory is not what you think it is. I have had this problem several times with the same error.
i have installed wordpress and i i have installed couple of plugins and i have got two themes already came with wordpress.
What i am asking about today is : what does the Plugins & Theme string value in database mean ?
Example [When plugins are active] , there is a value on table of :
a:3:{i:0;s:19:"akismet/akismet.php";i:1;s:9:"hello.php";i:2;s:37:"one-click-logout/one-click-logout.php";}
Example [When there are themes on the Themes folder] , there is a value on table of :
a:2:{s:12:"twentyeleven";s:7:"/themes";s:9:"twentyten";s:7:"/themes";}
I could get an explanation of what does the "a" and "i" mean from HERE , but the "s:" is what i do not know what does it mean.
If i tried to change the s:37 to s:6 or any other value , the plugin becomes deactivated , so the s:37 <<< the 37 must mean something or related to the plugin somehow and that`s what i am trying to find out.
's'+number is just number of characters.
so s:12:"twentyeleven" means string of length 12.
I suggest asking this in the WordPress Answers rather than here. This is a very specialist question.
The whole point of WordPress is that you DON'T need to get into the guts of the database - in fact it is highly discouraged since the data may well change between releases.
WordPress has loads of API functions that allow you to make use of it's power without needing to get into the complexities of the database. That is one of it's key strengths.
Even as a WordPress programmer or theme designer, you won't need this information - ever. You would only need to know it if you are planning to write/amend the source of WordPress itself, in which case, you are definitely in the wrong place.
I am using the Drupal 7 Migrate module to create a series of nodes from JPG and EPS files. I can get them to import just fine. But I notice that when I am done importing them if I look at the nodes it creates, none of the attached filefield and thumbnail files contain filename information.
Upon inspecting the file_managed table I see that both the filename and filemime fields are empty for ONLY the files that I attached via the migrate module. This also creates an issue with downloading the files.
Now I think the problem has to do with the fact that I am using "file_link" instead of "file_copy" as the file operation I specify. The problem is I am importing around 2TB (thats Terabytes) of image files. We had to put in a special request with Rackspace just to get access to that much disk space on our server. So I can't go around copying from one directory to the next because of space issues. So "file_link" seems like the obvious choice.
Now you probably want to see how I am doing this exactly, so here is the code snippet:
$jpg_arguments = MigrateFileFieldHandler::arguments(NULL,
'file_link', FILE_EXISTS_RENAME, 'en', array('source_field' => 'jpg_name'),
array('source_field' => 'jpg_filename'), array('source_field' => 'jpg_filename'));
$this->addFieldMapping('field_image', 'jpg_uri')
->arguments($jpg_arguments);
As you can see I am specifying no base path (just like the beer.inc example file does). I have set file_link, the language, and the source fields for the description, title, and alt.
It is able to generate thumbnails from the JPGs. But still missing those columns of data in the db table. I traced through the functions the best I could but I don't see what is causing this. I tried running the uri in the table through the functions that generate the filename and the filemime and they output just fine. It is like something is removing just those segments of data.
Does anyone have any idea what this could be? I am using the Drupal 7 Migrate module version 2.2. It is running on Drupal 7.8.
Thanks,
Patrick
Ok, so I have found the answer to yet another question of mine. This is actually an issue with the migrate module itself. The issue is documented here. I will be repealing this bounty (as soon as I figure out how).