Soma

Have you allowed link attributes in TinyMCE?

http404 doesn't necessarely mean it was on 404. Guest because it is triggered by a visitor. But can be amything. A cron script or a template or module.

Try $pages->find("template=visit-detail, limit=10, sort=sort");

Turn off session fingerprint in config.php.

You can make field global like the title.

@lostkobrakai There's in config.php for that problem. $config->pagefileExtendedPaths = true; Apart from that there's no limit in PW, going for millions may require special and different strategy depending on what it is built for. After millions of pages a fulltext search on large text's can grow linear quickly to several seconds. One also just have to take care about what code you build and it's easy to run into timeout or memory limit if you don't be careful. Also it depends if there's a lot going on like lots of user that post something. PW handles that all well but depends also on what server.

You would not loose anything. You can add objects to a normal array and later can access them and they're still a Pageimage with all its properties.

Why do you need WireArray? It can be a normal array and store images in there.

Can you give access? What is the code where you output and see HTML tags? Do u you have a HTML entities formatter set on that textarea? Cause that converts to entities you then see the <p> on frontend.

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.