adrian

Just discovered a weird bug - If you have more than one page of admin users and you are viewing any page but the first, the latest updates section in the sidebar also shows results from page x of its results. Not sure if this is a general PW bug or something specific to this theme. How does PW generally handle pagination when there are two things on a page that both allow pagination? I haven't come across this scenario before. Anyone?

I wonder if you don't have the Textarea (Multi-language) module installed. It is a core module, but not installed by default. The other thing to try when migrating to new servers is to do a test install (in addition to copying the folders across) so the installer requirement checks are run.

Thanks Ryan, but the 404 page is/was not viewable by the user, so I don't see how they could have changed it. The page they edited the name of also disappeared from the page tree and all the content was actually in the page with ID of 27, including all the uploaded images - which actually even ended up in assets/files/27. I am baffled how that could happen, but it did

Awesome diogo - thanks for the quick fix - sorry i didn't think to look there last night - was too late

Just used this for the first time - so easy! I am using 1.04 with the latest dev (as of today) Thought everything was working great, but then when I went to test to see if general admin users could see it, I discovered that they could see the new page just below "Access", but then when I clicked on it, I get a "You don't have permission" error. I have looked through all the permission options I can think of and can't seem to get it working. Any thoughts please?

Ok, here is a very weird one. Just had an admin user change the name of a page (direct child of Home) to "Contribute" from something else. Not sure that the new name is relevant. Somehow this page then took an ID of 27 which is the ID of the 404 Page Not Found page. It was set to hidden and the template was changed to basic-page. The page can't be viewed by non-superusers. As a superuser, I can't delete it, or even move it's position in the page tree (it moves, but the change doesn't stick). The person thinks they were using the main admin, but I do have the Admin Bar installed, so I wonder if this might be involved. Anyone have any ideas on this? By the way - I managed to clean things up via PHPMyAdmin to change the ID of the page and everything is working fine again, but it does seem like there might be a bug somewhere.

Hi Mike, Apeisa has this module: http://modules.processwire.com/modules/fieldtype-poll/ I haven't used that, but I have used the following code from Ryan successfully for a couple of polls and it works great: http://processwire.com/talk/topic/218-simple-poll/?p=1456 Hope that helps.

As far as I know, all it does is add the "_END" to the name of the field, which is what is required to define the end of a fieldset. Although I did try manually adding it and it didn't work, but maybe I had something else messed up at the time.

Soma - thanks muchly for the point in the right direction - it was the FieldtypeFieldsetOpen::fieldsetCloseIdentifier; that I was missing. Everything seems to be working great now!

I can create the FieldtypeFieldsetOpen no problem, but can't figure out how to create the FieldtypeFieldsetClose. It doesn't seem to be automatic like it is via the admin and I can't seem to create it manually either. I imagine automatic wouldn't work because it wouldn't know what fields belong inside the set. I have created the required fieldset using InputfieldFieldset and the layout looks ok until I want a second fieldset in the same template - then the need for the Close / _END field becomes important. Anyone have any ideas? PS I have been using this example as a starting point for generating the fieldsets: http://processwire.com/talk/topic/1196-api-show-field-label/?p=10691 but without defining a FieldtypeFieldsetOpen it doesn't really seem to do what I want in that nothing gets grouped in the admin.

I actually don't know what you mean by the "reply" or "another reply" links - I only have the submit button. Can you attach a screenshot of the links you are clicking on and then the url of the page that produces the 404 error, as well as describing the page tree that you see when you browse the forum posts in the admin. I am sure we can figure it out from there.

Did you create all the required .php template files, as per these instructions? http://processwire.com/talk/topic/572-release-discussions/ I have used this in a couple of sites without problems, so as horst says, it should be an easy fix to get this working. Whether it suits your needs is another story - it is a very basic (but effective) forum. Actual proper user integration with other forum software will be much more complicated. You could potentially install some and style to match your PW site though with less effort. Here is a recent thread that might want to start following as Pete is looking to possibly build some forum integration: http://processwire.com/talk/topic/3536-forum-integration-module/

