I am searching for a TYPO3 extension that lets me define variables and use them everywhere in the TYPO3 backend (something like %CEO_NAME%).
The customer wants to define names and addresses (for their CEO for example) centrally, so that when another person gets the job they can just change it once and it gets replaced in every RTE, page title, keyword, etc.
Is there some extension that would allow me to do that easily or is there an easy way this could be achieved with TS?
If at all possible I would like to avoid writing an own extension for this as the budget is somewhat tight on that project.
There are some possibilities with typoscript. Which means no editor can maintain the replacements.
One solution:
at last in the rendering process you replace any occurence:
page = PAGE
page {
:
do the rendering of the page
:
// now replace any occurence:
stdWrap.replacement {
1.search = __CEO__
1.replace = John Doe
2.search = __COMPANY__
2.replace = ACME
}
}
Be careful to select an unique key as the replacement is done everywhere (in HTML tags, in (inline) javascript/CSS, ...).
Advantage: this replacement can use regular expressions.
Next solutions:
Enhance the parsefunc, which is used for textarea fields.
tt_content.text.20 { <- example
parseFunc {
constants {
// replaces '###CEO###' with 'John Doe'
CEO = John Doe
}
short {
__CEO__ = John Doe
}
}
}
This will replace the markers only in the fields this parseFunc is active.
Related
I'm customizing an existing DocType(quotation) and I've added fields to the Quotation Item child table which affect the amount field of an Item. By default, i.e. before customizations, the grand_total, and Quotation net_totals get calculated as soon as an Item changes. But now that I have custom fields, how can I call the hypothetical "refresh" functions that do the default calculation?
Here is my current Custom Script that updates the Item amount on Quotation Item child table:
frappe.ui.form.on("Quotation Item", "paint", function(frm, doctype, name) {
let row = locals[doctype][name];
let rate = row.labour + row.trim + row.paint + row.spares;
row.rate = rate;
let total = rate * row.qty
row.amount = total;
refresh_field("items");
});
There are few techniques to achieve your goal.
The most effective one will depend on the HOOKS, specially :
doctype_js
override_doctype_class
As the first will allow you to run your js code along with the original doc js code.
And the second will allow you to override the original doc class and will give you the capability to call the hypothetical method you override.
You can check the below links for more details:
doctype_js
override_doctype_class
I want to build a multipage from.
The first page asks for first name and last name.
I want to greet the user with his first name in the second page.
The best way to do this is to use Live Merge Tags with Populate Anything:
https://gravitywiz.com/documentation/gravity-forms-populate-anything/#live-merge-tags
If you collected the user's first name in a Name field on page 1, you could great him in the field label for a field on page 2 like so:
Hello, #{Name (First):1.3}
(In this example, the field ID for the Name field is 1. The 3 refers to the first name input of a Name field and will always be 3).
If avoiding another plugin (as useful as that one is), you can use either the pre_submission_filter or pre_submission hooks to do this.
If their name was field 1 and lets say the field you'd like to show is field 2...
// THESE FOUR FILTERS WORK TOGETHER TO PRE-POPULATE ALL SORTS OF STUFF, AND YOU CAN ADD TO THIS AS NECESSARY. MINE IS ABOUT 1500 LINES LONG AND IS USED BY SEVERAL FORMS.
add_filter('gform_pre_render', 'populate_forms');
add_filter('gform_pre_validation', 'populate_forms');
add_filter('gform_pre_submission_filter', 'populate_forms', 10);
add_filter('gform_admin_pre_render', 'populate_forms');
function populate_forms($form) {
$form_id = $form['id'];
$current_form = 2; // pretending the form id you are working on is 2.
$future_form = 10; // imaginary form you'll create later for another purpose.
switch($form_id) {
case $current_form:
$first_name = !empty(rgpost('input_1_3')) ? rgpost('input_1_3') : null; // gets the value they entered into the first-name box of field 1.
foreach ($form['fields'] as &$field) {
if ($field->id === '2') { // Make as many of these as necessary.
if ($first_name) { // make sure there's actually a value provided from field 1.
$field->placeholder = $first_name; // not necessary, just habit since sometimes you'd need to have a placeholder to reliably populate some fields.
$field->defaultValue = $first_name; // this is the piece that will actually fill in the value like you'd expect to see in your question.
}
}
}
break;
//case $future_form: do more stuff.
//break;
}
return $form;
}
That should be a decent start for your functionality plugin where you can populate the current and future forms without much hassle. This can also be done with the gform_field_value hook; I've always found the language a bit clumsy with that one, personally.
The plugin mentioned earlier is definitely neat, but I found myself wanting to rely on that stuff less and less.
I have a w2ui form that contains a w2ui Drop List of choices. The choices will be different depending on what the user selected to bring up the form. My question is: can the contents of a Drop List be changed after it has been rendered?
With standard HTML controls, I would do something like this:
$("#mySelect option[value='xyz']").remove();
or
$("#mySelect").append('<option value="abc">abc</option>');
Can these kinds of operations be done with a w2ui Drop List? Any example code?
In w2ui 1.5 you can use $jQueryElement.w2field() to access the w2fild object - and then manipulate it.
Example:
var field = $("#my_input").w2field();
field.options.items = ["my", "new", "items"];
// optionally: pre-select first item
field.setIndex(0);
// if you do NOT use "setIndex" you need to call "refresh" yourself!
// field.refresh();
Note: setIndex() internally calls refresh() - so as stated above, you do not need to call refresh yourself in that case.
If you want to completely clear/empty your field, you can call field.reset().
Edit: after clarification that it's about a form field:
// Note: ``this`` refers to the w2form
// ``field[8]`` refers to a field of type "select"
this.fields[8].options.items = ["my", "new", "items"];
this.record = {
field_select: 'new'
};
this.refresh();
I do have a form. This form submits for example 3 words (beer, coke, wine). In the next action I do want to have a three choice widgets with one or more choices:
-beer: //first choice field
* buddy lighty //choice one
* busch //choice two
* miler //choice three
-coke: //second choice field
* coke diet
* coke
* coke vanilla
-wine: //third choice field
* bordeaux
* suave
* champange
<submit-button>
I want every choice in one action. So if somebodey make a choice busch, coke, suave will be submittet. How can I realise it?
Update:
Thanks for the comment. I might forget to say that I don't know how many dropdown menus I need. There might be just beer and coke or beer, coke, wine and juice. It depends from what the user fill out the number of forms the action before! I tried to do it with a foreach-loop in forms.class.php. But it doesn't help.
I use Doctrine.
One simple way to do this (depends on your model, too) is to configure each item as nullable, and then use form options to show/hide certain widgets. e.g., if your schema looks like this lazy example:
DrinkOrder:
columns:
# ...
beer:
type: enum
values: [Old Peculier,Tribute,Deuchars]
notnull: false
wine:
type: enum
values: [Bordeaux,Suave,Champagne]
notnull: false
# ...etc
Configure your form like this:
class DrinkOrderForm extends BaseDrinkOrderForm
{
public function configure()
{
if ($this->getOption('hide_wine'))
{
$this->widgetSchema['wine'] = new sfWidgetFormInputHidden;
}
// … etc
}
}
And then when the action of the previous form submits you can pass options to the form, like:
$this->form = new DrinkOrderForm($drink_order, array(
'hide_wine' => true,
'hide_beer' => false,
));
This is just a quick example - instead of an ENUM type, you could use relations to another table (e.g. wine_id and an sfWidgetFormDoctrineChoice widget & validator).
One thing you can't do is have 3-4 separate forms, because web browsers will only submit one of them. You either have to embed forms within each other, or use the simpler technique above, depending on how your model's set up.
If the number of types of choice isn't fixed, then you'd want to look into using something like the form system's embedRelation method (or the ahDoctrineEasyEmbeddedRelationsPlugin) to dynamically add sub-forms. It's hard to know from your example just how far you want to go. :)
I'm implementing a search box using CodeIgniter, but I'm not sure about how I should pass the search parameters through. I have three parameters: the search string; product category; and the sort order. They're all optional. Currently, I'm sending the parameters through $_POST to a temporary method, which forwards the parameters to the regular URI form. This works fine. I'm using a weird URI format though:
http://site.com/products/search=computer,sort=price,cat=laptop
Does anyone have a better/cleaner format of passing stuff through?
I was thinking of passing it into the products method as arguments, but since the parameters are optional things would get messy. Should I suck it up, and just turn $_GET methods on? Thanks in advance!
Query Strings
You can enable query strings in CodeIgniter to allow a more standard search function.
Config.php
$config['enable_query_strings'] = FALSE;
Once enabled, you can accept the following in your app:
http://site.com/products/search?term=computer&sort=price&cat=laptop
The benefit here is that the user will find it easy to edit the URL to make a quick change to their search, and your search uses common search functionality.
The down side of this approach is that you are going against one of the design decisions of the CodeIgniter development team. However, my personal opinion is that this is OK provided that query strings are not used for the bulk of your content, only for special cases such as search queries.
A much better approach, and the method the CI developers intended, is to add all your search parameters to the URI instead of a query string like so:
http://site.com/products/search/term/computer/sort/price/cat/laptop
You would then parse all the URI segments from the 3rd segment ("term") forward into an array of key => value pairs with the uri_to_assoc($segment) function from the URI Class.
Class Products extends Controller {
...
// From your code I assume you are calling a search method.
function search()
{
// Get search parameters from URI.
// URI Class is initialized by the system automatically.
$data->search_params = $this->uri->uri_to_assoc(3);
...
}
...
}
This would give you easy access to all the search parameters and they could be in any order in the URI, just like a traditional query string.
$data->search_params would now contain an array of your URI segments:
Array
(
[term] => computer
[sort] => price
[cat] => laptop
)
Read more about the URI Class here: http://codeigniter.com/user_guide/libraries/uri.html
If you're using a fixed number of parameters, you can assign a default value to them and send it instead of not sending the parameter at all. For instance
http://site.com/products/search/all/somevalue/all
Next, in the controller you can ignore the parameter if (parameter == 'all'.)
Class Products extends Controller {
...
// From your code I assume that this your structure.
function index ($search = 'all', $sort = 'price', $cat = 'all')
{
if ('all' == $search)
{
// don't use this parameter
}
// or
if ('all' != $cat)
{
// use this parameter
}
...
}
...
}