Soma

A page field uses pages, so the array will contain the page id's. So you go through them and add them to the field. To make things easier with adding removing pages, you can just removeAll() and then add the selected values back. if($input->post->submit){ $page->of(false); $page->checkboxes->removeAll(); foreach($input->post->checkboxes as $pid) { $page->checkboxes->add((int) $pid); } $page->save(); } Edit: edited code a little

You need to set $brand not $page $brand->of(false) (Short version)

Ah now I can reproduce this. But I don't see a solution to this shortly, the image resizing and PW image plugin takes the window size to resize the image selected if original is bigger. There's so many parts involved and there's a lot of width height going on all over it's hard to track down. And it's not a bug but a more of a feature after all. If you select an image, you get presented with a resize dialog, if the image is scaled down, you'll see a "link to larger version (1200x800)" checkbox with the original image width. You can renter and set the width or height to the width and height inputs and then click insert image.

Can I have a 3d animation? :-D

And do you have image field setting max width set to 400? Was what Ryan asked.

Try 1:=option1

Also wanted to chime in and say wow! It could be almost coming from me Joke aside, I really thought about that the day Ryan implemented this, but never bothered as I'm not currently needing it. Really cool here's how it looks on my Teflon dev theme.

There's a bug in Functions.php I just filed a issue on github. I just tried to enter a module name that already is installed, and it checks beautifully for that and says it's installed but older version. This is meant to be a way to update the module too? I then hit download, but it felt wierd. It may would be cool then to have the title or message then say an update is available more clear? And the button called "Download v0.1.3 update" or something.

Take all my code and money too. Well the latter comes in form of code. Serious, I'm very proud to have played a role. I agree with what you said and will first go check it out and come back later...

BTW you guys know you can add predefined templates to TinyMCE that can be selected and inserted to fill in? Those are html templates and they can contain tags that will be replaced with current date, user name or anything. You even see the preview when selecting them from the dropdown. It's much like what Macrura posted just "better".

I'm building something like block elements for processwire, it's just as with such system that they are complicated to do and often the system you implement them come to limit in terms of functionality or UI. If you are interested I could share the bare bone WIP proof of concept. We use a CMS at work for many years which allow such block system to build directly in the template that then is editable for the end user. You add a new block, select what type of block, and it will load the "template" with the field defined there. And so on, you can limit the count of the block, sort them and so on. Unfortunately the CMS has many flaws and is somewhat bloated and sometimes becomes a burden. It's as open as PW regarding what you build with it, I'd even go as far as saying it is a lot more flexible than PW. PW is just a lot more convenient to build structured data as is, simple and modular extendable and a lot more fun and reliable. If you want it's like Repeaters on steroids. This is what I originally imagined that repeater would be, but it came a little different. There were some people also discussed this when repeaters were introduced. Imagine Repeaters where you can select a "template" for each item. Each of them representing custom fields as many or different as you like. Those "templates" could be associated with a repeater. What I tried is to find a way to use the repeaters as a base for this and I think it would be possible to adapt them to work this way. Just a lot of work I then started building something from scratch just for fun that works like repeaters but only in the frontend. In the template you define the blocks you want to use for the repeater and it then will render a editable, sortable simple interface if logged in to manage block, and render them when not logged in. The block are pages saved unter a parent in the admin. There's no interface for the admin as this would go too far for now. You then could define a text field for a title and a textarea for the paragraph, and image with alignment, another with a video, another with a map etc. And if Wysiwyg used it would only to be able to set links, bold and such things as basic styling. This way you can get away from using a Wywiwyg as the main content editor and put everything in there which we have to agree is only as good as the editor, and we all know they can cause troubles. Rather than having building a complete new system with UI and not what for within a textarea or Wysiwyg, which would already exist if it would be a good way, I'd rather see the repeaters on steroids, for block based content easy to edit and build.

A coincidence, hide it with a module http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/

Its only needed in site admin templates. You dont need or should change anything in core. It willalso get overwritten on a update.

A coincidence http://processwire.com/talk/topic/3919-individual-image-field-widths-float-display-inline/

Testing this again, I got the latest dev again with the session login throttle fix, and can't really say now what version it was and in what case. I only got it once after trying to login (custom login) when there's was a throttle of 10 seconds going. It would throw me the has() on a non object in user.php. But somehow it's gone in the dev. Since in stable 2.3 the session login throttle is now still broken, do you consider fixing it there too because it's an quite important feature security wise.