The search.php file that comes with the default profile includes the following line: $matches = $pages->find("title|body|sidebar~=$q, limit=50"); That error suggests to me that you don't have the sidebar field in any of your templates, so you should remove "|sidebar" from the search.php file and I think you should be fine.

I think this should do what you are looking for: $pages->find('created_users_id=n'); where n equals the id of the user you are looking for. If you are searching for the currently logged in user, you could replace this with $user->id PS, Welcome to PW!

If you look at the bottom of the link that Wanze pointed you to, you'll see the "Allow new pages to be created from field" option. So long as that is checked, then yes, you can create new ingredients on the fly from the field in your recipe page.

Hi Ty, Welcome to PW. I haven't used either of those modules, so I might be totally off here, but I wonder if the FormTemplateProcessor is incompatible with the Select Fieldtype module. Not sure if you have read about Page fields: http://wiki.processwire.com/index.php/Page_Field At first it may seem like more work, but there are lots of advantages to created selects like this, rather than using the select module. Please try that and let us know how you go. Also, it would be useful if you show us your template code so we can see how you are initiating the FTP module. Perhaps someone else who has used both together might be able to chime in with a solution. EDIT: Apparently I should have looked a how the select module actually works - thanks Soma

No problem - most of us find that google does a better job searching this forum than the IP.Board search tool. In case you are not familiar with google site search: site:processwire.com/talk "search term"

Is this what you are looking for: http://processwire.com/talk/topic/519-pagelistselect-issue/

Hey Soma - sorry for the confusion - I just wasn't sure if this comment: "Without further consideration on if what you do is really a good way to go building forms" was directed at the approach I had proposed, or Peter's approach to his current problem. Sorry, I don't think I ever saw that post of yours on creating simple forms using the API - I'll have to start sending people to that!

Hey Soma, You've probably noticed that I have been pointing several people to that form code from diogo Are you suggesting that you don't like that approach? It has been working great for me - makes form generation so simple. I am sure Ryan's form builder is amazing, but so far I have been able to do everything I need with this approach. Do you think I should stop suggesting it?

Stolen from the blog profile. This will get all events for the month of May, 2013 $firstDay = strtotime("2013-05-01"); $lastDay = strtotime("+1 month", $firstDay)-1; $events = wire('pages')->find("template=event, date>=$firstDay, date<=$lastDay, sort=-date"); The rest of it is in the archives.php template.

Oh I see - sorry for misunderstanding on the ProForm. I do think you could easily change the layout by using the class attr, but maybe I am still missing your point. Of course if you match the layout in the backend using the Input -> Column Width (to make your 4 columns) - that layout will be mirrored on the front-end using diogo's code. Different CSS styles for the inputfield classes on the front end could easily change the look too. Not sure if this helps or not, but I have also done the following before. Please keep in mind that this is only partial code, but hopefully it gives you an idea of the approach I am talking about. It still relies on the InputfieldForm, but lets you iterate through each field separately. $questions = $page->fields; //Option type fields (select, checkbox, radio etc) if($question->type == 'FieldtypePage'){ $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){ $form->append($field); } } Maybe someone else has a better approach!

It doesn't require Ryan's pro form module, if that's what you mean. InputfieldForm is part of the PW core. A couple of options for styling the form. You could use jquery, or you can simply add a class to each field as it gets appended to the $form. See bold line below. if ($myfields){ foreach($fields as $f){ // Output all the fields minus the ones listed in the $myfields array // Instead, to output only the fields that are in the array, remove the (!) from the condition if (!in_array($f->name, $myfields)){ $f->attr('class', 'mycssclass'); $form->append($f); } } } Of course you could nest some conditional statements in here to apply different styles to different field types. Does that take care of what you need to do?

Hi Peter, Have have had lots of success using this code from diogo as a starting point: http://processwire.com/talk/topic/59-module-want-form-builder/?p=11639 This takes care of formatting the form inputs to match the field type in the back end. I think this will do what you need if I have understood you correctly. There is a comment further down that page from myself that might also help.

I am using that script of Ryan's on a site without any problems, but it is using an older version of PW, so perhaps it is a new bug.