ryan

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.

I'm using MAMP here, and I don't use vhosts... I just use subdirectories. So when I want to install a new PW, I do this: 1. Make a new database using MAMP's PhpMyAdmin. 2. Open a terminal window and go to htdocs dir: cd /Applications/MAMP/htdocs 3. Make a directory for your new site: mkdir new-site 4. git clone the latest PW into there: git clone git://github.com/ryancramerdesign/ProcessWire.git new-site 5. Load http://localhost:8888/new-site/ in your browser to complete the installation.

This is true, but I had to redirect processwire.net to processwire.com because Google was getting all up and in processwire.net and mixing it up with the main site. So if you want to preview processwire.net, you've got to login to the admin, otherwise it redirects you back to processwire.com. On this side, I'm finally getting some clear space on my desk after being overloaded on projects, so hoping to get this new site up with version 2.3.

Looks good to me! I will definitely use this for my next lightbox usage. Admittedly, I'm not sure I can swap out the one in PW with this one just yet because I know some people are using PW's FancyBox on the front-end of their site, and something like IE6/IE7 support might be needed there. So might want to wait for a larger release number to make a change like that. Though sooner or later we'll probably have to switch PW to use something more mobile friendly. Is this version of FancyBox more mobile friendly than the one we've got in place?

I tried it out here (with the German language pack) and found a notice being thrown with the parser (when in debug mode). I went ahead and fixed that, but kind of doubt this would prevent it from working since the parser is only involved in the interactive translation process. German seems to be working on the dev branch here. Just in case, do you want to try and grab the latest version of the dev branch and try again?

You might also find this post helpful, which shows how to build a profile editor on your front end.

Someone recently made a module that integrates with another image editing service. It looks like they never submitted it to the modules directory, and now I can't find it… I need to track it down, as I recall it worked quite well when I tested it.

Pete, I think I may have this fixed. Though couldn't exactly seem to duplicate it here, but found something that looks like it could be responsible (some missing parenthesis). Would you mind trying again with the latest dev version?

The problem here is that resizeThumb()'s implementation assumes that one can construct the server path to the file from the URL (see the first line in that function). But the URL and disk path can be very different things. You may be able to fix it by replacing the first line in that function with this: $thumb_path = $field->path() . basename($thumb_url);

While I still can't duplicate the issue, I did find discussion of there being an issue (on PHP.net) along with ways to resolve. I think I've got it fixed, but was wondering if you could test the latest dev, whenever you get the chance? I also have added some things to the SessionHandlerDB module, so you'll want to un-install and re-install the module before testing (couple fields were added to the DB table). Thanks for tracking down the issue.

I have a feeling this is something to do with a behavior change between 5.2 and 5.3, I will do some testing in 5.2. It sounds like PHP is trying to revert back to file-based sessions with that session_start() call, based on the error you mentioned.

If you are doing this in a template file, better to use some name other than $page, just so that you don't overwrite the $page provided to the template. $p = $pages->get('/about/'); if(!$p->id) { // create new page, if not already there $p = new Page(); $p->template = 'basic-page'; $p->parent = '/'; $p->name = 'about'; // URL name } $p->of(false); // turns off output formatting $p->title = 'About SwimToWin'; $p->save();

This is incredibly useful! It is a great security option to have for sure. Thanks for making this. Very nicely done.

I think that the problem did exist in 2.2.3. The current version is 2.2.9. I bet if you upgrade to it the issue will go away. Let me know how it works for you.

I think we all like to answer questions here, but especially like ones that are easy to answer.

Thanks for the nice feedback. Good suggestion. It's pretty readable here, but tried it on my wife's computer and it was a different case. I'll try changing this to Arial or something. Sort of. I evaluated the information architecture and researched other school sites and came to the conclusion that what they had on their previous site was quite nice in terms of organization. The problem was that it was navigationally bad, which made it hard to wade through. The old site had a design problem, not an architecture one. On the new site the information architecture (and even the exact URLs) are consistent with the previous site for the most part. But the new site makes the information a lot more accessible.

Pete, these updates are now in the FieldtypeComments for the dev branch. Please try it out and let me know how it works for you. I've also added a 'website' field option to the field settings. After you've updated, you'll want to edit your comments field(s) settings to enable the 'redirect after post' option.

That's kind of you to say. But the truth is ProcessWire makes me more productive. If I have to code something outside of ProcessWire, it takes a long time and I'm not that productive.

The user needs some kind of administrative access in order to access the PW admin. Just having page-view permission is not adequate permission to access anything in the admin. Otherwise, any random visitor to your site could go browse through the page tree in PW admin. Maybe that's not a problem per se, but I don't like the idea of it.

Sorry Marc, I'm guessing I wrote the wrong thing in some other thread. If you know what post that was, let me know and I'll correct it. Teppo's code is correct.