dragan

If you don't need the PW API to process the form, you can place your script in root. action="<?=$config->paths->root . 'myscript.php'?>" Although, as already mentioned, I'd suggest to create a PW page + dedicated template for such stuff. Together with URL segments, you can place all your form processing logic in one single file (or even include() each sep. form processing logic, in case there's many of them). Well, actually URL segments aren't really needed, you can just as well include a hidden field in your form, or add a ?form=support to your action URL. Many ways to skin a cat ?

The easiest way to make sure you always populate the default language, is a one-liner before all your regular page-creation functions: $languages->setLanguage("default"); and of course, if you always explicitly want to edit the french value: $languages->setLanguage("fr");

You don't need a hook for that. Just render the page title in your frontend template dynamically. Maybe something like this: $pageTitle = $page->title; if($page->template === 'product' && isset($page->design)) { $pageTitle = $page->design->title; } ?> <title><?=$pageTitle?></title>

@MSP01 I'm no expert on PW's auto join, but re: 2.) I think PW will definitely fire SQL behind the scenes each time you use such a helper function. What you could do instead, is maybe create your own $config vars. That's a perfect use for global settings, e.g. image resize options, or define your own custom paths/URLs etc.

I'm having a Case of the Mondays™ today... I've been using PW now for some 7 years or so, and most sites were multilanguage setups. Today I was trying to "upgrade" a PW site and add a 2nd language, and everything works as expected, except one strange thing: The default pagetitle field (id 1) only shows up in the page editor with default input language field. If I switch from german (default) to english in the admin, I see the english titles just fine in the page tree. However, when I open a page (any page, any template), I only see the german field, without the UI folder icon, or tabs). The API correctly gives me the language values I'm expecting. I thought maybe I wrote a hook a long time ago which causes this behavior, but I disabled my site/ready.php altogether, and things are still the same. Does anyone have a clue where to look, and how to debug? The UI elements are not there when I inspect the field in the browser (i.e. they are not just hidden by CSS, they're not there). What module or config could possibly cause this? And it's ONLY the pagetitle field that is screwed, all other text- and textareafields work fine. Update: I had a "pseudo multilang" field title_en, which caused havoc. Once I renamed (and finally deleted) this field, everything wente back to normal.

This may seem like a hackish workflow proposal, but you could just as well clone the production page, unpublish that copy, and work on that. If the clone is ready to be published, publish that one and hide / unpublish the other. Just bear in mind to adjust the page names and -names to avoid ugly looking URLs like /section/my-page-name-copy and 404s.

Another good reading material: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/

Sorry to flood the module dev forum lately with questions, but I thought I'd better create separate threads for each question (they're somewhat related, though not quite the same issues). I built a simple module that allows users to create new pages. That all works all quite nicely, but I noticed some differences how PW handles validation. I created a public function ___executeAddNewFooPage() in my module, which takes the form values from the main ___execute() function. What I would like to do though, is the same behavior like in a module configuration screen: Stay on the same page if there are errors (form not valid). I can detect invalid fields just fine in ___executeAddNewFooPage() and link back, display red errors at the top, but then each field, which is not a text-based field, loses the user's values, i.e. selects are reset, text + textarea field values are intact. I tried setting the form action to itself, i.e. "./" instead of "./addnewfoopage", but that doesn't change anything. What I would like to achieve is that the user stays on the page, and sees field errors like e.g. in the WireMail module config screen: I've searched the forums far and wide, but didn't find any related infos. If someone can enlighten me, I'd appreciate it very much.

I have built a simple process module that allows users to create new pages; so far, so easy. Now I noticed something strange, and I'm not sure if I miss something, but it seems inconsistent to me: Text-based input fields get the HTML5 attribute required="required" and it works as expected. However, for selects (InputfieldPage, InputfieldAsmSelect) PW only injects a CSS class "required", but doesn't set required="required". Example code: $field = $this->modules->get('InputfieldPage'); $field->inputfield = 'InputfieldAsmSelect'; $field->parent_id = 1221; $field->labelFieldName = 'title'; $field->name = 'service'; $field->label = 'Dienstleistungen'; $field->required = true; $field->setAttribute('required', 'required'); $field->columnWidth = 33; $field->collapsed = 9; $fieldset->add($field); I know I could create a hook and inject that attribute (maybe something like this?), but it seems like overkill, when we can already configure the fields. Am I missing something obvious here?

