Soma

You're mixing vanilla PHP with PW API. Selectors are PW specific. I don't know you guys know that you can also do this in PW (usually people miss this) if($page->is("template=home|basic-page")) echo "has template";

I'm not sure why you want to make it autojoin and global, global ok but autojoin? I'm not sure what autojoin does on repeaters but I don't think it's really needed. But most likely this or global could cause problems with repeater... However I just tried with one install and it works fine making it autojoin, but didn't wanted to go global... In the other install (latest dev) where languages support module is installed and also LanguagePageNames, I first had to install repeater module... and then got this: Notice: Undefined property: User::$language in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/LanguageSupportPageNames.module on line443 Catchable fatal error: Argument 2 passed to LanguageSupportPageNames::getPagePath() must be an instance of Language, null given, called in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/LanguageSupportPageNames.module on line 444 and defined in/Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/LanguageSupportPageNames.module on line 244 This error message was shown because site is in debug mode ($config->debug = true; in /site/config.php). Error has been logged. After a refresh it was gone. But when I do create a repeater field and make it autojoin and global I got this: Notice: Trying to get property of non-object in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/FieldtypeTextLanguage.module on line 41 Notice: Trying to get property of non-object in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/FieldtypeTextLanguage.module on line 41 Notice: Trying to get property of non-object in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/LanguageSupport/LanguagesPageFieldValue.php on line 114 Fatal error: Exception: Method Page::editable does not exist or is not callable in this context (in /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/core/Wire.php line 232) #0 [internal function]: Wire->__call('editable', Array) #1 /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module(485): Page->editable('some_repeater') #2 [internal function]: FieldtypeRepeater->___wakeupValue(Object(Page), Object(Field), Array) #3 /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/core/Wire.php(271): call_user_func_array(Array, Array) #4 /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/core/Wire.php(229): Wire->runHooks('wakeupValue', Array) #5 [internal function]: Wire->__call('wakeupValue', Array) #6 /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/core/Page.php(443): FieldtypeRepeater->wakeupValue(Object(Page), Object(Field), Array) #7 /Applications/XAMPP/xamppfiles/htdocs/pwmultilang/wire/core/Page.php(1352): Page->setFieldValue('some_repeater', Ar in/Applications/XAMPP/xamppfiles/htdocs/pwmultilang/index.php on line 214 This error message was shown because site is in debug mode ($config->debug = true; in /site/config.php). Error has been logged. And I can't do anything anymore, just get this error always. Then I go delete the field and its table and in fieldgroups in the db and it's all back and working again.

Id guess something with sessions...

There you go http://gruntjs.com/plugins

jQuery UI datepicker has different date formats than in PHP and not compatible. Maybe it's that. $field = $modules->get("InputfieldDatetime"); $field->label = "Aika"; $field->attr('id+name','time'); $field->required = 1; $form->append($field); // append the field Also I don't see any date formatting here...

*grunts*

Peter, depends what you have in mind. You can create custom admin pages and build your form using PW forms and API, so building on the foundation. The thread teppo linked to shows how to use inputs and form, whether for frontend or backend. Using PW components gives to plenty of possibilities to validate and manipulate and hook into various parts of the form and it inputfields. There around 400 hookable functions in PW http://processwire.com/api/hooks/. With this at your fingertips you can do almost anything pretty quickly, whether in backend or in front-end. It depends (as always) a lot what exactly you want to build and what the need are in detail and then look at what would fit best. Also remember all the PW backend stuff is built out of modules exactly the way you would build custom admin functionality and you always can look at how it's done or copy a module to site folder and start modifiying it. You could create your own admin pages and build mini apps that help editing, creating content and it's pretty straight forward. It would be in the same way for when building it in front-end. PW doesn't have a solution to all ready, but a strong foundation to build anything you want. I'm not sure what else you need to know or what you're exactly have in mind. I think you're still maybe need to play with that stuff to better understand all of that stuff and how to go about it in PW. So you should slowly start building custom admin pages I think and ask away.

Also look at core modules if you arent sure about something. Look up ProcessPageList.module which is configurable.

the config "data" field in db is a "TEXT" field so about ~64kb. Module config is stored as JSON and to store 5mb of data you would need a MEDIUMTEXT field ~16mb. Of course you can, but depending on your data and for what it's used it's maybe not a good strategie. To add another possibility, you could add a textarea (MEDIUMTEXT) field to the "admin" template, and store the data there. But if you would need flexible and larger data stored I would certainly also consider using pages.

