ryan

The contact link was moved to the footer on the main site. But the forum template is different and so the contact link remains up there for now. We will get it more consistent when we launch the new site design.

Always happy to hear about a new language pack! You are correct -- start a new thread with the subject like this example: "English (en-US)" in the forum Soma linked to. Let me know if I can be of any help.

Got it setup here: http://wiki.processwire.com Nothing there yet but a blank MediaWiki. The access to it should be wide open, so Nico and anyone that wants to experiment, have at it. Let me know anything I can do or setup on this end. Thanks, Ryan

You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon. Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs. As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder. A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder. As an example, here's the PHP array schema for my test form: $formArray = array( 'personal_info' => array( 'type' => 'Fieldset', 'label' => 'Personal Information', 'children' => array( 'first_name' => array( 'type' => 'Text', 'label' => "First Name", 'columnWidth' => 50, 'required' => true, ), 'last_name' => array( 'type' => 'Text', 'label' => "Last Name", 'columnWidth' => 50, 'required' => true ), 'email' => array( 'type' => 'Email', 'label' => "Your Email", 'columnWidth' => 50, 'required' => true ), 'phone' => array( 'type' => 'Text', 'label' => "Your Phone", 'columnWidth' => 50, 'required' => true ) ) ), 'customer_feedback' => array( 'type' => 'Fieldset', 'label' => 'Share Your Feedback', 'children' => array( 'store_location' => array( 'type' => 'Select', 'label' => 'What store location did you visit?', 'options' => array( 'ATL' => 'Atlanta, GA', 'CHI' => 'Chicago, IL', 'NYC' => 'New York, NY', 'SFO' => 'San Francisco, CA' ) ), 'would_visit_again' => array( 'type' => 'Radios', 'label' => 'Would you visit that location again?', 'options' => array( 'Y' => 'Yes I would', 'N' => 'No I would not' ) ), 'comments' => array( 'type' => 'Textarea', 'label' => 'Comments or Questions?', 'description' => "We'll respond right away!", 'rows' => 5 ) ) ), 'submit' => array( 'type' => 'Submit', 'value' => 'Submit Your Feedback!' ) ); That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like: $form = arrayToForm($formArray); if($form->isSubmitted()) { $body = "<html><body>" . $form->renderValues() . "</body></html>"; $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value; mail('me@domain.com', 'Form Submission', $body, $headers); echo "<h2>Thanks, your form was submitted!</h2>"; } else if(count($form->getErrors()) { echo "<h2>Fix the fields in red and try again.</h2>"; echo $form->render(); } else { echo $form->render(); } That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it. Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).

Sounds like you are on the right track with this Marc. I think PW should be a great way to construct a family tree. I agree that a Page reference would be the best way to identify any relations that don't follow the parent-child structure.

Edit your new template and click the 'import' tab. Then click to import from the 'admin' template. That will copy the process field to your template.

Great update! Thanks Netcarver! I look forward to updating the PW Textile module with 2.4 and am now using this version locally.

Another way to do it, just using PHP string functions: $out = "<ul>"; foreach($parents as $parent) { $out .= "<li><a href='{$parent->url}'>{$parent->title}</a></li>!"; } $out = str_replace('</li>!', '></li>', rtrim($out, '!')) . '</ul>';

Great! Glad that fixed it. Thanks to both of you for reporting back on the solutions.

Lars282, apeisa is right -- it looks like you have a version that's a few months old. If you put in the latest, you should see the extra field because it was added recently.

Edit any textarea field using TinyMCE. In the field editor, click the Input tab, then click 'TinyMCE Advanced Configuration Options'. Note the last field labeled 'Additional TinyMCE Settings'.

If you are displaying categories and want to exclude any that don't have any events attached, then you could do this: $categories = $pages->find("template=category"); foreach($categories as $category) { $numEvents = $pages->count("template=event, categories=$category"); if($numEvents > 0) { // display category } else { // don't display category } }

