adrian

Back to @elabx's question - if you want to tackle this, have a read of these two threads: https://processwire.com/talk/topic/4253-modal-pop-up-for-page-editing-problem-with-dynamically-generated-page-tree/ https://processwire.com/talk/topic/2380-fancy-admin-mode/

I never noticed that - thanks for the head's up - I'll see if I can fix it in the next couple of days. @tpr - sorry for hijacking your thread!

The title changes immediately for me - as soon as the modal is closed. The name however doesn't change until the parent page is reloaded. This is actually on my list of things to do, although it's been there for quite some time - maybe I need to make it a higher priority.

This could actually probable be done quite easily using CustomAdminFiles to apply the "pw-modal" class to the edit action button. Sorry, no time for an example, but you could probably steal from PageTable's edit trigger. Otherwise, you could alway use Batch Child Editor - the edit icons trigger a modal for editing:

You can always edit your module in the modules directory - simply open the edit mode and save - it will query Github and update the version number which will then make it available via the Upgrade module instantly.

Awesome - would love to see more of these. Please let us know your experience with it - maybe some day soon there will be enough PW devs in my part of the world to do host one.

Glad that helped, but I think I will defer to one of the multi-language experts for the other part of your question - it's not something I use, so I am not very familiar with it.

Hi @Karl_T I think this screenshot should get you going - the "Name Format for Children" option allows skipping the manual naming of the page:

I can confirm that adding the ProcessWire namespace to a module and trying to run it on PW 2.x results in an error.

Have you tried again recently - that looks like it might simply be an access to Github error. The feed is certainly running right now so I would try again and if you still get the error, please check the URL directly to see if there is a problem at your end: https://api.github.com/repos/ryancramerdesign/Processwire/branches

Ok, here you go: http://modules.processwire.com/authors/mikerockett/ I am pretty sure you just have those two modules, correct? I have deleted the account author except for "mike", just in case it wasn't you.

Beta release is now available via the modules directory: http://modules.processwire.com/modules/admin-restrict-branch/ Contains a few bug fixes, adherence to Add New permissions, and the ability to restrict the name matching to the restricted branch to a master parent to reduce potential for incorrect matches and also improve matching selector efficiency. Despite it being released, please still carefully check that your affected users have the permissions and access that you expect and let me know if you have any problems!

There is really only the roadmap: https://processwire.com/about/roadmap/ I have asked Ryan for this functionality outside of the forum and his response was positive, but you won't see it mentioned anywhere official.

Hey Mike - looks like you have a lot of aliases in the modules directory. Are all these you? What do you want them all merged to?

I do believe this is on the todo list for repeaters, along with the ability to name each one (which is pretty important if they are initially collapsed).

Why don't you try adding them to children like: $children->add($this->pages->get(1088));

You can use insertBefore, eg: $newField = $fields->get("your_new_field"); $t = $templates->get("your_template_name"); $existingField = $t->fields->get("sitemap_ignore_END"); $fg = $t->fieldgroup; $fg->insertBefore($newField, $existingField); $fg->save();

Any module that is a textformatter needs to be applied to each of the required fields via the Text Formatters dropdown on the Details tab of the field's config.

Sorry, I am on a bit of a roll - I really do love this module I don't really understand the "Select the inputfields where the extra fields should be attached." option in the config settings. It lists all the different inputfield types, but the module only works with image field types. I actually tried to see if it works with InputfieldFile, but it didn't even work there. Am I missing something about this setting? I think a more useful setting would be to control which image fields (the actual fields, not field types) that imageextra is attached to. At the moment the "Image Extra Fields" fieldset is added to the Input tab of all image fields, which I expect most developers don't need - they probably only want them for certain image fields. Does that make sense and sound like a good idea? Thanks again

I don't know what to say about the issue with removing extra fields - I am continuing to get that error on different PW installs. But now I have another issue for you. With ImageExtra installed and Maximum Files Allowed set to "1" when I go to upload a second image, the editor actually shows both images. After save, the first one disappears, but without ImageExtra, the second one instantly overwrites the first one. This has been confusing for our users - they think a second image has been uploaded rather than overwriting the first one. I hope you can reproduce at your end. I wonder if it's a simple matter of incorporating some of the new code in: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/modules/Inputfield/InputfieldFile/InputfieldFile.module#L438 into your module at: https://github.com/justonestep/processwire-imageextra/blob/master/ImageExtra.module#L540 Thanks!

You can filter like this: foreach($page->fields->find("type=FieldtypeImage") as $f){ or you can create a new field array with: $myFields = new FieldsArray(); foreach(xxxx as $f){ $myFields->add($f); }

Just to add to this thread - I needed the check to run during init() and the best option I could think of was: if( wire("process") != 'ProcessPageView' ) { //in the admin } Can anyone think of any situation where this would fail? Perhaps some modules may run ProcessPageView in the admin? Maybe Nico's check for the admin path in the URL is a better option. Anyone have any more recent thoughts on this?

The latest version of PW has built-in hide/unhide and pub/unpub action buttons, so I don't actually think there is a need for this module anymore.

It's working fine here - are you saying it never returns any results from image descriptions, or are there inconsistent results returned?