Perhaps this is a stupid question to seasoned PW module developers, but here it goes: I'm trying to put together a module with various fieldsets, where users can enter form values and save to PW-pages (or elsewhere). I see that the entire module content is wrapped in one single form. I know I can split a module into several pages, but I'd like to have collapsible fieldsets instead. Can I create multiple forms, with each one having its own form action? Or is there another workaround / method to accomplish this? I know I could do some JS/AJAX stuff (e.g. a button with a click handler sending data to another PHP script inside InputfieldMarkup), but I'd prefer to stick to "the PW way" as much as possible.

Bonjour Chris, and welcome to the ProcessWire forums. You should be able to get the correct counts with this method. The digit you see there is simply the language page ID (setup -> languages -> hover over the language code). I agree that this is not very intuitive, compared to most PW API methods... An alias selector like lang=fr (language shortcode) would be easier to memorize.

Are you really sure you want to add that to every single link? What about email links? Anchor links? Links to internal PW-pages? If so, you could inject these with a hook, or via JS; but if you have lots of pages and RTE fields, that might not be the most efficient approach. But apparently, you can also configure CKEditor to do what you want: https://ckeditor.com/old/forums/CKEditor/Set-link-default-target-to-new-window-blank https://ckeditor.com/docs/ckeditor4/latest/guide/dev_howtos_dialog_windows.html http://handsomedogstudio.com/ckeditor-set-default-target-blank

That's what I was going to suggest as well. A little hint:

The HTML you get is the login form. It looks like you get logged out randomly. Did you try to delete all cookies from your site, logout and login again? I have no clue how this might be related to file/image uploads though. Here's a forum thread with login issues that might give you some hints how to troubleshoot. Also, is there anything special about pages with ID 3942 + 3947? (those appear in the SQL error and the HTML action attribute). Perhaps the database got corrupted somehow?

I'd recommend Laragon too. And WinSCP instead of Filezilla. If you have the budget, get a good IDE as well - my recommendation would be PHPStorm by JetBrains. In order to profit from IDE hints, you can use the pages()->find syntax instead of $pages->find (just an example - I don't have time right now to search for the docs or blog/forum posts explaining this - here it's called "API variables as a function"). You can get rid of an FTP client altogether, if you configure PHPStorm to automatically upload files upon save, which is a big time-saver. These days, I'm sure most (all?) of JetBrains' functionality can be had with VSCode as well, but I'm not sure if there are still significant differences (probably means installing a few plugins).

I'm not really sure what you're asking. The above DIV- and SPAN-soup is certainly not a product of the official CKEditor plugin. CKE uses regular, semantic table, th, tr, td etc. tags. And with semantic tags, you don't need any ARIA or schema.org stuff. Where's that code-block from?

@Robin S Excellent module! Thanks. I have just tried it, and I noticed that the pagination doesn't work. It still works with all other Lister Pro instances. Is this intentional (same as with not being able to sort by clicking on table headings) ? Clicking on any of the pag. numbers actually loads the AJAX file, i.e. I see XHR finished loading: POST "https://mysite.com/admin/setup/lister-selector/page2". Google Chrome, Win 10, latest PW version, no JS/console errors.

