ryan

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.

Good idea for sure. But not very easy to implement at this stage. Will keep it on my mind though in case a solution presents itself.

Thanks for the follow-up here. Looks like you found a great way to handle this.

Glad the answer turned up! I was really confused about this one. I'm surprised that any web hosts would be using a MySQL version with this issue. It seems like this would affect almost anything that uses MySQL.

Don't worry about lack of time or resources - I personally use ProcessWire on all my client projects, so it's something I've been working on steadily for many years and will continue to. My business depends on it! Sometimes I get blocks of time where I can focus on it a lot, and other times I have to focus more on my client projects, but PW always moves forward because I use it almost all day every day. Though something I'd like to be able to do is less client work and more ProcessWire work. One thought that crossed my mind is to maintain another version called ProcessWire Pro (or something like that) that would basically be the same but include faster support by e-mail and several of my modules that I use in commercial projects. It might also include a separate support board geared for your clients, so they would also have a support resource should they ever need/want it. I was thinking something like this might appeal to the EE crowd that is looking for the guaranteed support and services beyond the typical open source project. The audience here would be the web designer/developer that does this for a living and wants something extra that they can't currently get from PW or other open source projects. But that in turn would help to open up more time for the project as a whole. Not everyone needs or wants this, but it might be nice to offer it for those that do.

I'm not sure I understand. Can you post a screenshot of the output that you get?

Jasper is right: it sounds like PHP/Apache doesn't have write access in your /site/assets/ dir.

If you want your events index to list all the categories, you could just do thi: $categories = $pages->find("template=category, sort=name"); foreach($categories as $c) echo "<p><a href='{$c->url}'>{$c->title}</a></p>"; If you want to use URL segments to filter the listing of events by category, you could use URL segments with a URL structure like /events/category/cheese/. Then your events index could look for it like this: if($input->urlSegment1 == 'category' && $input->urlSegment2) { $name = $sanitizer->pageName($input->urlSegment2); $category = $pages->get("template=category, name=$name"); if($category->id) { $events = $pages->find("template=event, categories=$category"); foreach($events as $event) echo "<p><a href='{$event->url}'>{$event->title}</a></p>"; } }