Leaderboard

Work continues on the new processwire.com website. I’ve nearly finished developing most of the modules directory this week and next week will be working on the development side of the API reference and sites directory. Some more good news to share is that when the new site launches, the new admin look and feel will launch as well. The website and admin share a similar design language in some areas, and I’m confident you will love them both. When we use screenshots of ProcessWire in the new site design, they will be from the new admin look and feel. It is still admin AdminThemeUikit, but with a new face that is beautiful, modern and professionally designed. I’ve been using for more than a week and it’s fantastic in my opinion. If for some reason you end up wanting to keep the current look of AdminThemeUikit (perhaps a client doesn’t like change), it will remain as an option too. If you are extending AdminThemeUikit or using the admin.less feature (developed by Bernhard) to custom style the admin, all of that will continue working too. What will likely be changing is that we’ll be moving the older AdminThemeDefault and AdminThemeReno out of the core and into the modules directory. I’d rather keep the core efforts focused with AdminThemeUikit, but continue to support the older admin themes as installable options. Prior to this, most of what you’d seen in ProcessWire’s core admin and website has been designed by me (excluding AdminThemeReno). And I haven’t worked full time as a designer since 2005 or so. If I ever had any site design skills, they are long gone. So PW has always had a “designed by a developer” look. Having professional designers take over the design of both the admin and the website just feels like a major upgrade to ProcessWire all around. More than I could have guessed. I look forward to when I can share the new site design, admin look and feel, and the designers with you. Thanks for reading and have a great weekend!

Hey Ryan! First of all, this all sounds very promising. In my humble opinion you are vastly underplaying your own skill in terms of design, but that's also why we can trust that you'll recognize amazing design once you see it. Looking forward to seeing what the team working on the design has cooked up 😉 Now, please forgive me for jumping directly into asking for stuff, but... I know this is small thing, but it would be quite nice if the new admin made use of CSS variables wherever it makes sense; colors, font sizing, etc. (Or provided them as an alternative for non-core tools to use, in case it is not feasible to use them for actual admin styling.) The reason I'm saying this is that I've built various admin tools that I wanted to look like the admin theme, and since there is (to my knowledge) currently no simple way to access existing colors etc. in CSS, any non-Uikit elements I've had to "hard-code" to use current styles. This includes the default green/cyan/blue color theme, current spacing and font size practices, etc. As a result said custom elements may look out of place once the theme is updated 🙂 (Just for the record: SCSS/LESS might be an option, but that feels like a lot of unnecessary overhead and complexity where vanilla CSS would easily suffice. I'd really like to avoid that if possible, and to me it seems like CSS variables are an easy and well supported alternative.) Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

I've done something like this once, neatly grouped in chapters, with screenshots and even short video-captures. Everything the client needed was covered. Problem was... that particular client mostly forgot to look it up in the first place - even though that manual wasn't hidden away in some obscure place, or distributed as a separate file. It lived right there in the PW admin as a custom admin page. I'd share it here, but a) it was in german, b) the site's setup is way too custom-tailored to make sense for most other people and c) it uses pro modules like Form Builder and Lister Pro. Also, afair the screenshots contain sensitive information, and the rich-text editor in use was CKE with a non-standard choice of buttons. I'm not sure I would ever do such a manual again, seeing how much work went into it, and how easily it can be overlooked. I would invest my time even more into UX; e.g. for some sites, it makes sense to completely hide the page-tree. Also, use field labels and hint texts liberally. Hide, rename or otherwise simplify admin stuff (hooks? Admin On Steroids - or whatever the successor is called now? there's plenty of tools and examples around). Some stuff is right there in the core, e.g. restrict templates by page-tree, or disable changing the template etc.

@bernhard Apologies for the delay! I've pushed updates to the dev branch. I had a few changes that were already going into the next version that I had to do some extra testing for and a lot of housekeeping. Let me know if this works as well for you as it did me and I'll push another version to main https://github.com/SkyLundy/Fluency/tree/development New feature that some may be interested in- adding DeepL languages for translation that are technically supported by their API but not delivered by the languages endpoint yet. You can read more about when that happens and why on this DeepL documentation page. To manually define languages in Fluency that are supported for translation, you can use a hook. This will make the language available both within the global translation tool as well as available for configuration with a ProcessWire language on the module config page. <?php namespace ProcessWire; // ready.php use Fluency\DataTransferObjects\{EngineLanguageData, EngineTranslatableLanguagesData}; // Hook after Fluency gets the available languages from the DeepL API wire()->addHookAfter('Fluency::getTranslatableLanguages', function (HookEvent $e) { // $e->return is an instance of EngineTranslatableLanguageData // The `languages` property returns an array of EngineLanguageData objects $languages = $e->return->languages; // Create a new data object, define the values according to the API docs, add it to the original languages array $languages[] = EngineLanguageData::fromArray([ 'sourceName' => __('Arabic'), 'sourceCode' => 'AR', 'targetName' => __('Arabic'), 'targetCode' => 'AR', 'meta' => [ 'supports_formality' => false, // This is determined by DeepL, check to see if it's available in their API docs ], ]); // Instantiate a new EngineTranslatableLanguageData object with the language array then assign it to the return value $e->return = EngineTranslatableLanguagesData::fromArray([ 'languages' => $languages ]); }); @Hari KT This is a new method supported by Fluency to add Arabic to Fluency before DeepL lists it for translation. Thank you for inspiring a solution with your Github issue on languages not being available in Fluency. This is available on the dev branch of the Fluency repo if you would like to help test it out @ryangorley This will address the issue you had with Traditional Chinese, albeit a lot later than may be useful for you, but the hook above can be modified to resolve that problem. I'm surprised how long the language had been listed as "available soon" on their API documentation 🤷‍♂️ I would have gone this route sooner had I known there was some documentation about this, I don't think it existed at the time.

Hello! I trashed a page and when I checked the Trash to restore it I noticed that there is no "restore" button on it. Not even a "view" button. There is only "edit" and "move". If I set the page to "Unpublished" while on trash only then the "view" button appears but still there is no "restore" button at all. The page belongs to a template that is used for children. I'm using a brand new ProcessWire installation 3.0.244. Also, upgraded it to 3.0.245 and the issue remains. I do not have that issue on a website with 3.0.229. EDIT: While I'm using 3.0.245 now, I created a new children page and then trashed it and the "restore" / "view" buttons are now visible.

I ended up modifying the module (FieldtypeSecureFile) of Wanze to my needs. Wanze's module doesn't delete the files nor the sub-directories where the files are in. Also, the module didn't work in the latest version of PW. Now it does, but I don't know about the old versions (and I don't care). I left out the download part and the roles, because I don't need that. I'm sure there are some things that could be approved in the code, but it works for me. I can now safely upload and delete files in a directory outside the webroot. Example: /home/username/securedir The link to the module: FieldtypeSecureFile (GitHub)

Hi Teppo, Would it be possible to make the 'isRepeatableField' in Indexer.php method hookable. I would like to attach our FieldType 'FieldtypePageTableNext'. That would be great. ?