@flydev Thanks for this module. Alas, unfortunately it doesn't work here. I have followed your installation steps, changed the JSON to: { "providers": { "google": { "className": "Google", "packageName": "league/oauth2-google", "helpUrl": "https://console.developers.google.com/apis/credentials", "ClientId": "xxxxxxxxxxx-2q54e3b4n232hog8odtk66c7ogj7inl3.apps.googleusercontent.com", "ClientSecret":"xxxxxxxxC0fh1AfF7wwoW" } } } I installed the package via Composer in PW root (vendor folder is next to site/ and wire/). However, I never see a provider screen in the module config after saving. And the frontend example just shows an empty form with just one hidden field. The backend variety throws an error: Fatal Error: Uncaught ArgumentCountError: Too few arguments to function Oauth2Login::hookBackend(), 0 passed in /site/ready.php on line 12 and exactly 1 expected in /site/modules/Oauth2Login/Oauth2Login.module:175 Any idea what I might have missed? edit: I installed the phpleague stuff via Composer locally, and then uploaded the vendor folder via FTP, along with the updated composer.json + composer.lock files. Not sure if that matters. Do I need to move the vendor folder elsewhere, i.e. somewhere in your module's folder maybe?

There are hints in this thread: https://processwire.com/talk/topic/7971-renaming-the-content-tab-when-editing-pages-of-a-given-template/ As mentioned there, this is a working, albeit very hacky solution: (content instead of view tab) // site/ready.php wire()->addHookAfter("ProcessPageEdit::execute", function($event) { $render = $event->return; $template_name = "basic-page"; // Change this to match the exact template name of pages you want to apply tab-renaming to. if (false !== strpos($render, "template_{$template_name} ")) { $render = str_replace("Content</a>", "Content is King</a>", $render); // EN $render = str_replace("Inhalt</a>", "Inhalt ist Kaiser</a>", $render); // DE $render = str_replace("Contenu</a>", "Le roi, c'est le contenu</a>", $render); // FR $event->return = $render; } });

Did you see the comments under 8A? # 8A. Optionally (O) set a rewrite base if rewrites are not working properly on your server. # ----------------------------------------------------------------------------------------------- # In addition, if your site directory starts with a "~" you will most likely have to use this. # https://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritebase # Examples of RewriteBase (root and subdirectories): # RewriteBase / # RewriteBase /pw/ # RewriteBase /~user/ e.g. uncomment # RewriteBase / (remove #) and try again?

Not sure about pre-populating, but maybe this would help too: Define custom sort order (tab "children" -> manual drag-and-drop) in the parent page that holds your FAQs. Then simply move your 5 default answers/pages to the top, so that they're always the first ones in the list. Sort of like you usually see country dropdowns: The top countries at the top, followed by the rest in alphabetic order.

Not me. It sounds like a recipe for headache, frankly speaking. It really depends on lots of things... You should tell us more about your current site. What does it do? How complex is it? How many templates do you have now? How dynamic is it - or needs to be in the future? (for visitors and editors) How much functionality is there currently in terms of users interacting with the site (register, login, user profiles, voting / commenting....) ? Is it really just a "brochure" site (mostly static content for frontend-users, but manageable by editors) ? Or really more like a web-application? A redesign is not the same as porting content from CMS A to CMS B. If the site architecture will most likely remain, then I'd talk to the client and persuade them to allow budget to transfer the entire site in one go from Textpattern to PW (using the same frontend markup). In the long run, this would probably be more efficient. Once everything is running in PW, you could then later discuss about a redesign.

Is that your actual code? There's a missing > there $config->urls->root vs. $config->urls-root https://cheatsheet.processwire.com/config/urls/config-urls-root/ If that was just a typo here in the forum post, you might wanna check Docker-related forum posts, e.g. https://processwire.com/talk/topic/10736-running-a-processwire-site-with-docker/

It works perfectly fine if you just put the code inside a template. I guess using such functions as wireSendFile() inside Tracy aren't meant to work exactly the same (or not at all) as when you are viewing a PW page in the frontend. (I used an image file for testing instead of PDF, but that doesn't matter)

What version do you need? I can see ancient releases @ https://github.com/icecoder/ICEcoder/releases?after=v2.2 ... way back to v.0.5.9 https://github.com/icecoder/ICEcoder/releases/tag/v0.5.9 (2012)