Just to confirm, it always shows the homepage? I wasn't sure because you said it won't show any PW pages, but that it displays the index.php file if you try to go to any page. I'm assuming that means it's showing the homepage, but if you mean it's literally showing the index.php file (the text of it) then that's a very different problem. Assuming you see the homepage at every URL, it sounds like apache rewrite engine is not working. You'll want to double check that your /.htaccess file is in your site root. Check the bottom and top of that file, as well as /index.php to make sure some WordPress exploit hasn't attempted to modify these. Assuming nothing has modified those files, you'd need to find out why Apache rewrite engine isn't working, or if it's completely bypassing your .htaccess file. To determine if your htaccess file is getting bypassed, edit it and enter some random characters at the very top of it, like "alekjfalkjfalefjk". Save, and try to load a page. You should get a 500 http error. If you don't, then Apache isn't reading your .htaccess, and it's a question for the web host. If you find that you did get the expected 500 error, then change it back to a working state and post back here so we can look at more.

Here's another way you could go: $siblings = $page->siblings('publish_date<' . time()); if(($prev = $page->prev($siblings)) && $prev->id) echo "..."; if(($next = $page->next($siblings)) && $next->id) echo "...";

What errors did you get from the first screen on the installer? That's the screen where it checks system compatibility and show all green boxes if everything checks out. I'm wondering if you had any red or yellow boxes? If you'd like PM me a link to a PHP file containing this on your server: <?php phpinfo();

That additional settings field is where you can specify any additional TinyMCE settings that PW doesn't have dedicated config options for. These are the TinyMCE settings it's referring to: http://www.tinymce.com/wiki.php/Configuration So you could put this one one line in that additional settings field, as an example of specifying the theme_advanced_styles option in TinyMCE: theme_advanced_styles:Header 1=header1;Header 2=header2;Header 3=header3;Table Row=tableRow1

You are right, quite a lot in it. It could have just as easily been a couple of versions, and maybe should have been. But I'm mostly focused on just getting stuff in there that's needed, when needed, and version numbers are secondary. But I'm feeling pretty good about where the multi language support is in stability, and once the repeater/clone issue is resolved, should be able to make 2.2 more official. We already have this (Edit Field > Advanced > Duplicate/Clone). When it comes to a form builder, I think long term we'll do great things here. Short term (v2.3), maybe we should have a relatively simple built-in contact form module, just so solve the simple/common needs.

Thanks for finding that Diogo. It looks like it was not yet multi-site aware. I have just updated it so that it should be now.

Thanks for the testing netcarver and stillmoving design. Looks like I can set this with the jQuery UI datepicker 'yearRange' option. Though I'm wary about getting too many configuration options with the field, unless it's something everyone will use. Good point though, this may be one to have... JS/jQuery datepicker is working with the timestamp in seconds * 1000, whereas PHP isn't. I did the conversion on the front-end (passing value in ms), but neglected to on the submitted value. So that's a bug-- thanks for finding it. But it brings up something else. Rather than adding code for this exception, I'm really wondering if there's any point in having a unix timestamp for this field. After all, the unix timestamp is always available since PW keeps it in memory as a timestamp regardless of what date format you choose... converting from timestamp to formatted date is part of runtime output formatting. And a timestamp is always acceptable as input from the API. So the whole purpose of the date/time format and date/time picker is so that you don't have to see/use a timestamp. As a result, I'm thinking perhaps I should remove the timestamp option, unless anyone can think of a reason to keep it. The question is why I put it there in the first place.

I've still got to get the account setup. Sorry for the delay. I ended up working on that datetime fieldtype/inputfield with what extra time I had, because I got fed up with the old one. I'll get this account setup within the next day here hopefully.

Thanks for the feedback Netcarver! I think the jQuery UI standard for stretching groups of years is to select the first/last year, and then it should extend the list. I'm on mobile now, so can't easily confirm yet, but I think that's how it works if I recall correctly. I will try with dates before unix epoch. I haven't tried before 1970 yet, but should support them with negative numbers, but not positive about the jQuery stuff and how far their support goes. Good find--I will test Monday. As for April 8th--I needed a date that would demonstrate the difference between zero padded vs. not. Anything above 9 prevents me from doing that. Plus 4/8 is my daughter's birthday. It's a date that worked for both months and days in leading zeros vs not. Still I agree about some ambiguity there, but at least all the info is there to figure it out. We may have to ultimately show two date samples to maximize clarity. Thanks again for helping me to test this!

