Leaderboard

Hi all, For some reason, I'm unable to add this language pack to https://processwire.com/modules/category/language-pack/ as described in So, I'm sharing the GitHub repo here: https://github.com/dlzi/processwire-language-pt-br, where you can download it directly.

I was dealing with this very recently. Below is a link to another thread regarding this. I also made an additional change to the JS file mentioned below, but I don't have access to this code today. Can post tomorrow. This seems like it started happening after US daylight savings last hit...

Hey, @kuba2! The issue is not PW itself, but rather a 3rd party module - MarkupSEO. It has not been updated for awhile (8 years))) You should: Solve the issues in this module yourself (the author is not around anymore AFAIK). Use a more modern SEO module like this one. Remove all the SEO modules and cope with SEO needs with regular fields and creativity. Anyway, you need to be able to change PHP versions back and forth and see what other modules might need an update.

Process Render File A Process module that renders markup from files in /site/templates/ProcessRenderFile/. This provides an easy way to create simple admin screens where it might be overkill to create a dedicated Process module for the purpose. Process page When you install the module a page with the name "render-file" and the title "Render File" is created under Setup. To change the page name or title, expand Page List to Admin > Setup > Render File and open the page for editing. Tip: if you create a new text field with the name "page_icon" and add it to the core "admin" template you can set a custom menu icon for the page by entering the icon name into the field. E.g. enter "smile-o" to use a smiley icon for the page. If you want to use ProcessRenderFile for more than one Process page you can create a new page under Setup. Select "admin" for the template, enter a title for the page, and in the next step choose ProcessRenderFile in the Process dropdown. Render files for URL segments On install the module will create a "ProcessRenderFile" folder in /site/templates/. Any .php files you save to this folder will be rendered as the output of a matching URL segment for Process pages using ProcessRenderFile. For example, if you create a file foo.php containing code... echo "This is the output of foo.php"; ...then you'll see this output when you visit /processwire/setup/render-file/foo/ (assuming the default ProcessWire admin page name and the default ProcessRenderFile page name). In the render file you can use all the ProcessWire API variables like $pages, $input, etc, as you would in a template file. If you create foo.js and foo.css (or foo.scss if you have ProCache installed) then those assets will be automatically loaded when you visit /processwire/setup/render-file/foo/. When a file is rendered the filename will be converted into a capitalised format that's used as a browser title and a headline. If you want to set a custom browser title and/or headline you can do this in your render file: $this->wire('processBrowserTitle', 'Custom browser title'); $this->wire('processHeadline', 'Custom headline'); Render file for the Process page If you create a render file that has the same name as the ProcessRenderFile Process page then this file will be rendered when the Process page is viewed without any URL segment. So for the default ProcessRenderFile page name you would create render-file.php. Note that this will override the default list output described below. Configuration The module configuration screen lets you select URL segment render files to appear as menu items. The selected render files will appear in the flyout menu for the Process page, and also as a list when the Process page is viewed without any URL segment. The list is only shown if you haven't created a render file for the Process page as described above. If you've created more than one ProcessRenderFile Process page then you'll see menu options for each page in the module configuration. https://github.com/Toutouwai/ProcessRenderFile https://processwire.com/modules/process-render-file/

@Juergen you are awesome. Great final addition to this module.

Version 2.2.14 is out! This new version comes with a new CAPTCHA type: a slider captcha. Now FrontendForms supports 7(!) different CAPTCHA types and I guess this will be the last one. There is a fabulous module in the module directory which also creates a slider captcha that can be used with other forms: Slide Captcha. But the slider Captcha in FrontendForms is an extra coded and integrated captcha, that has nothing to do with this module. To be clear: The slider captcha inside FrontendForms is similiar to the Slide Captcha module, but it has nothing to do with it. So there is no need to install the other module. The only thing you have to do is to enable the slider captcha in the module configuration - that is all. You have 1 additional configuration field where you can select the accuracy of the puzzle piece to the goal. 5 means that the distance of the puzzle pieces to the target must be less than or equal to 5px in order to solve the captcha correctly. Here you can see the new slider captcha in action: As always, please report any bugs on Github!

Hi @Atlasfreeman I'm sorry but I don't understand what you are trying to say. What is file.php? What is index_filter.php? These things might be obvious for you but they are not for me/us. Every PW project is different, so you have to explain your setup in more detail. I don't understand what you mean by "catches all the page references". The RockPageBuilder field is a PW field like any other field. You output it like any other field in PW, see https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/blocks/#rendering-blocks If you don't want to output any blocks on any page, don't add the field to the template and don't add the render call in the template file. ---- Maybe anybody else understands your questions better.

Hi @SIERRA, have you tried to declare the namespace at the beginning of your file? <?php namespace ProcessWire; echo __("Test"); I think it should work by adding the namespace. I manually add the namespace on every file, although ProcessWire has a file compiler which should do this automatically. Regards, Andreas