Hey Ryan, I tested again on different installs and I'm still getting strange results. $pages->find('title|parent.title%=space'); In my language enabled install I get something like the following, no matter what user language is set to. Although it should return other pages that also have "space" in their title, it doesn't return them in the result. Title: Space | Parent: Images Title: hubble-wallpaper-space | Parent: Space Title: hubble-wallpaper-space-647500_1600_1200 | Parent: Space Title: outer-space-stars | Parent: Space Title: space-space-584336 | Parent: Space Title: pastedgraphic-2 | Parent: Space Title: pastedgraphic-3 | Parent: Space Title: 492772525_d8803eb637_o | Parent: Space Title: 2400862255_daeb5326d8 | Parent: Space Title: pwprofile_ch-uploads-4 | Parent: Space Title: pwprofile_ch-uploads2-4 | Parent: Space Title: pwprofile_ch-uploads-4 | Parent: Space Title: pwprofile_ch-uploads2-4 | Parent: Space Title: pwprofile_ch-uploads-4 | Parent: Space Title: pwprofile_ch-uploads2-4 | Parent: Space ... Notice the first has parent "Images". Which is strange as there's also "space" in titles under "Nature" parent! When I remove the parent.title from the selector I get this: Title: Space | Parent: Images Title: hubble-wallpaper-space | Parent: Space Title: hubble-wallpaper-space-647500_1600_1200 | Parent: Space Title: outer-space-stars | Parent: Space Title: space-space-584336 | Parent: Space Title: space | Parent: Nature Title: space | Parent: Nature Title: space | Parent: Nature In my other install with different pages but same selector, where I don't have language support installed: Title: Templates space | Parent: Home Title: asdasd§ | Parent: Templates space Title: sdf sfs f | Parent: Templates space Title: gsgfdsf | Parent: Templates space Title: fgfdsgsa as | Parent: Templates space Title: Space | Parent: Images Title: space-space | Parent: Space It finds all that it should with "space" either in title or parent title.

It's a general miss-conception that children need playful childish design, they're as demanding as adults and don't want to be treated with "dodoo dadaa"

You can just use subfields on page references. For example to get the title it would be something like this: pagefieldname.title

This is a little example to show there's nothing that special with repeaters, just think of them as Pages or a PageArray and this example (extending from Ryan's example here http://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=32856) might help understand https://gist.github.com/somatonic/5391391

Thanks adrian for the report, turns out the download github link as wrong. Should be fixed now.

Free beer!

Just added this module to the modules directory. http://modules.processwire.com/modules/chrome-php-logger/

Ok once again I have beaten myself... after trying to find a reason, nothing worked I thought it just can't be and knew there must be something stupid like $page->template = "home" in the code... and gotcha! I really should be more careful and always use "home" == $page->template Thanks diogo for your time.

Thanks diogo, yeah somehow, I just have a main.php and in there echo $page->template outputs "home" always. It's all very confusing and I can try what I want but no success. It works in other installs though. I copied this site from one that is very similar and used same template approach. So as a start I copied db and site folder, and dropped in lates wire core. I'm still trying find what's wrong, but I'm kinda lost.

I use alternative filename on template to use main.php, from where I render the content according to the template name. So basic-page would result in including the /views/basic-page.inc in the main.php I now use latest PW on this new site and it doesn't work anymore, as all those end up having a template name "home". When I echo the $page->template it shows "home" no matter what template. I changed things around and when I use it without alternative filename it works as usual. Can somebody confirm this?

Thanks for you work here mindplay, I'm sure this will be interesting and comes handy for people that use and like this stuff. Personally I never felt the need for this in ProcessWire, as for the hand full of objects and variables I usually need that are always the same anyway. So in other words PW is so simple this is like having a description how to use a key on a door.

How about storing it on a page you put somewhere? I dont think it possible to use module config without using the interface. Otherwise you could maybe store it manually to db on the module using json encode and sql.

Theres a plugin in TinyMCE called CodeMagic. Its not enabled by default but you cab add codemagic to the plugin and controls in the field tinymce settings.

Aah, wasn't reading careful and didn't spot the ...->fields... well yes it's the same at the end but using $fields->product_price->label; is little shorter

Field label is not in the page field value, you have to get it through the field itself. echo $fields->get("body")->label;