adrian

Hi Joss - I am not sure either really. I definitely like the fact that PW doesn't load tons of stuff on the front end automatically. I guess I just think in this case it is applying the class and loading the TinyMCE config settings, which it only does when there is a form field that requires them, so it seems to me that it is only doing half the job. I think perhaps it should either load everything, or nothing? There is quite possibly a very logical reason for this that I am not seeing though

I agree that separate logins would help, but all the editing I am talking about is front-end, and will be by groups of people that may change on a daily basis, so it starts to get complicated. I am sure I will make use of your module as a starter, but you are right, I may have to do this differently to handle front-end protection.

Hi Soma, This is a great setup, but I am thinking about the issue of more than one person using the same login details. I have a project where each team of people will have a single login and I'd like to be able to have the warning popup even if the page is being edited by the same username. An IP address won't be appropriate since many will likely appear from the same address. I am thinking a cookie approach might be best. The other thing I want to be able to do is use this to warn users editing pages via a front-end form. I plan on implementing these shortly, but thought I'd ask if perhaps you already had any plans along these lines, or any suggestions.

Hi everyone, Not sure if this is a bug or intended behavior, but I am using $form = $modules->get('InputfieldForm'); to load a page for editing in a front end form. Everything works great, including applying InputfieldTinyMCE as a class on the <li> and loading the tiny config settings in the head: 'var config = .........' But, the one thing missing is the tinymce scripts themselves - ie: <script type='text/javascript' src='/wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.js?v=358'></script> <script type='text/javascript' src='/wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.5.8/tiny_mce.js'></script> Obviously I can manually add these, but I feel like they should be added automatically if a field requires the editor to be loaded. Thanks.

Fair enough - I didn't realize they were moderated. Still, for whatever reason at the time my browser just kept hanging and never showed any success text. No big deal if it's all working now.

Well it looks like they ended up posting, despite all the hanging - I guess whatever it was resolved itself!

I am not sure what is going on, but I just went to post a comment here: http://processwire.com/api/fieldtypes/comments/ but the form won't submit. I tested on FF and Chrome - it just keeps trying to load the page. I actually just installed and set up the comments module on my own site and it works perfectly. I was just trying to note the following: "Just wanted to point out a missing step in the instructions above. After you have created the new comments field, you need to add that to the necessary templates. This needs to be done somewhere between step 3 and step 6." Is anyone else have troubles submitting a comment? I actually had to clear my browser cache and restart it to get the PW site to load at all after that.

For anyone else who stumbles across this post, Soma's link should be: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/templates-admin/default.php#L67

Nice - glad I could help

When I was trying to figure out the error, I stopped APC and it editing the repeater fields worked fine. I have since restarted APC and I can actually edit the fields fine again now, so I guess that restart cleared whatever the problem was in the cache. Hopefully just a weird one off issue?

Thanks Ryan - some great tips there - I am sure these will come in very handy.

Ryan, That code is on line 71 for me also. I checked out the dev version within the last couple of weeks. Maybe it's an APC config setting at my end. When googling the error I did notice lots of results mentioning the big name CMSes and APC seems like the most common culprit. To be honest, I went back to using pages rather than the repeater anyway. It was for a staff directory and I want users to be able to find the people via the search function and be able to display individual pages for each staff member, so repeaters weren't going to work in the end anyways. I can help debug though if you'd like - I still have the repeater fields set up, just unpublished.

Hi Soma, I am developing a web app based on user data submissions so there are many different parameters that need to be collected - these are then the basis for generating a variety of dynamic outputs - tables, graphs, maps etc. There might be a more efficient way to do what I am doing, but I think in this case there is no opportunity to re-use these anymore than I am already, which is for each user submission. If you have any general tips, I'd love to hear them. Thanks

I don't think this will fix all of your problems (or maybe even any!), but I found I had to set: $config->sessionFingerprint = false; Otherwise I was being asked to login again every few minutes. Might be worth trying.

