MoritzLost

Awesome, thanks @ryan! ? Now I can update my TrelloWire module so it works properly again ?

It doesn't have to be, but it's certainly best practice. You can point your form directly to a PHP script, but you will have to bootstrap ProcessWire manually if you want to use the API. The PHP script also can't be in the template directory, as direct access to that is blocked by ProcessWire for security reasons – see my answer here. How best to add custom logic to your forms depends on how your form is built: FormBuilder? Use a hook to adjust how it processes the form, Custom form? You can put your logic in the same page template where you build your form. As zoeck mentioned, use the $input API to check if the form has been submitted and handle the inputs there.

@maddmac Thanks for the suggestion! As far as I can tell from the documentation on creating cards, custom fields can't be send in the same POST request the card is created with. But you can utilize a hook to add custom fields whenever a card is created / updated (see the hook documentation for the module). Something like this: wire()->addHookAfter('TrelloWire::createCardForPage', function (HookEvent $e) { $TrelloWire = $e->object; $page = $e->arguments(1); $TrelloWireCard = $TrelloWire->buildCardData($page); $api = $TrelloWire->api(); $cardId = $TrelloWireCard->id; $customFieldId = 'id-of-the-custom-field'; // replace with actual custom field id $api->put( sprintf('cards/%1$s/customField/%2$s/item', $cardId, $customFieldId), ['custom-field-data' => $page->my_custom_field] ); }); Quick and untested, might need some adjustments. I haven't worked with custom fields yet, so I'm not sure what data a custom fields needs (the documentation is also handwavy about it), but this should be a good starting point. A the moment this will only work correctly with the dev version of the module (branch JSON-request-body on Github) and with a core that includes the pull request mentioned above.

@maddmac That's great, good to know it's working in other environments as well ^^ Let me know if you run into any problems!

@maddmac Unfortunately, I recently started having problems with the Trello API as well, and right now I'm not sure that the module will work correctly. I have asked the support if they have changed something in their API-backend, but nothing came of it. Anyway, I have discovered some minor problems with the way the module sends it's requests as well as some major problems with ProcessWire's WireHttp class which prevents the module from connecting to the Trello API using cURL. Unfortunately, I wasn't able to get it to work using sockets or fopen as well. Now, I have submitted a pull request to ProcessWire's core that fixes the issues with the WireHttp class, but as of now it hasn't been merged yet. I have also started work on fixing the issues with the module itself - the dev version is available as a separate branch on Github. The problem is that this branch won't work at all without the fixes to the WireHttp class included in the pull request. So right now, I'm not sure how to put out a release that will work for everyone. The likely path it that I will have to wait until the pull request is merged, and then push out a new release that includes all the related fixes, updating the required ProcessWire version to whichever version the pull request is available in. Unfortunately, the only surefire way to get the module working correctly at the moment is to (1) apply the changes from my pull request to your installation of ProcessWire and (2) manually download the dev version from this branch of the TrelloWire module. Sorry I can't provide a better solution at the moment. I'll keep this thread updated as soon as I can solve those issues! BTW I also plan to add more logging / error reporting, but I first want to get the module working properly again ...

If you're content using just the template cache instead of ProCache, you could do this with my Cacheable Placeholders module, which is designed for exactly this purpose: Having a fully cached site with just some dynamic placeholders which are dynamically replaced. You can add a placeholder wherever you want to output some content with Du / Sie variations and use the callback to server the correct output depending on the cookie value (or whatever). Won't work for ProCache though, as it can't modify the static HTML pages. But if you want to use ProCache, yeah, JavaScript probably. I recently had a similar problem on schwarzdesign.de. The dynamic options there include the theme switch (light / dark theme), as well as the Fridays for Future theme, which is only displayed on friday (use this link to view the theme even if it's not friday ?). Previously, this was done server side by reading a session value which stored the theme preference as well as checking if it's friday and serving the corresponding stylesheets / body classes. In order to be able to use ProCache, I have rewritten that functionality in JavaScript. Now both scripts are included as preloads, and the correct theme is toggled active with JavaScript depending on the stored preference (now using localStorage instead of the session). Maybe you can do something similar, but with JSON files containing translations, and then replacing the texts with JavaScript? You can check out the source code on schwarzdesign.de, it's an inline script in the <head> section, pretty simple in this case. As for SEO, I would definitely serve one version by default (maybe the formal language version) and then just replace it with the information version with JavaScript, if selected ... this way it shouldn't impact your ratings negatively.

