LostKobrakai

It seems like you would need to change the rewrite base in the .htaccess. That's the most obvious thing that would cause this behavoir.

Inputfield dependencies are evaluated by javascript only, that's why the api selectors do not work. The only information the dependency can evaluate are the values of the present form fields. It even does not work if a field is set to not editable, because in this case the value is not rendered as form field. The first impression of the form is after the first saveReady hook, as each page is created/saved right after you submitted the page name.

Which version of processwire are you using? In 2.5 should be a admin page called "Find", which allows for exactly that. To predefine multiple of those lists there's the pro version of this module in the store: https://processwire.com/talk/store/product/16-listerpro-single/. It allows for easy creation of custom listers and a few things more.

Edit: It's actually a other line: https://github.com/ryancramerdesign/ProcessWire/blob/master/LICENSE.txt#L79

Another thing to your entry post, please use the code boxes for code. foreach($myPages as $p) { $p->set("your_new_field", $p->field.$p->anotherfield); //Field is runtime only } Maybe this works. You'd need to fill the field for each page. Even if it's different contentwise.

You could use FieldtypeConcat for that job, so you even wouldn't need to have the foreach loop.

Directly fetching only the cells you really need will always be faster than the api. It's the nature of having an additional abstraction layer between mysql and php.

You can't, you need to check that manually. Inputfield dependencies are only evaluated on the frontend by javascript.

This still does not explain why a page has a modified_users_id if it won't change depending on who's saving the page.

@horst I know that and I actually meant reusing groups of fields in different templates not in a single one. Just like the example in the entry post with have multiple classes which implement the same base classes to share sets of properties / methods.

Just to make this clear, you want a way to be able to continuously import from that source and not a one-time thing?

I would think that this should happen without manually assigning the user.

The only issue I'd have with it, is that you can't easily reuse fixed groups of fields. You have to set this up for each template on it's own or implement a custom setup process via api. But still better than nothing.

Getting the different values is easy for the pagefields, as you know all the possible values (the pages). $formats = $pages->find("template=format"); foreach($formats as $format){ $num = $pages->count("template=video, format={$format->id}"); // Count all videos where format is $format if($num) echo $num; } For the other informations I'd suggest going the same way. E.g. for clip length: Add pages to your tree for the different clip length options (5-10, 10-15, …; you don't need the exact values for the count). Add a pagefield to the video's template: "clip_length_option" Use a hook to update this field on page save (example) dependent on the field that holds the real length of a clip. Use mysql to update existing video entries with the new field data (i think that's the fastest way as you're already using mysql). Hope this helps.

I had looked a little more at the core code yesterday and the only thing that seemed to be able to cause this would be disabling trackChanges for that case. Or even not changing anything.

The easiest way would probably be redirecting the requests of the subdomain to the admin backend via .htaccess. Or maybe use symlinks to the folders and just use .htaccess to remove the "/processwire" part of the url. Or map both domains to the same folder and use .htaccess to do stuff dependent on the domain. So it should be no problem, just a bit of rewrite trickery.

Can you elaborate why find() doesn't work for you? It's made for that job. Edit: Just read that you need the count. Use count() instead of find(). It's exactly the same, but does not load the data and just returns the number of returned pages.

I'll try it, but it won't be as efficient as your mysql statement. // This is optional if you know the templates $t = new TemplatesArray(); foreach($templates as $template{ if($template->hasField("myfield")) $t->add($template) } $ps = $pages->find("template=$t"); $list = new PageArray(); foreach($ps as $p){ $list->import($p->get("myfield")); } $list = $list->unique(); $list->explode("name"); Edit: getting the templates could be more efficient like this, but I'm not sure about this. $myfield = $fields->get("myfield"); $fgs = $myfield->getFieldgroups(); $t = new TemplatesArray(); foreach($fgs as $fg){ $t->import($fg->getTemplates()); }

There's currently no way to implement this. Each template does have a single fixed set of fields. That is at least the answer to the backend structure. What you can do is provide a own php class (subclass of Page) to the "parent" entity. This class could then populate itself at runtime with the fields of those childpages you mentioned. This way you could at least maintain the structure in your code. The option to set such a class is in the template settings if you enable advanced mode. Maybe this could even be done with hooking the Page class, and without using the advanced mode settings.

Would uploading the whole thing as zip be an option? Edit: Just had a look at the source. There is an option to allow dots in filenames (the .min is never parsed as extention), but it's not used by pagefiles. The more fail save way of handling files is still to not allow them.

As someone told me in the ACE editor thread, you can just skip ACE when uploading to production. You shouldn't change the hanna codes there any way and that's the source of the big overall file size. The module itself is not larger than others.

It's not really a big security risk to allow access to html files, as that are static files. It's just that by now it wasn't a intended behavior to be able to access html files, therefore the rule. Also in the templates folders are maybe docs and such things in html format, which should probably be hidden. But if you use markdown this security is gone as well. Writing a custom .htaccess rule to allow access in the bower_components folder would probably be the best / most flexible bet.

If these layouts are predefined, then you could go and use FieldtypeOption to simply build a selectbox for the backend where the editor can choose. In the template file it would be matter of a simple if / else structure. You could even use includes or wireIncludeFile or wireRenderFile, to import the different layouts, so they're available to other templates as well (if you need that or simply for more structured code). If the html stays the same you could easily use file fields to let the editor upload css / js files. These would be dynamically added to the site. It's better to use files instead of textfield (which would also work from a backend point of view) because it's better to include files instead of inline codes. If you need the html to also change you've two options. Either use again the file field for a php file and include that file, or use a textfield with the new Inputfield ACE Extended, but for the second option I'd suggest using a templating language, as it's easier and more secure than handling real php code.

I missed the false if condition. And yeah, will do that now

Your problem is actually in the html, not in the php code. Forms are send in plaintext by default, so to upload files you need to add this to the form tag. <form … method="post" enctype="multipart/form-data">…</form>