Leaderboard

Hi @da² PW shows no error log for the crash. But I looked into httpd Apache error_log file and get this after site errors out: I work locally on a Mac so it very much might be a bug on platform specific implementation, as I see "SwiftNative" mentioned in the log. Would be interesting to see if other Mac users are experiencing this or it's just a super specific issue on my end ?‍♂️

I've been thinking of adding this for a while. Now configurable in v0.3.10

Hello, Not sure if this is a simple request - it just came up in use, but can we choose in the config whether the 'Add New' menu item appears at the top or bottom of the dropdown? That field list can get kindof lengthy. It would be nice to have it available at the top if I wish.

There's always an error message recorded somewhere, if not in PW logs it's probably in web server logs. If @donatas is using Xampp on Windows, Apache logs are in xampp/apache/logs/error.log. Trying to understand an error without knowing the message is quite challenging. ? EDIT : But he should first look in PW Exception|Error logs.

Thanks! Doing more exploration I narrowed it down further that the issue is caused by using PW translation functions inside your static function: _() and _n(). Removing these it can be used as a static function and doesn't cause the error. But I guess that defeats the whole point to have time strings translated...

FrontendForms update 2.1.55 Bug fixed on min time configuration input field (name attribute was missing) Static function secondsToReadable() will be reverted to non-static. The static function leads to some problems under certain conditions, so the best way was to revert it back to non-static (read the discussion above). IMPORTANT: This has an impact on the FrontendLoginRegister module if you are using 2-factor-authentification, because this module uses the static function. If you are using the FrontendLoginRegister module, please update this module first (or at the same time with FrontendForms) to prevent problems. Thank you!

Hi. Yes, your updated file version seems to be working fine for me, no error. I guess it is safe to update the module with it. Thank you for your time and a useful module!

Upgrading plugins? Contact Form 7 changed IDs in their shortcodes for embedding forms from incrementing integers to hash based strings. From the release notes: orly. You see- upgrading the plugin replaced all of the IDs for the forms. It didn't add hashing, it replaced all of the integer IDs in the database during the plugin update process. Instant borkification. I've dipped my toes in programming once or twice and I can tell you that seems like a pretty big oversight... TO THE GOOGLES! First result was a support thread for this issue on the plugin's website. Hey- marked resolved, day has been saved! But there's no actual solution in the thread. IT WAS A RUSE. So here we are. Just in case anyone using WordPress needing help on Contact Form 7 is still looking for a solution and stumbles on this thread, I'll provide it here on a different CMS' support forums: Go through your entire site and replace all of the existing shortcodes for all of the forms wherever they were added on pages and templates with the new ones. By hand. Couldn't be easier. The mostest popularest user-friendliest CMS strikes again.

Hi Denis, thx. That's already fixed in the latest version on the dev branch ? Sorry for the trouble! I'll merge that soon!

This would also work: <?php if($page->matches("id=1042|1043")) ... ?

Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.

Right, I understand now. You are wanting to give a role (let's call the role "manager") the ability to edit roles/permissions and add new roles/permissions. First thing to know is that in doing this you would be going well off the map of what is documented in ProcessWire and straying into some potentially dangerous territory. Normally only superusers manage roles and permissions, and if you decide to deviate from that you'll want to do your own thorough testing. It sounds risky to me and not something to be done lightly. But I took a look at what's needed to enable this and it seems that the steps are... Manage roles 1. Create new permission "role-admin". 2. Give this permission to the manager role. 3. Open the "role" template at Setup > Templates (you'll need to show system templates in the filter section). On the Access tab allow the manager role to "Edit Pages" and "Add Pages". 4. Open the "admin" template, and on the Access tab allow the manager role to "Add Children". Manage permissions 1. Create new permission "permission-admin". 2. Give this permission to the manager role. 3. Open the "permission" template at Setup > Templates (you'll need to show system templates in the filter section). On the Access tab allow the manager role to "Edit Pages" and "Add Pages". 4. Open the "admin" template, and on the Access tab allow the manager role to "Add Children". You can skip this step if you already did it.

Recently hit the wordpress wall for the first time trying to help out a charity upgrade their WP-based site. Very troublesome.