ryan

The file size shown for Sample.pptx is pretty large. You may need to bump up PHP's memory_limit. Can you tell what the memory limit is currently? One way to see it is to upload a PHP file to your server that has this: <?php phpinfo(); Then view the URL in your browser and locate the PHP ini settings. You should see a line that refers to memory limit. You want this to be 128 or higher. I have mine set at 256.

Looks good, thanks Nikola!

Taking the first example from the CrossSlide site, you could do it like this: <script type='text/javascript'> $(document).ready(function() { $('#placeholder').crossSlide({ sleep: 2, fade: 1 }, [ <?php $o = ''; foreach($page->images as $img) $o .= "{ src: '$img->url' },"; echo rtrim($o, ","); ?> ]); }); </script> I'm stuffing it into the variable $o before echoing it just so that I can trim off the trailing comma, which prevents a JS error in some browsers.

URL segments are a runtime thing that ProcessWire doesn't know anything about. It only knows where you want to allow URL segments, but not what they are or what you plan to do with them. It's up to you (in your templates) to look for the URL segments you want to act upon. Likewise, it's a best practice to throw Wire404Exception(); when your template gets a URL segment it doesn't recognize. If you want to avoid any possibility of there ever being a collision between a page name and a URL segment, then you wouldn't use URL segments on pages that had children where the URL segment names had potential similarity with the child names. However, I think it's okay to use them in the instance where you are because it seems like there is no chance for a real-world collision here. I would feel comfortable using the URL segment "category" in this instance just because it doesn't seem to be consistent with something that would ever be used as an article title (though that may be just me).

File uploads through public forms is where things can get dangerous if not handled really carefully. Adding email to the mix makes it even more so. When a client brings up this need, I always see if the need can be solved in some other fashion, like asking the user to email the file, or specify a URL, etc. I consider public file uploads kind of a last resort if nothing else will work, so generally avoid them when possible. Recognize that you will get viruses and exploit scripts sent to you through your public upload form (even if limiting it to images). Given that, it's important to make sure those files could never end up in a spot on the server where the user could access them by direct URL. It's also important to make sure that the client is prepared to deal with this sort of stuff. In terms of actual implementation, I think this may be outside the scope of what we can safely cover in full, but there are a lot of articles that include details of how to do this (search google for "file upload php email attachments"), such as this one at Sitepoint. Another option is to use Form Builder, which has page creation and safe file upload capabilities built-in. It doesn't email files, but it does email secured links to them (which is a more complex, but potentailly safer way to go vs. emailing the actual file).

Your selector looks good to me, assuming the repeater field is named rental_period. If it's not working, you may want to check what values you are providing to date_from and date_to, just to make sure they are either a unix timestamp or some other recognized date format string. Longer term, you'll probably want to be careful with repeaters for this particular purpose because it seems like quantities could grow quite large (over time) in terms of repeater items per property. You may want to setup an automated process to remove expired rental periods. I had a similar need when setting up a property availability system, but opted for a separate /properties/ and /reservations/ structure, where the /reservation/items each had page references to a /property/. So far this has worked well in the application where I'm using it.