The new version 4.1.0 includes an important bug fix: The module will now exclude pages in the trash from being linked!

@psy No idea, I haven't used ProDrafts yet. Though unless I have misunderstood the question, this question is about having public and draft versions of a page's content, not different versions of it's PHP template. So I don't think your suggestion applies to this use-case?

This is the exact purpose of the ProDrafts module!

@Brian Peat Just move your new landing page one level up in the page hierarchy. In the page tree, you will see the "Landing pages" page, and below that your new landing page. Move it up to be on the same level as the "Langing pages" page. If that is not possible due to the template's family settings, you can use the Custom Paths module to overwrite the path for your page to whatever you want.

@Brian Peat Debugging is easier with the Tracy Debugger module installed. The Request Info panel will show you exactly which template is being rendered and which PHP file it's using. Check if it's the correct one and take it from there.

But doesn't that mean the contributor has to manually add their own repo as a submodule? That seems unnecessarily complicated. It comes down to the same thing anyway. A submodule can have multiple remotes, so both the original and the fork can be added as remotes (to keep in sync with upstream changes, while commiting to the fork).

Sounds solid to me. If you want to accept translation changes in the form of pull requests, a contributor will be required to fork the pw-lang-de repository in any case. However, you can still include the submodule in your repository and people don't need to add it manually. Once a contributor has cloned the repository, they can go into the submodule and add their own fork as a remote: $ cd site/assets/files/1019 $ git remote add fork https://github.com/<user>/<pw-lang-de-fork> Then they can do their updates, commit the changes and push to their fork instead of the original repository: $ git add . $ git commit -m "Update translations" $ git push fork master:master Or is this what you meant? ? Anyway, I think that's the most efficient solution with your current setup!

Hi @dotnetic, thanks for maintaining the German translations, we use it in most of our projects ? What are you having trouble with? I would use Composer scripts for both initializing the environment (importing the database) and copying the translation files to the submodule directory. I see you already have a composer.json in your repository – if you put the restore.php in a Composer script and add it to post-install-cmd, the database will be restored when you execute composer install. Likewise, you can add a script that copies the translation files to the submodule's directory. Then one just needs to cd into the submodule and commit the changes.

Not sure about a table layout (of course, you could build it yourself!). But you can change the default process you see after logging in easily. In the page tree, find the Admin page and go to edit. There you'll find a Process option. Switch this from the default (ProcessPageList) to ProcessPageLister to show the page lister by default. If you're using ProLister, the Process might have a different name, not sure right now. After saving, logging in or clicking on the logo in the admin bar should take you straight to the page lister.

Are you using URL Segments or query parameters to detect the currently selected keyword? I don't fully understand your setup. What is the "singles" field you use in your selector? I don't think you need Connect Page Fields for what you're trying to do though. Anyway, once you have your keyword, you can build a query to find all keywords one level below that using the parent selector: $keyword = $input->urlSegment1; $keywordPage = $pages->get('name=' . $sanitizer->selectorValue($keyword)); if ($keywordPage && $keywordPage->id) { $keywordsBelow = $pages->find("template=keywords, parent={$keywordPage}"); // ... use keywordsBelow to build your filter options } Does this help or am I missing something in your setup?