Not so sure about that. But the GH repo on the extension page links to tailwndlabs. EDIT: Actually I would not trust that extension since they are clearly not linking to their own GH repo and therefore pretending to come from tailwindlabs.

Then I'm not a real programmer :-) For me the extension is still working on Cursor Version: 0.40.1 VSCode Version: 1.91.1 Commit: 58b91712431381a1b75817cd3437cee35dddcb30 Date: 2024-08-24T02:52:24.035Z Electron: 29.4.0 ElectronBuildId: undefined Chromium: 122.0.6261.156 Node.js: 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 6.10.6-zen1-1-zen But that is on Linux. I tried it on a project that I setup with your TW/UIKit profile, so there is LESS involved. Since this extension comes from tailwindlabs, the creators of Tailwind, I would go with it.

@Stefanowitsch if you hook into Pages::saveReady then you modify the $page object right before the save happens. For example you can just set $page->title = 'foo' there without saving, because PW saves the page object right after you modified it. If you hook into Pages::saved the save has already happened. In that case you need another $page->save() after you modified anything. Sometimes it's better (or necessary) to use Pages::saved, sometimes you can just use Pages::saveReady to be a little more efficient.

Great! This has been annoying me over the last few days as well (and on any previous project), but it was not annoying enough to have the idea of supporting custom stubs per project so your input was highly appreciated ? If any of you guys have any other suggestions how to further improve the day to day development experience when using RockPageBuilder please let me know!

@Stefanowitsch many thanks for sharing your solution, really helped me out. I modified it a little when implementing. Does the same job but may be a little more optimized. <?php $wire->addHookBefore('Pages::saveReady', function($event) { // ...rest of code here $page->block_search_cache = $index; // By hooking before the saveReady event it's possible to set the search cache field value without calling an extra page save // $page->save(['noHooks' => true]); }); Worked for me and just thought to share. Thanks again!

A few usability tweaks and tips for the CKEditor "Styles" dropdown, which is by default not that user-friendly: As you can see it's small and if you add custom items to it they may look awkward as they may inherit styles from their targets (a 3rem bottom margin in the screenshot above). These are relatively easy to fix but you have to load your custom CSS files to two places (eg. with AdminOnSteroids): PW admin and CKEditor. After loading the CSS/Js assets (see code below) the dropdown looks nicer and more usable: The screencap contains other features that you can achieve with the snippets below. Code CSS - CKEditor (contains demo styles too) CSS - admin JavaScript - CKEditor custom styles P.s. in case you wonder whether the half-margin, no-margin stuff and font-sizes from 12px to 48px were real-life examples - yes, client request ?

Version 2.2.13 comes with an upgrade for the FrontendFormsManager module. The FrontendFormsManager module shipped with FrontendForms was added a few versions ago. The usage of this module is optional. This module now also supports the management of suspicious IP addresses. These are IPs that have been temporarily banned due to many unsuccessful form submission attempts (logging must be enabled in this case). A new section for managing these IP has been added. As you can see, a table of statistical data and a chart have been added to the FrontendFormsManager. When you click on the "Go to all temporarily blocked IPs" button, you will be redirected to a new page that contains all the temporarily banned IPs. The data is taken from a log file. Below you will see a screenshot of this page. Inside this table you have a button to view more details about this IP and a button to add/remove this IP to/from the blacklist. If you click the "View details about this IP" button a panel will be opened with more information about the IP and the number of blockings. With this information, you can now decide whether you want to block this IP permanently by adding it to the blacklist or not. Happy testing!

Look here for a detailed instruction.

I have used ProcessWireUpgrade for years over a decade without any issues. I do have to admit that I can work at least annually on most of the sites I run. Only once did I have any problems with it, when UIKit became part of the core and I had to update a website that I built in 2012. That's over a decade ago! That was the only instance where I had to upgrade PW manually, for which I followed this process which wasn't all too difficult. Basically came down to renaming some files so I could revert back in case I'd screw up. Aside from that it basically came down to uploading a new wire folder and refreshing the backend. Quite simple.

I also experienced this issue. Following on netcarver's advice above, it turns out that my device clock is ahead by over 5 minutes. I adjusted my device time & it worked but thought a broader solution might be better. This fixed my issue. var startTime = parseInt($('#login_start').val()); // GMT/UTC // var maxSeconds = 300; // max age for login form before refreshing it (300=5min) var clientStartTime = Math.floor(new Date().getTime() / 1000); var clockDifference = clientStartTime - startTime; var maxSeconds = 300 + clockDifference; But I prefer it be done in the core, so I opened an issue in github.

It should not be difficult to add a language pack to https://processwire.com/modules/category/language-pack/, but it seems I'm missing something here.