Soma

NO he's amazed like the women on that Stockphoto

In my opinion it doesnt matter. It was just an alternative and don't think it add more overhead than loading the field from db or adding it via hook.

I'm not sure why at all. it shouldn't work. But then I only see partial code. Well, then you haven't read the HelloWorld.module yet!?. The documentation along with examples is right where you start learning it.

What I just thought about is: What if you add the property to the Inputfield using a hook. And it works you can do $this->addHookProperty("InputfieldText::overwrite", $this, "addProperty"); Then public function addProperty(HookEvent $event) { $event->return = 0; } Then this works $this->addHookAfter("InputfieldText::getConfigInputfields", $this, "hookConfig"); public function hookConfig(HookEvent $event){ $fields = $event->return; $field = $event->object; $modules = wire("modules"); $f = $modules->InputfieldCheckbox; $f->attr("name", "overwrite"); $f->attr("checked", $field->overwrite ? "checked" : ""); $fields->add($f); }

Ah sorry, I read that too quick (on mobile). Now at the laptop, I see that you're getting the config value from the field. I did that here too https://gist.github.com/somatonic/4252958 Since the property isn't set in construct, it's not automatically set to the field from the config data.

$event->object refers to the module / class you hook into. @Adrian config fields are not fields. Only Inputfields for a module config.

What if you add this to your config.php? $config->sessionFingerprint = false;

There's another method to be able to overwrite created user directly when creating a page. There's a new template setting to allow overwriting the $page->createdUser that you can enable to allow this via API. Then you can do this: $p = new Page(); $p->template = "basic-page"; $p->set("createdUser", wire("users")->get("importer")); $p->title = "Imported page"; $p->save();

Everybody who has import scripts running as a cronjob, there's this effect that the cronjob is run als guest user. So imported pages via API are created and modified by "guest". This is not nice and can lead to confusion. "What?! How can a guest create this page?" To avoid this and set the current user via API you can do this at the beginning after bootstrapping PW: include_once("./index.php"); /** * Overwrite static user for imports. All created pages will now * have created and modified user set to "importer" PW user. * Otherwise API created pages will have the created user "guest" * ------------------------------------------------------------------------------------- */ $importerUser = wire("users")->get("importer"); if($importerUser->id) wire()->setFuel("user", $importerUser, $lock = true); Only thing is you have to create a new superuser with the name you wish to use for such scripts and replace the name in the script. Now if you run this script no matter from where or with what current user you'll have "importer" as the created and modified user. ----- Note: There's a new way to set system vars like $user via wire(name, value), but this doesn't seem to work in this case in my tests. Cause the user will get overwritten again when creating a page by the current user calling the script. I'm not sure it's a bug or what, so it might be possible in future to use the shorter version of wire()->setFuel(name, value).

Repeaters are pages themself. So it would'nt be on same page technically. Since repeaters aren't supported anymore to go any further by Ryan (strangely it's the most used field type it seems fir a reason) cause it causes technical problems. And it showed. Your best bet would be to use subpages or pagetable instead. PagetabLe and ImagesSelect. And use ImagesManager to create image DB you can select images from. Not all as in a perfect world but there's lots of benefits from going this route. I built ImagesManager to show how it can be done and I'm a little sad some other smart people didn't join in to make it big and improve its implementation. Btw I'm using this combination on a big news portal www.1815.ch with lots of editors and while it may take an extra step they're pretty happy and love PW now. There wasn't even a obvious reason to use referenced images and we may even convert it back to on page core image field, but it proved to be pretty stable and flexible while still open to change it quickly. Image and files in general are a though one especially cause PW is so different. Only time will tell what will happen. My concept is clear to use native tools fields and pages, to build a media db and then provide helper modules to manage them. And a lot is possible then. Building proprietary image fields that somehow provide other functionality is critical as when Ryan builds whole new functions and tools into image field that then are missing in other self made image modules. My tools work still and I benefit from updates on the image field cause I use page per image with a core image field. Ok but now I use the new croppable image field and it doesn't let me use new size tools Ryan build cause it uses other or modified markup. Another benefit is that I can use ListerPro to build a search and edit tool to show the image DB. I don't have to think about if it woud work it just works.

Post max size is for uploads (and sizes of data. I'm talking about count of post vars (inputs).

The ImagesSelect let's you filter and search from the images you create as pages like ImagesManager does. You see a list of results and each has a +add button to add it to the page. It looks like a image field and it copies the description from the source but you can then change it. the image it self is just a reference line a page select. It doesn't copy the real image. So you can't insert it into a RTE On the page. It doesn't support multi language. The live search is using Selector Inputfield from core. The image markup inserted is copied from the core image field but isn't meant to function like it. Just the sorting and description field.

I tested installIng ImagesManager and then ImagesSelect and works fine. Note both modules are WIP and proof of concept. I don't support them. They're not in the official modules directory. ImagesSelect is tailored to a project and while working it isn't meant to be ready to use and has many hard coded assumptions that all is easy to customize if you know what you're doing. So anybody can take it and study it and adapt it. I just shared it for others to see.

In backend it works cause there's no outputformatting. Doing in a template you see the error cause front end template context has output formatting enabled. Not sure if pagetable causes issues with clone but can't remember if Ryan said something. So the solution is right there explained in the error if you read it! Try a $pages->setOutputFormatting(false) before your code.

My example is right from Process.php comments. Not sure about status.

Security mods on server. Max post inputs reached?

Seems to work great here. Awesome tool! Thanks.

Thanks for making this, great idea that comes in handy. Just for code: At a first glance at the code, why does it have to be a Process module that is autoload? Not sure but I think implement Module isn't necessary as Process class already has that? Instead of this: public function install() { parent::___install(); /* Create manager page */ if (!count($this->pages->find('name=' . __CLASS__))) { $p = new Page(); $p->template = $this->templates->get('admin'); $p->title = 'Page Path History Manager'; $p->name = __CLASS__; $p->parent = $this->pages->get(3); // Create as children of /admin/pages $p->status = Page::statusHidden | Page::statusSystem; // Hide in menu and prevent deletion $p->process = $this; $p->save(); } } You can also do now public static function getModuleInfo() { return array( 'title' => '', 'page' => array( // optionally install/uninstall a page for this process automatically 'name' => 'page-name', // name of page to create 'parent' => 'setup', // parent name (under admin) or omit or blank to assume admin root 'title' => 'Title', // title of page, or omit to use the title already specified above ) ), ...

You could also do $current_lang = $user->language; $pages->uncacheAll(); $saved_lang = $user->language; $user->language = $current_lang; // reset So it will reload the user. But you have to reset it back afterwards. (And I'm not sure a $pages->uncacheAll() will make processwire reload all pages already in cache. So I'm not sure it's a good solution if not really needed. )

What hook? Looks complicated.

@horst in the LanguageSupportPageNames.module I guess. It's evaluated with some AI to get the right language and page. Once the language is determined by the requested url the user language is set on runtime. It's not saved in DB of course. This would load the cached user already with changed language. This is determined very early before page renders etc. So only way without adding your own field to manage this, would be to save the language to the user with a new property (at runtime) and this should happen before LanguageSupportPageNames does it's job. In template code you won't be able to do this unless you do a DB manual query. So an autoload module would do that with an added hook line of code in the init() (see HelloWorld.module) public function init() { $this->wire("user")->savedLanguage = $this->wire("user")->language; } and then use in templates: echo $user->savedLanguage->name;

User language is tied to what language is requested. So it changes on runtime. User language set in admin is for backend primary. If you need user to set a language for frontend you could add a field to user and check that.