Leaderboard

Hi @Clarity - sorry, I am a bit lost as to what you are asking. Are you referring to a particular action? Is there a place where you are being asked to enter things like 'select', 'text, 'AsmSelect', etc? Maybe post a screenshot of the interface you are finding confusing, or if you are writing a new action, then the list of available field types is only limited to the fields in ProcessWire so that is where you should go for a complete list. Is that what you're looking for?

Field that stores one or more references to ProcessWire pages with additional data in field context. Values are editable via page edit modal of the referenced page provided from the field if module AdminPageFieldEditLinks is installed and "Enable link to create new pages?" is checked in field settings. Requirements: AdminPageFieldEditLinks >= 3.1.4 https://github.com/kixe/FieldtypePageContextData https://processwire.com/modules/fieldtype-page-context-data/ Use case example: The planning of the Tonmeistertagung in the CCD (Congress Center Düsseldorf) from November 3rd, 2021 to November 6th, 2021 is in the finalization phase. The conference consists of a conference part and an exhibition. The planning is done via a separate frontendless PW instance. There, all companies (pages) that are active at various events are kept in a pool. Changes (address, logo) can always be done there. For the exhibition of the current conference in November, the exhibitor-companies (pages) are selected via a page reference field. A stand number must now be assigned to each selected company (page). We had originally solved this using the Profield FieldtypeTable. However, this had the disadvantage that each entry again made all companies available for selection and did not recognize which were already selected in a previous table row. The new field type now allows the value (company's stand number) to be assigned to a Company (page) in context to a specific Pagefield living in a specific page. https://tonmeistertagung.com/en/exhibitors/exhibition/

@MrSnoozles Edit 1: Thanks for feedback. I fixed it in the recommended way. Edit 2: It's good that you found a solution to your needs.

Thanks for the reply. Will try in the evening and report back. I'll also try to have a look into why ProcessUser is removing the GET parameters. EDIT 1 (FieldTypeSelect): I did test the new version. When I configure "option1\noption2" the select shows: option1 option2 option1\noption2 This is because in line 387 $inputfield->option = trim('option1\noption2'); is being called, adding the full settingValue as another option. If you continue; in the block where you're checking if the inputfield is a select, it should be working. Also instead of using "\n" or "\r\n" you could probably use the constant PHP_EOL which contains the line separator for the operating system PHP is running on. EDIT 2 (Editing pages of template user): So far I've found out that the redirect is because of the method ___setEditor() in wire/core/User.php. It leads to a redirect that strips the two parameters &forpage und &forfield. If they are appended, everything works correctly. One way to solve it would be to not use ProcessUser and use ProcessPageEdit instead by adding this code to your init method: // do not redirect to a page using ProcessUser when editing a page relation $this->addHookBefore('User::setEditor', function (HookEvent $event) { if(!$this->input->get('forpage') || !$this->input->get('forfield')) { return; } $event->cancelHooks = true; }); This is not yet optimal though, because in the edit screen the "name" is shown in all languages. But imo it's good enough for now. A better way would be if the method editUrl() in the User class would keep the url parameters. But that would be a core issue.

I created a companion module for Fluency to translate all fields on a page at once: https://github.com/robertweiss/ProcessTranslatePage You can find the corresponding conversation about it in the Fluency thread (link below), but I decided to add the module to the official list so others who have a need for this have an easier time finding it.

Like I've got a resave action or some other action I need to run on a certain pages selected with, well, a selector field. The selector is the same, but each time I run it I need to re-enter it again and again. And I do run this for a couple of sets of options. That's where savable option sets or bookmarks would come handy.

@adrian and @Pete! Do you think we should transform this thread into a dedicated sub-forum like the one for tracy debugger? There are 10 pages now. And the questions are really diverse due to the nature of the module. This move could also make us think more about sharable actions.

OK, will try to use variables then to insert the newline character. But it’s definitely in the docs. See the attached screenshot.

I cannot find any example with newline character in the docs? Do I oversee something? I thought that escape characters are not supported by the translation. If I'm right, maybe it should be written explicitly in the docs too. I think the right usage is or can be like this: // use %s with sprintf() $out = sprintf(__("It's time for you %sto get to the party."), "\n");

I'm writing custom admin action and trying to figure which types can be written in 'type' field, like in this code: return array( array( 'name' => 'fields', 'label' => 'Fields', 'description' => 'Select the fields you want to delete', 'notes' => 'Note that all fields listed are not used by any templates and should therefore be safe to delete', 'type' => 'checkboxes', 'options' => $fieldOptions, 'required' => true ) ); If these types fully correspond to Inputfields in ProcessWire, then it solves my problem. I was not sure about it. Thank you.

