LostKobrakai

Nope. This is what 90% of the backend is based on. So yeah, you can edit pretty much everything in the backend.

It's just another Inputfield to be used with processwire's form api. Instead of rendering a "real" inputfield you can just set a string (markup) to it, that will then be plainly rendered, without looking at it. What I just noticed: I was wrong above, just using it for opening and closing markup won't work as InputfieldMarkup is also wrapped in the "wrappingMarkup" that every other Inputifield does get, too. Edit: The holy bible for working with the form api: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/

@Soma This functionality was already implemented a year ago, just did take some time to get it into the description.

But only if everything goes well. I've seen this new recaptcha thing multiple times, but only once or twice was it the fancy checkbox. The other times it did fallback to identifying house numbers for google maps (which in itself, while clever, feels kinda exploiting for users).

Have you tried just disabling your hook and changing the two module's fields to show the time, too?

If you're talking about Lister then it's already released. The core module is part of ProcessWire since I think 2.5.3 and the Pro module, which has additional functionality, needs to be bought here in the store.

The custom php code field for page fields is sometimes a little more complex on a current project and I wanted it to sport an better editing interface and syntax highlighting. My module does convert the standart textarea there to an ace textarea. There isn't a field behind this form, where one could simply change the inputfielClass for. So it's useful for all the process module forms.

Even the id won't be necessarily available. If not explicitly set it's not retrieved until the page is added to the database.

Maybe this can be useful to people. It replaces a normal textarea in the backend with an ace instance. class AdminHelper extends WireData implements Module{ const phpFirstLine = "<?php //autmatically added but not saved"; public function init() { // Inputfield Ace Extended for editing page fields $this->addHookAfter('InputfieldPage::getConfigInputfields', $this, 'makePHPFieldACEField'); $this->addHookBefore('ProcessField::executeSave', $this, 'removeLeadingTag'); } public function makePHPFieldACEField($event){ $form = $event->return; $field = $form->get("findPagesCode"); $ace = $this->modules->get("InputfieldAceExtended"); // foreach (get_object_vars($field) as $key => $name) { // $obj->$key = $name; // } $ace->setAttributes($field->getAttributes()); $ace->setArray($field->getArray()); $ace->modes = array("php"); $linecount = substr_count($ace->attr("value"), "\n"); // Preserve collapsed mode and do not add when build for saving if($ace->attr("value") !== "" && !$this->input->post->findPagesCode) $ace->attr("value", self::phpFirstLine."\n\n".$ace->attr("value")); $ace->rows = $linecount ? $linecount : 4; $field->parent->insertAfter($ace, $field); $field->parent->remove($field); $event->return = $form; } public function removeLeadingTag($event){ if($this->input->post->findPagesCode && strpos($this->input->post->findPagesCode, self::phpFirstLine) !== false){ $this->input->post->findPagesCode = trim(str_replace(self::phpFirstLine, "", $this->input->post->findPagesCode)); } } }

I think another good way would be using a PageTable (core module, but uninstalled by default), which would get you a more visual list than a classic pagefield.

I did read that. That's one of two topics why I looked into it and it probably false bahavior. Therefore the github issue.

That's not possible right now, you could only use InputfieldMarkup before and after your inputfield to add wrapping markup around the whole inputfield.

That's quite a specific need, I doubt that you'll find this ready-made. So either just use multiple mapmarker fields or multiple pages, or you'd most likely need to enhance the module by yourself so to store multiple values. If you go the latter route, than have a look at FieldtypeEvent. It shows quite nicely how one can make a fieldtype multivalue from an existing single value.

It's just a ton of work to set it up

@diogo I did at first just take a look at the small comparison table at the top, but man is the author's view of processwire flawed.

It would be nice if PageTables could get some attention in this module. E.g. removing a page from the pagetable will result in an error (line 220).

The one you lamented about, that it would remove tabs everywhere: https://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/?p=95063 To make it more obvious, currently there seems to be no ready-to-use way to remove those tabs only in Fredi. You'd either need to solve this on your own or find someone who would take a look at it for you (extend/update Fredi or hook somewhere in between to remove the tabs).

I just noticed. The page will only be save if the pressed button is named "submit_save" or "submit_publish", so my above code will never save the current page.

The preview video was posted 2 years ago, the handling of tabs has changed since then (besides the obvious mayor version updates), so this most likely would need changes to the module. Or you find a way for an external module (my last post) to remove the tabs only if it's called by fredi and not as normal backend process.

The incompatibilities come from different issues. The PageList ones just cannot show anything besides a pagelist. With Autocomplete I think it's because of the ajax functionality. Both could work with the addition of the "custom php code" returning a single Page, which could then work like the simple parent selection above, but PageArrays bring their difficulties. As for your try: Did you select a template/parent above the "custom php code" section?

Basically it's this. If you need this to only work in Fredi and not in the default backend, then it'll need some modification: https://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/?p=90280

@diogo You were right after all. I just didn't grasp fully what was happening in the code. The difference between $pages->find() and $somePageArray->find() is still quite a pitfall, especially for pagination.

Now it makes sense, didn't grasp the $fonts in the different codeparts. Essentially you're using this: $fontlist = $pages->get("/fonts/")->find("id>1, …"); vs. $fontlist = $pages->get("/fonts/")->find("keywords=mykeywords")->find("id>1, …"); There it's exactly the difference diogo and I did talk about: The first one is classwise Pages > Page > find(), which works for pagination and the second one is Pages > Page > PageArray > find(), which doesn't. You'd need to build it like this: $parents = $pages->get("/fonts/")->find("keywords=mykeywords"); $fontlist = $pages->find("parent={$parents}, id>1, …"); Edit: To explain the difference a little more. Pages::find() and Page::find() are both searching new pages, which will be paginated. PageArray::find does not search for new pages, it just returns a filtered subset of itself, which is not automatically set up for pagination.

That's not like it's supposed to work. It's most likely a bug. If one sets up the field with disabled multilaguage descriptions from the beginning, then it really doesn't use languages. https://github.com/ryancramerdesign/ProcessWire/issues/1161

I've some notes for you: This should basically be a own fieldtype, not only an inputfield. The fieldtype would obviously extend the image fieldtype, but this is not a standart image field anymore, with just some custom "frontend" (a.k.a. inputfield). The configuration part should most likely not be a admin page, but part of the field's configuration. The images in an image field already have dedicated folders and you can simply get their paths like this: foreach($page->images as $img){ echo $img->path; } The button won't know if there's a image field on a page by looking into a crystal ball. You'd need to check that for yourself (check the current page) and only add it, where you want the button to appear. To have the generation be started automatically you'd add this to the fieldtype's sleepValue() function, which is essentially the save-to-db function for each fieldtype. That should be the place to initialize an update of the sprite file.