Disclaimer: Correct me if I'm wrong! I don't think what you're trying to do is possible using ProcessWire's datetime fields. The problem is that datetime fields always use MySQLs datetime column type, which represents a fixed date and time, never only a time of day. So even if you're outputting only the time, if the start & end time fields are datetime fields, they're gonna be stored as datetime data. This is why a smaller / greater than selector can't work for a "time of day" scenario, because you can't really compare a timestamp with a time of day. Note that if you want to go one level deeper and go with direct database queries, you can extract the time portion of the datetime field using something like the TIME function and then do the comparison with that. Might be slow though, unless you add an index for the TIME values. Or maybe that can be done with some of the advanced finder module (RockFinder3 maybe?). A ProcessWire native solution would be to add a hidden field that acts sort of like an index for the time, and use that for filtering instead. I've described this approach here. For your use-case, you could use two hidden integer fields for the start and end time. Then use a hook to update them automatically with the start and end time in the form of seconds from midnight. Then use those fields to filter by in your selector.

Not sure what the problem is here, the error tells you exactly what's going on ? You appear to have a namespace statement somewhere inside your template – as per the documentation, namespaces need to be defined at the very start of your script. Either remove the namespace statement or move it to the top and the error will go away. If the namespace statement is at the very top and you're still getting the error, it might have something to do with (a) a problematic file encoding, make sure you're using utf-8 or (b) something going wrong with ProcessWire's template compiler. If correcting the problem does not make the error go away, please post your template so we can check what's going on.

Hm, that's curious. The way it's supposed to work is that the label gets the class InputfieldHeaderHidden, and the span inside the label is then hidden with CSS. In your form the class is generated correctly, but for some reason the corresponding CSS is missing. In my test installation, the CSS code that hides the label comes from /site/modules/FormBuilder/FormBuilder.css, which isn't included on your site. Maybe you're missing one of the core CSS files in your FormBuilder output? If you can't or don't want to include this CSS file, you could just add the required rule manually to any of your stylesheets. This should do the trick: .InputfieldForm .Inputfield:not(.InputfieldStateCollapsed) > .InputfieldHeaderHidden > span { display: none; }

Release 1.0.1 is now live! It fixes the errors on ProcessWire versions below 3.0.139. Background: The module uses Inputfield::skipLabelMarkup to remove the label markup if the inputfield is configured to not display a label. This constant was introduced in ProcessWire 3.0.139. On older versions, the module now falls back to Inputfield::skipLabelHeader, which renders the label but hides it with CSS (instead of skipping the label markup completely). @aComAdi Let me know if the release isn't working for you, or if you have any more problems with the module!

@aComAdi Thanks for letting me know! I'm using a constant there that is only available in ProcessWire 3.0.139 and above. I can certainly fix that! In the meantime, if it's possible for you you can update ProcessWire to the new master version, which should fix the problem as well. But I'll update the module to work with your ProcessWire version as well, hopefully later today ?

@kongondo Aaaah I see, I always use the flyout-menu for fields, never the fields page ^^ The flyout menu only shows system fields in advanced mode, though.

I've never heard of that, where do you set that?

You can change the password requirements through the field settings of the password field, which is just a regular field. The field should be named pass. If I'm not mistaken, it's hidden by default, and is only displayed in the field list in advanced mode. Set $config->advanced = true to activate advanced mode, then you should see a couple of system templates and fields, including the pass field. Go to setup -> fields -> pass, there you can control the required characters as well as modify the complexity requirements.

@rash One possible workaround to this problem is to use a hidden text field that acts sort of like an index to your Selectable Option fields. I've used this approach before to make the selected options searchable (since their titles can't be searched, as you noticed). This would also work for your sorting problem: Create a text field (let's call it direction_index) and add it to the templates where you have your direction field. Use the Pages::saved hook to automatically write the current title (or value) of the direction field to the direction_index field. Now you can use the hidden direction_index field for sorting and searching. Since it's a regular text field, it has it's own database table and has full support for all ProcessWire selectors. Though of course that's probably more work than just migrating the the select field to a page reference ?