Ryan, Well the reason I was trying to figure out the input field type is because I was generating a front-end form and needed to figure out the type so I knew how to handle it. I was manually iterating over each field so I could do some unit conversions on the values. Anyway, I discovered a much easier way to do this, so no need to figure out the input field type anymore. Regardless, back to my point - I guess in general I am just wondering if it might be possible to provide more contextual documentation, probably only for superusers, that shows how to access any of the elements via the API, whether it is the type or columnwidth of a field, or the name (rather than just the title) of a field when in page view. Another example would be the field tags (remember I asked about that the other day). I'm afraid at the moment this is a vague and not well thought through request. Maybe when I have a little more time I'll come up with a list and a plan. Thanks for listening

I know it seems silly to be creating them that long - they started getting so long due to my adding prefixes referencing the template and page they belonged on. This was before I figured out tags etc, so I am back to reasonable lengths again now.

Perfect - I had actually tried 16% initially and that didn't work either. I didn't realize it actually had to add up to 100% exactly. That change did the trick, thank you!

Thanks Ryan - that makes sense - I have so much to learn about the inner workings of PW

My page with the repeater field views perfectly, but when I go to edit it, I get this error. Error: Cannot call overloaded function for non-object (line 71 of xxx/usaus-h2o-dev/wire/modules/Inputfield/InputfieldPage/InputfieldPage.module) If I disable APC then everything works fine. Not sure if there might be an APC setting that can be tweaked or something in PW that can be fixed. Just to clarify, I am using PHP 5.4.11 and APC 3.1.14

Actually it turns out that this is a little more annoying than I realized. Even though the table won't create because of the length of the name, the field does actually get created. And when you go to delete the field you get another error: Session: Incorrect table name 'field_very_very_very_very_long_table_name' DROP TABLE `field_very_very_very_very_long_table_name`

Only a very very minor thing, but it would be nice if the field name input was restricted to 58 characters (64 for the mysql limit less the 6 for the 'field_' prefix that gets prepended), so that we don't get an error message and have to fill everything out again.

I have a fieldset with 12 fields (months of the year). I have the widths of each field set to 15%. In the admin backend, InputfieldColumnWidthFirst is applied to January and July as expected, but in my front end form, it is being applied to January and August which is messing up the two row layout that I'm after. My template code looks basically like this: $form = $modules->get('InputfieldForm'); $fields = $page->getInputfields(); foreach($fields as $f){ $form->append($f); } Is it possible this is a bug, or am I doing something wrong?

Diogo's code above taught me a lot and saved me lots of time, but I just noticed one tweak that I think should be made: foreach($mypage->fields as $f) { $mypage->set($f->name, $form->get($f->name)->value); } should really be: foreach($mypage->fields as $f) { if (!in_array($f->name, $myfields)){ $mypage->set($f->name, $form->get($f->name)->value); } } so as to avoid "Notice: Trying to get property of non-object" errors on any fields that were excluded. Also, I had to include: $mypage->of(false); // turn off output formatting before setting values $mypage->save(); I don't know whether this is something specific to my use, or whether it's just obvious and so wasn't included, but though it might help someone else.

Hi everyone - being new to PW I have had a few struggles working with the API. As an example, I was just trying to figure out how to get the Input field type (ie Checkboxes, Radios, AsmSelect etc) for a field. I couldn't find what I needed in the cheatsheet and was just about to give up and ask here, but it ocurred to me to look at the name of the select field within the admin where you actually choose the Input field type. It is named: "inputfield" which of course means you can simply do: $field->inputfield but I had tried $field->inputfieldtype and $field->InputFieldType which of course don't work. I think I'll be using this approach a lot for figuring things out from now on, but I though it might actually be helpful to put "inputfield" in parentheses after the title in the admin panel e.g Input field type ($field->inputfield) or something like that - kind of a contextual cheatsheet. Not sure if others think this would be useful

Thanks teppo - that helps a lot. This works: $inputfield = $question->getInputfield($page); $options_parent_id = $inputfield->parent_id; $options_parent = $pages->get($options_parent_id); $options = $options_parent->children(); foreach($options as $option){ But I have to admit to not understanding why I can't replace: $options_parent_id = $inputfield->parent_id; with: $options_parent = $inputfield->parent; and skip the next line altogether. Why do I need to get the id first and then get the page from that? Not sure if there is a more efficient way to do this.