I'm sure it works in your case for now, but is "wrong"... - There's already an API var $fields! http://cheatsheet.processwire.com/#fields , as I said in the previous post. Now you overwrite it, and it may cause problems later if you would want to use $fields somewhere else. It's like if you would overwrite $page or $pages... (Apart from that you're getting inputfields and not fields here), anyway. So I'm wondering why your $fields template var isn't exisiting! You may already have it overwritten before that code somewhere? - The red code you posted isn't necessary in this code. - But if you want to go with $page->getInputfields() you already get the inputfields!, so there would be no need to get it again. - Then also with $page->getInputfields() , there's no need to set the $f->attr("value",$page->account_type) again as the inputfield already has the value set from the page you're getting them. So this would be correct if you want to take this route: $inputfields = $page->getInputfields(); $f = $inputfields->get("account_type"); echo $f->render();

Strange for me theres such an error only in the dev version. The stable works fine..

Ah or with $child->child->id should also work. does it?

The error reveals that get() is called on a non existent object. In the example the $fields->get(), see? Means the $fields somehow doesn't exist... it can't call the member method get() on it. $fields is like $pages or $page available in all template files, if not, there something either wrong with your installation, or you're using $fields in a function or module. In the scope of a function you'd have to use the global function wire("fields")->get(). $page in the getInputField($page, null) is just a page and I think it can be any, PW requires it. The secon argument is for the context. Since fields can have template context settings, you could pass the template there I think. You can see the base classes wire/core/field.php and wire/core/inputfield.php or any wire/modules/Fieldtype/* and wire/modules/Inputfield/* module that extend those. But the more important part in the code is this: $f->attr("value",$page->somefield); Where you set the value of a page to the inputfield before rendering. This is a very broad, somewhat complex or versatile, advanced and individual topic, I always have a little hard time educate to someone with basic to none coding skills just through writing without knowing the whole scope of the project and context. Are those front end users, trusted or not. What data needs to be edited or created... uploads, datepickers or just simple selects and so on. I spent already sooo many hours coming up with examples and explanations that I hardly feel motivated to do it over and over again. No offense to you or anyone personally of course! Peace The thing is, it is an somewhat advanced topic and it also took me some time to find all out and learn by trying and reading source code in core, understand how it works and what are the limits. It's also good to know that the inputfields and fields used in the backend primary are built to be used in the admin context and not originally intended for front-end usage. But it's built so well by Ryan that it's possible to use them out of the admin context to some extend. It's just that some fields other than simple text, select, radio or checkboxes ... like files, images,ASM select, dates with datepicker, they require some more assets to also be included in your front-end namely js and css files. So you'd have to include them aswell. The admin theme templates uses the $config->scripts and $config->styles file arrays to render the styles and scripts loaded by a inputfield module. I also recommend: - Read that thread I linked to completely. Have a look at some examples (my gists with forms) to get a feeling. They're by no mean complete or the only way. It gives you enough flexiblity even with styling and markup. You can set the markup of InputfieldWrappers. ie. $form->setMarkup($options) you'll see in wire/core/InptfieldWrapper.php - Study the FormTemplateProcessor module by Ryan. http://modules.processwire.com/modules/form-template-processor/ As Matthew said, you can also just build your very own markup and forms, as you would normally and use the API to add values, validate and save values to pages. It's not that much of a magic. And maybe keep trying to make simple forms using the API first to get into it... you know start small, grow big. Try to learn from mistakes and experiments asking in the forums.

Doesn't matter in the main.js or inputfields.js inside the document ready. Speaking of the /site/templates-admin/scripts/main.js Depends if you have a custom admin theme installed already or not. If not and you use default admin theme, you can copy the /wire/templates-admin/ folder to your sites folder and edit away.

Ah now that's the numChildren problem. In that it isn't published or access aware. Means even if all children are unpublished it will return true. There's now a attribute to make it recognize that Not sure what version it was added exactly but maybe this works for you: change all $child->numChildren to $child->numChildren(true) Or if you use older version you can instead replace it with this: count($child->children)

Huh? I didn't say anything? I'm just not sure what Peter is up to with and how he's approach to create front-end forms and for what task really are... as he says he don't wants to use form API. But it really depends what forms are they? There's nothing wrong with using form API PW uses itself in the backend and I'm the one that brought extensive and various form examples (with upload and page editing) in multiple threads about this subject. I've been using it since there's required field options and error messages. http://processwire.com/talk/topic/2089-create-simple-forms-using-api/ and my gist are full of it https://gist.github.com/somatonic

My guess it's that he has a local /site-default/ folder and tries to upload or edit it through it... but it doesn't exist on the server of course.

Yeah it's this LanguageSupportPageNames and is in dev with 0.0.6. Seems to exists in stable as with 0.0.3.

You don't need another type or class just for different validations of a text field, you can hook into the processInput of the inputfield and add your own validation and add error if needed. Rare cases where I need this but it's great and flexible way. There's also filter regex you can add in the field settings for validation but maybe little limited. Maybe some sort of module with common validations methods that can be added or configured along with multilanguage (of course!) error messages would be a nice addition. This could then be added to a field or through a hook.