The current core date/time fieldtype/inputfield in ProcessWire has been a little weak, and there are some issues when it comes to using the datepicker. I've been working on fixing all of these and really upgrading the datetime fieldtype and inputfield to be much stronger. However, I need some help testing before a commit to the core source. I would just put it on a dev branch, but know that not many people will try it that way, so figured this would be better to post here. The file is attached. To install, you'd replace the existing files... /wire/modules/Fieldtype/FieldtypeDatetime.module /wire/modules/Inputfield/InputfieldDatetime/ (entire directory) ...with the new ones here: <attachment removed> Here's what's new: You can now select from predefined date and/or time formats, rather than having to manually construct a PHP date format (though you can still do that too if you want to). It converts your date format to the equivalent javascript format, so when you select a date from the datepicker, it stays in the right format rather than changing to a YYYY-MM-DD format like that old one did. No more conversion issues with day-first vs. month-first dates and the datepicker. There is now a time picker too! If you opt to include a time component, the datepicker will include a timepicker. You can now choose when you want your datepicker to appear: on click (as before), on focus (new), or inline (new, always visible). You can now optionally specify alternate date/time output and input formats on a per-language basis. So if you need month-first dates for US users, and day-first dates for European users, no problem. For the date output format, you can use PHP strftime() codes if you want to. This enables you to have one date format that outputs language-specific/localized month or day names. Though if you don't need to output localized month/day names, then it's better to stick with the default date formats. If anyone gets a chance to try it, please let me know how it works for you and if you run into any issues. There is a lot of new and somewhat complex code in here, so it needs a good testing. I've been testing here, but know with something like this there are some scenarios I could miss. Once we've confirmed all is stable, I'll commit this to the core. Thanks, Ryan Date/time picker example: Fieldtype configuration example: Inputfield configuration example:

It also depends what version you are upgrading from. Upgrading within the same major version (like 2.2) means just replacing the /wire/ directory, /index.php and /.htaccess file. But going from something like 2.0 to 2.2 or 2.1 to 2.2 means you have to check the upgrade notes before attempting an upgrade. However, currently the only upgrade you need to be careful with is 2.0 to 2.2, as that one involves more. I've not heard of something like this before. Just to be on the safe side, I suggest hitting "reload" in your browser once or twice, as it sounds like a possible CSS cache, rather than an upgrade error. If that doesn't do it, let me know what version you upgraded from. I'm assuming you were previously running at least 2.1 Though if not, you need to revert and follow the 2.0->2.1 upgrade instructions. Currently, that is the only version change that requires something more than replacing a few files.

In the WP example, they are getting the DB by making $wpdb a global. In ProcessWire, you'll want to access the database with wire('db'). So you could do something like this: function bb2_db_escape($string) { return wire('db')->escape_string($string); } or this function bb2_db_escape($string) { $db = wire('db'); return $db->escape_string($string); } I don't know what DB library/client WordPress is using, but ProcessWire is using PHP MySQLi. So when you reference wire('db'), you are actually referencing a PHP mysqli object. http://php.net/manual/en/book.mysqli.php I am guessing that if there were any other ready-to-go bad-behavior-generic files from another CMS that also used mysqli, the implementation would be nearly identical. Please let us know what you find.

The form builder probably won't be part of it, but the history module will (and already a good start with that). For the form builder, I've either got to wait till I get a bunch of time off work to do it, a client wants it and is willing to subsidize it, or we get a sponsor for it. So it's something I definitely see us getting eventually, but probably shouldn't nail it down to a version. I'm also really interested to see where Netcarver's form builder is going and see if there's collaboration potential there. I've wanted to wait to officially announce 2.2 till language and repeater functions were bulletproof. But I've been fixing minor issues in both as recently as this week, so feel like I need to have at least a week of no issues coming up before we'd consider 2.2 ready for announcement. I still also need to resolve the repeater / page clone issue. 2.3 will likely follow 2.2's announcement by 2 months, so likely sometime this summer.