Soma

http://www.w3fools.com/

I noticed soemthing strange I don't think is very good. Add a date or email field to a template (ie basic-page). After filling the field on one page and looking at DB field table everything is ok, there's a new entry, the value is saved with the page id. Now if you remove the field from the template, you get prompted if you really want to, and after hitting ok, it shows messages for each page that uses this template that the field was deleted. So far so good. Now but you wouldn't expect that if you look at the field table, suddenly there's an empty entry for one and each page that has this template! Oops. And this empty data will stay there until you delete the field itself. It happens so far for date and the email field, for text field it seems ok. I use 2.3 dev (not nightly) and haven't tested in older versions.

That's fun: foreach($templates as $template){ foreach($template->fieldgroup as $field){ if($field->name == "myfield"){ $template->fieldgroup->remove($field); $template->fieldgroup->save(); echo "deleted $field->name"; } } }

When calling a page url without trailing slash.

Dragan isnt the problem issued by a custom theme? It works in every browser for me.

Moved to dev talk board.

Ryan as mentioned in an other thread about urls it looks like if language page names is installed it doesnt redirect to trailing slashes as without module. Maybe related?

And in modules there's also $this->pages ...

Now that you say I also stumbled on the same odd behavior of built in fields versus custom fields the order matters

I have it run!! I'm not sure I can follow you completely and I have a difficult time understanding what is wrong with your setup and how much you understand what you're doing. First, my setup is like this: We need a multiple select page field you can select from all page in your site tree, that is.. - pagelist_hidden - a page field, multiple page (page array) checked, the setting is "Home" page as the parent and the inputtype is PageListSelectMultiple* - No I attach this field to the user template (system template needs template filter set "Show system templates?" to show) So now I can select and add pages that should be hidden on every user page, since user template now has this field. Now if you login with the user, page are not shown in page tree anymore. This module does only this to filter those pages out on the ajax json response the admin page tree works with. It's more of a workaround and proof of concept / example module. It shows how it could be done. While this is simple, adding more features and configuration would go pretty complex and I'm not sure it's a route we should promote. Even just to reverse and add pages the user should see is a differnt thing considering a tree based structure. It's doable but maybe should be avoided. I your case it sounds like every time a new user is added you need to do a lot and add the new pages to each user. And you have templates for each user, but all the same setup? To get around the template based permissions I guess? I think it also could be avoided by using almost exact like module to add pages the user can edit and go with one set of templates. I think there's also some examples or even a module by Ryan around. https://github.com/ryancramerdesign/PageEditPerUser http://processwire.com/talk/topic/2141-module-page-edit-per-user/ http://processwire.com/talk/topic/3051-page-edit-per-user-and-template-access-how-do-they-relate/

There is a filter on templates screen above the list..

The template for user in PW. Its a system template so you have to filter for sytem templates.

What I do in a similar situation is save the value ob page save to a field outside repeater. Makes for easy and fast searching with limits and pagination.

I think the page field should be added to the user template and not the news template. As per description the page field is to define page that are invisiblevto the user.

Yes exactly. The pseudo user page can be anywhere and you could add children pages for all kind of things. And only a couple field like prename lastname to the real user template. You dont have to it's up to you. I also think you're creative enough to already see what is possible it's more the code you worry. Let me say in PW it'S REALLY no rocket sience compared to other systems and just keep trying to go with the simple API. Once you learned that you'll do anything with ease. Maybe I'm too modest but I'm also not a hardcore programmer but a design guy, and learned a whole lot with PW. Of course I got some background and did a lot with php. You're in good hands with the guys here.

A posibility I also use is have a page field reference added to the user template and reference the userpage there. Makes it easy to setup and you dont have to care about names as it's already checking for unique username.

Yeah cool but now we don't know what causing the issue on your side... again plz post your specs. Maybe? Thanks!

I'm guessing some autofill plugin.

Modules Manager doesn't check the modules location before updating. Though when you placed it in the wrong spot to begin with manually it get's quirky. Depending on the module and how the user manually installed the module previously and how he named the folder it can mess things up. It's a known issue, I think we need to keep in mind when migrating the ModulesManager to the core soon. Currently ModulesManager creates a folder with the "classname" entered when adding a module on modules.processwire.com, it's the only reliable info we got from the module feed, so it has to take that when creating the folder.

wire("page") in this context will give you the admin edit page and not the page editing. In this case you can get the page edited through ProcessPageEdit. if($this->process = "ProcessPageEdit") { $page = $this->process->getPage(); }

It does not, but maybe you can find out why it does it for you?

What if you copy the tiny_mce_popup.js to your tinymce folder?

I think you need fieldgroup to add fields first and then add fieldgroup to template. Look at apeisa's shop module for examples. Oops or couple posts above nice guy soma has some example.

No there's no way to avoid this, except if you would do $fields = $somepage->fieldgroup; foreach($fields as $f) { $inputfield = $fields->get("$f->name")->getInputfield($somepage); $form->add($inputfield); } This somehow gets around the error when rendering the form. But once submitted you'll end with the same error. Yes you are correct. In PW a page needs to be saved before files can be added or accessed, the PagefileManager requires a page id and since you build it using inputfields in context of a page object it fails. Pagefiles are saved in the filesystem using the page id, and since the page doesn't yet have an id it's simply not possible. For the same reason Ryan's FormTemplateProcessor also only works with text fields. Since you seem to have file fields in your template, you have to save the page to go this route, which I'm sure you don't want. Or remove file fields from the form, which is maybe also not what you want. So you have to build it different and build the form differently, maybe still using the fields from a template, but add your own file field upload. There various threads and example I did a while back. Some are on my gists. Example: https://gist.github.com/somatonic/4150974

But now cheatsheet is a PW site and Ryan can edit it easily himself.