I lose it here unless I copy the code out of the IPB editor (before message has been posted) and into a plain text editor, then paste it back. Once I post a message, I've lost the ability to alter the code without losing formatting. That's because IPB doesn't even retain the original formatting in the posted message (if there's any indentation). In some cases, I can copy the code out of the posted message into my editor, but this only works if there's not much or any indentation. It seems that IPB starts to exponentially magnify any indentation after the first tab (or 2 spaces). So unless I go back and redo all the indentation, IPB exponentially doubles the indentation yet again. :'( I actually keep dozens of text documents open with code samples I've written so that I can go back and re-paste them should I need to, but no longer had the one above. If you know of any tricks to avoid all this, I'd love to learn them. I anxiously await the day when the IPB developers fix these bugs.

You can do it if using Inputfields from the API, but not from Setup > Fields > some_checkbox_field. Though I'm not sure what you mean about a double negative. ProcessWire is designed to be friendly to schema changes. We assume that you are probably not defining everything you need ahead of time. As a result, it's preferable to use a checked checkbox field to alter a default behavior, not to enforce one. Lets say you have hundreds of pages using some template, and you decide to add a new checkbox field called enable_nav that you use to determine whether or not to show navigation on a page. You could say that you wanted that checkbox to be checked by default... great, but that only applies to pages created from this point forward. All your existing pages didn't have the field before, and are not checked. So now you have a new problem. Now consider the the alternative, which would be to make your checkbox do the opposite. Instead of calling it enable_nav, you call it disable_nav. Add it to your template, and your existing pages are kept in the proper default state. New pages created from this point forward will check a box to bypass a default state rather than enable one. Using this strategy scales well, enforces consistency and don't break existing systems when you add a new field.

It really depends on the server. This is a question for your hosting provider. In terms of ProcessWire, these particular permissions apply only to files in /site/assets/. The default permissions are going to work anywhere, but are not safe in shared environments that aren't completely jailed from one another. I don't know anything about your hosting environment, so can't suggest without more information. But one thing you can do is to test different permissions to find what will work. If 0700 for dirs and 0600 for files will work, that might be a good place to stay. But unless your server is using suexec, that won't work. If that doesn't work, see if 0755 for dirs and 0644 for files will work. This is a starting point, but you want to find the most secure solution for your server environment. The best way to check if something works is to create a page with a files field on it and upload a file. If the file upload does not work, then you've likely not found the right permissions. Once you have found the right permissions, make sure to go back and apply it to directories/files that already exist in /site/assets/, including the /site/assets/ directory itself. This is starting to sound like a good idea for a new module... The most common ProcessWire hosting environment is a dedicated one (server or VPS.) If that is also your environment, then you won't have to worry so much about locking down the permissions. But if you are using a low budget/shared hosting environment, then tweaking the permissions is definitely a good idea. Either way, your hosting provider will be the best to recommend what is right with their servers.

Here are some more recent 2.3 additions that are currently in the dev branch. This list is far from complete, but covers the more interesting ones: Admin Theme The default admin theme now handles long titles better. If you are editing a page with a really long title, it will dynamically reduce the size of the headline in the admin theme so that it can fit. After a certain point, if it still won't fit, then it will wrap it. If you try to make a headline as long as a paragraph, then you are on your own though. Inputfields Added the 'side-by-side' (inline) option to Checkboxes and Radios Inputfields. This lets you have them all display on one line, floated, rather than placed in columns. To do this, specify "1" for the optionColumns setting. Added ability for PageEditImageSelect to select images from within repeater fields on a page. Update InputfieldDatetime to support i18n jQuery UI translation files with the datepicker. TinyMCE: Add config option to ProcessPageEditImageSelect enabling you to turn off the population of width/height attributes in TinyMCE inserted images. This is desirable for responsive images. To configure this go to Modules > Process > Page Image Select. Sanitizer Added new $sanitizer->entities($str); method, which is the same thing as htmlentities($str, ENT_QUOTES, 'UTF-8'); Added $sanitizer->emailHeader($str); method that does what it says (sanitizes an email header). $sanitizer->url(); will now optionally accept query strings. Comments Fieldtype Add new 'redirect after post' option which makes the Comments form perform a redirect after a comment is submitted. This prevents the possibility of duplicate submissions and enables the user to see their posted comment immediately (when applicable). To enable, see the 'details' tab of your comments field. You can now search the contents of comments fields from $pages->find() selectors in the same way you search text fields. Example: $pages->find("comments*=some text"); Added new 'website' field option to comments fields. To enable, check the box in your comments field 'details' tab. Added Gravatar support to comments fields. To enable, select the Gravatar rating in your comments field 'details' tab. Added option to not send notifications to admin when comment is detected as spam. Some of us were getting dozens of emails a day from spam bots making the rounds through our sites, so this prevents that from annoying us. Added new gravatar() method to Comment class that returns the Gravatar image URL (this is a convenience for those implementing their own comment output). File and Image Fieldtypes Add new 'tags' option to FieldtypeFile. This gives you the option of specifying a 'tags' field with each file/image. From the API, you can then retrieve a files/images by tag using $page->files_field->getTag('some-tag') to retrieve first match or $page->files_field->findTag('some-tag') to retrieve all matching files. Previously you could only retrieve files/images by filename or index. You can also use "[field_name].tags=[tag_name]" in $pages->find() type selectors. To enable tags for any files/images field, see the checkbox on the field details tab. (Note that this also affects InputfieldFile, Pagefile, Pagefiles, FieldtypeImage, InputfieldImage, Pageimage, Pageimages). Add support for secured pagefiles. Now unpublished or non-public pages may have their files (in /site/assets/files/...) protected from direct URL access. For existing installations, you need to add $config->pagefileSecure = true; to your /site/config.php in order to enable this capability. See also $config->pagefileUrlPrefix and $config->fileContentTypes in /wire/config.php, if interested. Files become secured when the page is not accessible to the 'guest' role. Functions/Methods Add new methods to WireArray class: replace(), findRandom() and findRandomTimed(); Name of the last one may change to findRandomInterval before 2.3 is final. Add new wireRmdir() function, to go along with the existing wireMkdir(). The wireRmdir() function works the same as PHP's rmdir() except that you can specify a second boolean argument to make it recursive. This essentially results in a directory prune function that not just removes the directory, but everything in it, recursively. Be careful with this! Add new wireSendFile($filename); function that works as a file passthrough script. This is used by the new secured file functions, but also available for your use should you want it. Add new wireRelativeTimeStr("timestamp or date string"); function that provides a relative time string like "1 minute ago" or "10 hours ago" or "5 minutes from now" type string.

This is great -- thanks for making this translation! Nice to see a new translation here.

Thanks Netcarver. That's correct... I wrote it in the browser. I would go back and correct it but know I'll lose all the formatting. :-

Since there is a common problem between admin and front-end with the files missing extensions, that seems to indicate there is another factor at play beyond ProcessWire. What is the source of your upload script on the front-end? Is this self-built or something else? What 3rd party modules do you have installed?

Your PHP memory limit may be a factor. You might have it set to 32 or 64. I'd suggest bumping it up to 256.

For the Comments Manager (ProcessLatestComments) you could also drag its page out of the 'setup' menu and into the admin root. I actually kind of prefer the comments manager at the admin root level anyway, so that's what I've been doing here already. If the user doesn't have access to Fields/Templates then they shouldn't see the Setup menu anymore, once you get the Comments out of there.

Thanks Nikola! I will switch over to this one in the dev branch to test.

We force a non-www on processwire.com, but it seems that not many sites do that for whatever reason. If you want to do that, here's the code you can use in your htaccess (replacing processwire.com with your domain): RewriteCond %{HTTP_HOST} ^www\. RewriteRule ^(.*)$ http://processwire.com/$1 [R=301,L] This isn't technically part of ProcessWire's runtime configuration because the rules in the htaccess file are what ultimately gives control to ProcessWire (they are executed before ProcessWire is).

Thanks! That helped me to track it down. It should be fixed now in the latest commit to the dev branch.

No doubt if something can be built in WordPress, it can be built a whole lot better and more easily in ProcessWire. That's my opinion anyway. But as to the best approach here, I think a lot depends on these services that power all the data. I don't have enough background on those services and data to make informed statements about best strategies here. But I think there is at least a good chance that such a setup might be built out most easily as a site profile.

ProcessWire pages would definitely be the ideal data source here. In my case, I had to pull and cache from an outside service (Veracross).

I'm with Neil on Skeleton -- that's what I used on my last project, after some modifications. Skeleton is not really doing anything other than giving you the responsive grid and typography baseline that's more useful than a reset.css. This is nice if your need calls for a custom design without any influence by the framework. It's also very easy to modify Skeleton because the bulk of the layout customization is in one CSS file that's easy to follow. But it's up to you to provide anything else, so there's no image carousels, lightbox, dialogs, icons or any of that fun stuff you might get in other frameworks. So I've been keeping /site/templates/foundation/ and /site/templates/html-kickstart/ directories that have those frameworks, and selectively including elements from them too. On my most recent project, I used Skeleton as my base but combined it some of the useful widgets in Zurb Foundation and HTML Kickstart. This might sound kind of heavy-weight, but it's a lot lighter weight than using just 1 framework if you do it efficiently and only pull in the elements you want to use.

I'm still using VIM, but I'm going to be trying out PhpStorm and Sublime Text 2 over the next couple of months. Project load is getting lighter and I can experiment with stuff like this finally.

Do you mean you've got this figured out? Let me know if I can post an example of hooking before/after Pages::find?

There's really not much to it, as json_encode() and json_decode() built-in to PHP provide everything you need to go to/from an array to JSON. So the main thing you have to do is just provide the data to FullCalendar in the format it is looking for. Most of your work will just be translating the format that the events come to you in, to a format that is useful to FullCalendar. In my case, my calendar template looks something like below. This is not the actual code I'm using, but it gets across all the important parts. Note that the getEventById(), getEventsByDateRange() and renderEvent() functions referred to below are fictional functions that do exactly what they say. I don't know what your event data source is, so how those functions are implemented would depend entirely on where the data is actually coming from. So think of them as placeholders for your implementation. /site/templates/cal.php function eventsToJSON(array $events) { $items = array(); foreach($events as $event) { // translate events from some source to a format recognizable by fullCalendar $items[] = array( 'id' => $event['id'], 'title' => $event['description'], 'start' => "$event[start_date] $event[start_time]", 'end' => "$event[end_date] $event[end_time]", 'url' => "./$event[id]", // event ID is the url segment ); return json_encode($json); } if($input->urlSegment1) { // event ID provided as a URL segment to this page $event = getEventById((int) $input->urlSegment1); include("./head.inc"); echo renderEvent($event); include("./foot.inc"); } else if($config->ajax && $input->get->start && $input->get->end) { // fullCalendar making an ajax request of events $start = (int) $input->get->start; $end = (int) $input->get->end; $events = getEventsByDateRange($start, $end); echo eventsToJSON($events); } else { // display the calendar $config->scripts->add($config->urls->templates . 'scripts/fullcalendar/fullcalendar/fullcalendar.min.js'); $config->styles->add($config->urls->templates . 'scripts/fullcalendar/fullcalendar/fullcalendar.css'); $config->scripts->add($config->urls->templates . 'scripts/cal.js'); include("./head.inc"); echo "<div id='calendar'></div>"; include("./foot.inc"); } FullCalendar gets instantiated by javascript, something like this: /site/templates/scripts/cal.js $(document).ready(function() { $("#calendar").fullCalendar({ theme: false, editable: false, events: "./", defaultView: 'month', aspectRatio: 4, header: { left: 'today prev,next', center: 'title', right: 'month,basicWeek,basicDay' }, eventClick: function(event) { window.location.href(event.url); // or load it in a modal } }); });

There are some updates pending to the installer (most submitted by SiNNuT) so these will be going in here with version 2.3. The JSON support detection is just a matter of newer versions of PHP reporting it differently than what the installer is detecting. It's going got be changed to a method_exists() detection here shortly.