LostKobrakai

You don't seem to have noticed the edit to my last post. It's doable with "template" or "template.label".

Sorry missed your point a bit, thought you wanted a more "descriptive" layout instead of only better titleing. backes already showed the part of the pagetable configuration, where you can change which rows should be visible. Just put title in the first line and you'll get the title there. Edit: If you're talking about the title of the type of page use "template" or even "template.label"

Sure you're actually using the PageTableExtended module http://modules.processwire.com/modules/fieldtype-page-table-extended/? That's providing exactly what you're asking for.

Maybe you should search not only the forum http://processwire.com/api/hooks/#read_arguments

I cannot tell you where it comes from, but noSetting is only available in the backend if you enable advanced mode in the config.php. It's not a setting meant to be freely available all the time.

Modules populate their styles and scripts to the $config variable. $config->styles and $config->scripts each hold an filesarray which you can loop over to generate the markup for those files in the head of your website.

How about implementing a custom function for that? $field = wire('modules')->get("InputfieldPasswordGeneric")->setConfigs($array);

I think you didn't add those fields to the user template? If so you can still add variables like above, but these are runtime only and won't be save, as there are no columns in the database for these fields. You can add fields to the user template like you'd do it with every other template. It's just hidden by default so you need to enable "show system templates" on top of the templates-list.

There's also this for showing the pagetreelinks on hover in addition to the always visible ones. They are more present this way and I'd think users will be less tempted to click the title of the page. It's one of my standard admincustomfiles files. .content .PageList .PageListItem:hover .PageListActions { display: inline; -webkit-transition-delay: .25s; transition-delay: .25s; } @Jan Romero You're not the only one. I do this, too, while I doubt my clients are using such bulk editing skills

Did you miss any "<?php" or "?>"? At least that's most of the time the culpit for such an error.

The thing is: Ryan most likely won't rebuild something that's already working really great. I think there are really more important features on the roadmap. This should not hold somebody else of building a wrapper for other databases, I'm just talking about a core implementation.

Please use the code tool of the editor here in the forums, this makes is easier to read. <div> <?php foreach($page->children as $element) : ?> // <-- no semicolon, but a colon here <h3><?=$element->sp_title; ?></h3> <?=$element->sp_content; ?> <?php endforeach; ?> // add the php </div> You're effektivly replacing {} with ":" … "end…;". The semicolon always marks the end of a statement, if it's a single line or a whole loop.

There isn't even support for things like sqlite oder postgree, even though there where requests for it, so I'll doubt others will be adopted in a near future. One has to keep in mind, ProcessWire is developed by Ryan only. He really has to put his work into the meat and by now it really does not make sense for a cms to support an other database than mysql if there isn't the time to support multiple databases.

You'd have to hook into ProcessPageEdit::buildForm. Have a look at this: https://processwire.com/talk/topic/8836-how-to-manage-delete-tab-for-user-groups/?p=85732

It's possible by using a hook in ProcessPageEdit::execute and just redirect to your module if needed.

@diogo That's great for changing content between breakpoints

Firstly $form->get() does only search by field name, while you supplied the id of the button. Also this id will be used for the "save" and "publish" button, so to differentiate use this names: "submit_save" "submit_publish". Secondly the value of the submit field is not necessary for the form submition, otherwise it would not be translateable. Only the name attr has to stay the same.

Before ProcessWire hands of to your templates' code it does not output any markup. So you should be able to change headers anytime before that and even in your templates' files if you're not outputting markup by yourself before that.

I think you can't as there's no fieldtype using it. I think Ryan did it mostly to give module developers the chance to reuse the code. But there's a 3rd party module that does allow for icon selection: https://processwire.com/talk/topic/8960-fieldtypefonticonpicker/

I see now, why it does not work. With all those attr("id+name", …) I didn't had this on the radar. ProcessFormBuilder does only set a id for it's fieldsets, but not a name, which is really great if one wants to get() those fieldsets. Edit: thanks for that tip with the parent. This way I don't need that find().

http://stackoverflow.com/questions/9416508/php-untar-gz-without-exec

Do I really have to ->get() all fieldsets down to where my field is? What boggles me is this: // $form = edit form of ProcessFormBuilder $field = $form->get('form_emailFrom'); // returns the correct select field // try to get the fieldset containing $field $fieldset1 = $form->get('fieldsetEmail'); // returns null $fieldset2 = $form->children[1]->children[3]; // returns the fieldset with the id 'fieldsetEmail' $fieldset1->insertBefore($field, $someotherfield); // this works $form->insertBefore($field, $someotherfield); // this does not work I don't see why the first line would work, while getting the fieldset via it's id returns null, even though the fieldset is indeed in the form. Maybe you can try it with exactly the code I had: https://github.com/LostKobrakai/FormBuilderEmailExtentions/blob/master/FormBuilderEmailExtentions.module#L116

For me it's working after the update to 2.5.20, so maybe the update clear the cause of the issue. Can't say for sure as the installation is not managed by me.

You'll get the same error again if you every want to update ProcessWire. For anything else it should be fine.

As a CMS provider you never know if this is in fact the case. It's always better to restrict stuff like this as it really does not limit the ability to have save passwords, while it limits the potential for error. Inline whitespaces are just two chars that you can't use.