Leaderboard

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

I did find this topic: @Robin S provided a hook for site/ready.php $wire->addHookBefore('InputfieldFile::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->noShortName = true; });

Thanks @bernhard, I'm digging into module creation as we speak. I've been lurking the forums here for a minute and soaking up all the useful tidbits I can to be sure. As far as front end flexibility goes, the way it works now is all the content sections are templated and language translatable ( template can be switched in admin ). Most sections are set up as blocks to be placed wherever you need. Of course there will be quite a few changes which will be made to bring it into line with PW and hopefully be attractive to most audiences. Thanks for the offer to help, if I decide to go the open route I will surely give you a shout ?

I'm far from an expert on all this npm, node, grunt things (actually I use none of them, just a php less parser to compile less to css on the fly) but I don't get why you want to do all the compiling on both machines? Why not do all the compiling just on your local dev machine and then git push/pull the static files to your live server? Only problem with that workflow is that db changes are not synched automatically but usually you don't have a lot and if you have, they are quite easy to solve. You have at least three options: Move a DB backup from your local dev to remote live and restore it there. You can do this only, of course, if there where no changes/updates on the live system during your development. Use PW's import/export tools. You have pages import/export and template/fields import/export. For small updates those tools work well and fast. Use code to do that automatically, eg via the migrations module or wireshell.

I normally develop in a remote server and connect with my text editor through SSH. (using emacs, ironically haha) Normally on the dev server, I install the things needed to compile frontend stuff (if needed) and just run the tasks either on a background process or run them everytime I'm developing in a terminal window. If I need sync with live, I use git and manually push (have yet to look into fancy hooks integration) On this thread you can take a look at some comments that talk about a very nice VSCode extension that mounts remote file systems through SSH:

Working fine here: $wire->addHookBefore('InputfieldImage::render', function(HookEvent $event) { /* @var InputfieldImage $inputfield */ $inputfield = $event->object; if($inputfield->hasField == 'image') { $inputfield->setMaxFilesize('2m'); // Set the max file size in bytes or use string like "30m", "2g" "500k" } }); But if you have client-side resizing enabled for the field that will likely interfere with the checking of the filesize before upload.

I figured why is this happening. Now waiting for a response on how to proceed. For more info check the GitHub issue.

I'm really in love with FormBuilder, but the one thing missing to match all my end users' expectations were repeatable field groups. Think repeaters, in ProcessWire terms. Our primary application of PW is our corporate intranet, so "lines" of fields are quite common in the forms I build. We have all kinds of request forms where the information for a varying number of colleagues needs to be entered (from meal order to flight booking request) and where it is simply impractical to send a form for each, and I don't want to clutter my forms with multiple instances of fields that may only get used ten percent of the time. That's why I started to build FormBuilderMultiplier (link to GitHub). What it does: Adds an option to make a regular Fieldgroup repeatable Lets you limit the number of instances of a Fieldgroup on the form Adds an "Add row" button the form that adds another instance of the Fieldgroup's fields Adds a counter suffix at the end of every affected field's label Stores the entered values just like regular fields Makes the entered values available in preview and email notifications Supports most text based fields, textareas and selects (really, I haven't had enough time to test all the available choices yet) What it doesn't do (yet): Support saving to ProcessWire pages (i.e. real Repeaters) I haven't tested all the validation stuff, Date/Time inputs etc. yet, but since I'm utterly swamped with other stuff at work, I didn't want to wait until I have it polished. Any feedback is welcome. There might also be some issues with different output frameworks that I haven't encountered yet. The forms I work with mostly use UIKit. Status: Still alpha, so test well before using it in the field. Known issues: When rows are added, the form's iframe needs to be resized, which isn't completely clean yet. How it works: The Fieldgroup settings are added through regular hooks, as is the logic that adds the necessary field copies for processing the form and displaying previews. "Multiplied" field instances are suffixed with _NUM, where NUM is an incremental integer starting from 1. So if you have add two fields named "surname" and "givenname" to a fieldgroup and check the "multiply" checkbox, the form will initially have "surname_1" and "givenname_1" field (I'm still considering changing that to make the risk to shoot oneself into the foot by having a regular "surname_1" field somewhere else in the form less likely). When a "row" is added, the first row is cloned through JS and the counter in the fields' IDs, names and "for" attributes as well as the counter in the label are incremented before appending the copies to the Fieldset container in the form. To keep backend and frontend in sync, a hidden field named [name of the fieldset]__multiplier_rows is added to the form. Both the backend and the frontend script use this to store and retrieve the number of "rows". ToDo: Naturally, add the option to store the data in real repeaters when saving to pages. Do a lot of testing (and likely fixing). Make a few things (like the "Add row" button label etc.) configurable in field(set) context. Add a smooth API to retrieve the multiplied values as WireArrays. The mandatory moving screenshot:

Yeah, it's not clear exactly which languages are supported but the example in the docs... ...makes me think there is some non-English language support. Good solution. Thanks for adding this feature.

@Robin S - I went ahead and added the pluralize.js library. I have also added a check so that if the parent and child templates are the same, then the child template name is removed so that the form won't submit and you need to manually set them. A simple example to test this is using "Sheep" for the Field Label. In this situation I would just manually name the parent template to "sheeps" and be happy with that, but I didn't want to assume anything, hence the approach I took. Let me know what you think.

You can get all fields of a page, that are editable by the current user, like this: $p = wire("pages")->get(5994); foreach ($p->getFields() as $pField) { foreach($p->getInputfields($pField->name) as $inputfield) { if(!$p->editable($inputfield->name, false)) { continue; }; // need tracy debugger for bd bd("is editable: {$pField->name}"); } } https://github.com/processwire/processwire/blob/96f62b313fca3f48df0521096145b782fa08c0e3/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L815 https://github.com/processwire/processwire/blob/96f62b313fca3f48df0521096145b782fa08c0e3/wire/modules/PagePermissions.module#L118

A couple of small updates to the Adminer panel / process module. 1) It is now restricted to the database for the PW install. Previously you could access all databases available with to the PW DB user. If some of you out there don't like this change, let me know and I can make it optional, but I think it's a better default (cleaner and a little safer). 2) It's now possible to uninstall the Adminer process module and it won't be automatically re-installed each time you upgrade Tracy - @Rudy was concerned about this with his setups. Obviously if a user has superuser access they can still install if they want, so it's more a case of removing something tempting for users without sufficient skills, rather than being a true change to security. On this note - Adminer is restricted to superusers (same with the Console, Snippet Runner and File Editor panels).

Recently Bitrix (a popular commercial CMS here in Russia, known worldwide for its Bitrix24 CRM/PM/... solution) introduced similar functionality they called Site Constructor. This thing allows to build pages or parts of the pages from pre-defined blocks which can be static or dynamic. Site developer can style, modify or add their own blocks. They recommend this for landing pages for now, but are aiming to move all content management to those blocks. So there is some trend. I actually do use (almost) the same approach in PW. Most of my pages have content-page template with content_blocks Repeater Matrix field holding most of the content in repeater items. What is missing in my solution is: the easy ability to restrict the order, allowed types of those items (though possible with this module); the ability to easily move/duplicate content blocks from project to project (still think Repeater Matrix should be PageTable Matrix); the ability to easily preview the page built (like with this solution) in admin / edit it inline on the frontend. I see this way of building content very flexible, but still somehow unfinished. We have all the parts in PW to build a full-blown page bulder that will not allow too much for ones that do not need it, but will make it easy to build something really complex and interesting without programming. But those parts are not yet combined in a polished solution. I would certainly like to have it in PW (as a PageTable-like PageBuilder FieldType/Inputfield combo, probably).

Hi Robin, I don't actually ever use the "_items" suffix myself - I always go with "cars" and "car" for the parent and child templates, respectively. That approach was to make things as logical as possible without the user having to change these settings. I am definitely keen to take a different approach though and the pluralize library seems like a good option. I see that it contains lots of rules for non-standard "s" suffixes, although it doesn't look like there any non-English ones provided. The other concern I have is the "Singular words with no plurals" list (https://github.com/blakeembrey/pluralize/blob/298eb67f19369dd30207c0817eda4f0045c6c1a7/pluralize.js#L393) - won't these result in the parent and child templates having the same name? Do we just need a check to make sure they're not the same and if so empty the child temptate name field and prevent the form from submitting until it is completed? Any thoughts?

I've a prove of concept S3 filesystem module based on flysystem and the core inputfield file running in a project of mine. I'm not comfortable to put it out in the public, but there are ways to make it work. Personally I'd try to avoid mounting remote filesystems, as there's more networking involved: client <-> server <-> S3. I'd rather work with direct s3 urls for the frontend.

Hi @breezer, I'd love to see a forum-solution for PW, but to be honest I'd only want to pay for it if it was exactly what I need or extremely flexible. Both is very unlikely. If you want to get familiar with module development in PW this would be a great opportunity to start with. Easy and I'm quite sure it would be helpful for many of us: A favicon generator helper module: You might also want to talk to @autofahrn (forum bug again... *sucks) from this post: If you choose to develop your module open source I'd be happy to assist wherever I can to make it great ? PS: A huge challenge will be all the Frontend Markup Generation of your forum. As every site can be different in PW this makes such modules a pain to develop. I'm working on a Frontend-Theming-Module right now, that might make this a lot easier...

Thanks for the welcome, I think I will give it a shot and move forward with the rewrite. Since I have so much time invested already it would be a shame to abandon my project. That being said it will take at least a few months or more due to the way I had to work around the previous cms but I feel sure that once I'm more familiar with PW a really nice forum module will emerge. Wish me luck lol and I'll post updates here sporadically ?

AOS also has this tweak: https://github.com/rolandtoth/AdminOnSteroids/wiki/FileFieldTweaks

I think you could just create a new page under /youradmin that has the admin template and the process "ProcessUser" assigned. Then you can hook into executeEdit to always set the userid to the currently logged in user: $wire->addHookBefore('ProcessUser::executeEdit', function($event) { $this->wire->input->get->id = $this->wire->user->id; }); I'm once more impressed by the flexibility of PW ? My user has id 41 of course, and not 123456789.

Happy to assist. I think it would be a good idea to give very clear and easy instructions of how to help. Something like a little tutorial that guides us step by step through the process from finding an un-translated word to creating the PR. Thanks for taking this project over! ?

Here's a little Tutorial of how to get pages and their parent's titles requested by @mel47 The page structure: The initial basic Finder: The easy and inefficient way: This will load all pages in memory and be slow when you have lots of pages! The a little more complicated but far more efficient way. First, we prepare the finder to join: Then we join that finder to the initial finder: Then just hide those two unnecessary columns in your final grid: document.addEventListener('RockGridItemBeforeInit', function(e) { if(e.target.id != 'RockGridItem_yourgrid') return; var grid = RockGrid.getGrid(e.target.id); var colDefs = grid.gridOptions.columnDefs; var col; // all your grid's frontend settings grid.getColDef('parent_id').hide = true; grid.getColDef('cat_id').hide = true; });

Nice one. I have another enhancement in mind but perhaps you wouldn't agree with the premise. The default Child Template Suffix is "Items" so I guess you like to name the child templates with the plural, but to me the parent template should be plural and the child template should be singular. And ideally the singular wouldn't be created by appending the word "item" but would be a bit smarter. So if the noun is "car" then the parent template is "Cars" and the child template is "Car". And as a trickier example, if the noun is "bacterium" then the parent template is "Bacteria" and the child template is "Bacterium". An an experiment I added pluralize.js to the module and it's working great, with ProcessPageFieldSelectCreator.js consisting of: $(window).load(function() { $('#Inputfield_fieldLabel').bind('keyup change', function() { var field_label = $('#Inputfield_fieldLabel').val(); var plural = pluralize(field_label); var singular = pluralize(field_label, 1); $('#Inputfield_parentTemplate').val(plural); $('#Inputfield_childTemplate').val(singular); $('#Inputfield_parentPageTitle').val(plural); }); }); Of course the user would want to double-check that the plural/singular forms are what they want, but this addition could save time if you are creating a lot of select fields (which is something I needed to do recently). The pluralize library looks like it handles non-English languages too but I couldn't find documentation on that and I'm not competent to test that myself. What do you think?

You should learn emacs! ? I'm afraid I don't have any tips for you, but here's two forum threads asking basically the same question:

I would try upgrading to the latest dev version. Ryan mentioned something in his most recent weekly update: I don't know if this will also be the case for image-fields though; didn't have time to test it out myself...

I am proud to anounce, that I am the new maintainer of the github repo now. I will add my translations for the dev version very soon. Thanks to @yellowled for handing it over to me.

@yellowled Hey, thanks for the quick reply. Yeah, I would like to take over. My username on github is jmartsch. You can transfer the ownership to me and I try to do my best to update the language pack (with a little help of the community).

Nearly ten months later, FormBuilder is happily at work here and I am testing a home-brewed module that implements repeating fieldsets for FB forms [TM]. I have named it FormBuilderMultiplier and put it on GitHub in case anybody is interested.

I usually use english names for the templates and fields (german websites). I think everybody understands that ?

From a core development perspective I'm going to agree with this – but while the core probably shouldn't include a pre-built, "full featured" page builder (at least for the time being, since no one really knows what the future holds), there's no reason why third parties should be discouraged to create such tools. I also know for a fact that there'd be a market for that ?

Generally: hidden prevents pages from being listed in menus, foreach loops and searches, but if you now the path to the page, you will be able to call it, even when being guest (meaning: not having permission to see unpublished pages). Unpublished means hidden in lists (like mentioned above) AND, for users that do not have the permission to see unpublished pages, inaccessible even via its path/URL. I assume you have that page reference construct built in the backend. There, unless actively changed, you are superuser. "Hidden" pages will appear in such a reference field, "unpublished" ones won't.