I've pushed a fix. The separator must be translated into a real line break (expected by the Inputfield). I changed the translation to "\r\n" instead of "\n" only, which should work cross platform. Continue to use the string '\n' in the field settings. Please update to version 1.0.1. Could you please give feedback if it works? The pipe '|' you mentioned is already reserved to separate an option 'value' from the option 'title' (@see SelectableOptionManager). I prefer to handle the setup according (very close) to the expectations of the inputfield. ProcessUser and possibly some other processes for editing system pages are not supported. In the special case of ProcessUser, the GET-Parameters forfield and forpage are removed from the url of the modal window for whatever reason. Any idea? The module is still in an alpha stadium. Thanks for testing and feedback.

This is amazing! I have missed this functionality in ProcessWire for a while already. Installation Install AdminPageFieldEditLinks: https://processwire.com/modules/admin-page-field-edit-links/ Install FieldtypePageContextData (this module) Create a new field of type "Page Reference Context Data" When setting up the field: in tab "Details" enter configuration in "Additional page fields in Pagefield context". You can see many examples here https://github.com/kixe/FieldtypePageContextData in tab "Input" select "Enable view/edit linnks on selected pages?". If you don't see this field the module AdminPageFieldEditLinks is not activated in tab "Input" when changing the label field: you can also use the additional context fields as label in the page reference. Symply change your label to a custom label and define it like so: {title}, {_customfield1}, {_customfield2} assign the field to your template Screenshots When installed and configured correctly you see the page reference like normal. But now you can click it and edit the page in a modal. This modal also contains a new tab "Pagefield Context Data" (the name of the tab can be changed in field settings). Bugs found so far On Windows: separating option values for select by \n is not working correctly. Maybe use | instead? (as that's how ProcessWire separates fields) for the user template the tab "Pagefield Context Data" is not being displayed Very well done. This is SO useful! ♥

There's a couple things that made me think this part of the core could be better (and nothing related to middleware). First is that PW didn't originally support multi-language URLs, and so the LanguageSupportPageNames module was built to hook in and add support for that. There are benefits (performance, simplicity, etc.) to having that logic lower-level in the core and part of the same logic that identifies non-multi-language URLs. So that's something I've been interested in for a long time, but it was always more than I wanted to get into. The other thing is that I was working on that SessionAllow module and found it was a real drawback not to be able to know what Page was requested before deciding on things like whether to allow a session or not. Granted, we can still know the request URL before we know the Page, but it just seemed a lot more flexible for the core to know the requested Page much earlier in the boot process. That way, we can do things like configure whether sessions are allowed on a per-template basis, where such an option seems to make the most sense. Another example is 404 pages—maybe we don't need a session on a 404 page. But without knowing whether the URL will resolve to a Page or not, we didn't have that choice. Following these updates, we will. Lastly, I just like to revisit the core logic for things and improve it when/where possible, which helps to keep it fresh on the mind. But I don't like to get into replacing this kind of major core code when it'll soon be merged to the master, as this is the kind of stuff that needs more testing over a longer period of time. So with a comfortably stable master version available right now, it seemed like a good time to work on this.

Hi. Not tested but should work $this->wire()->addHookAfter('LanguagesPageFieldValue::getStringValue', function ($event) { $value = $event->return; $languagesPageFieldValue = $event->object; $languages = $this->wire()->languages; $userLanguageID = $this->wire()->user->language->id; $chineseLanguageID = $languages->get('chinese')->id; $newFallbackLanguageID = $languages->get('english')->id; if($userLanguageID === $chineseLanguageID && !$languagesPageFieldValue->getLanguageValue($chineseLanguageID)) { $value = $languagesPageFieldValue->getLanguageValue($newFallbackLanguageID); if(!strlen($value)) { $value = $languagesPageFieldValue->getDefaultValue(); } }; $event->return = $value; });

Sorry for interrupting the usual programm and topic here but... @franciccio-ITALIANO maybe you want to look up a mentor/tutor here that helps you to maintain and build ProcessWire sites from either the ground up or even to maintain already built sites. I know you from your past questions, requests and and posts in several other topics. As much as I want to see someone helping you... the more I think you need someone that's guiding you from the basics of PHP to the basics and fundamentals of ProcessWire to the state you can work out ProcessWire sites from each and every state and upwards. So... my questions for our awesome community is... who can help and assist @franciccio-ITALIANO to get to a state where he is able to maintain a basic ProcessWire-website? Native italian speakers (is this even the correct way to write this?) go ahead... and let us know. If there is noone who can assist... let me know @franciccio-ITALIANO... I'll put time aside to guide and assist you in some kind but in english. ;)

Did you check read and write rights on the server location (folder) where you install processwire ?