ryan

Also posted here: http://alternativeto.net/software/processwire/ And we could use some likes there. Though I guess the listing isn't yet officially approved, so not positive that link works yet (it does for me at least).

Don't worry, you aren't the first to ask. I plan to make a video demonstrating how to set this up.

You are half way there–next you have to assign that role to one or more templates. For the pages you want them to be able to edit and delete, locate the template(s) that are being used by those pages, click the 'access' tab, and define the access there.

Exactly–that's the issue. The alternate field doesn't do us much good just because that's for sending input back to the CMS to be saved, and we have no problem with that at present. The only issue is just in getting datepicker to output the selected date in the same format it does in PHP. While there are ways to solve it, none are particularly simple, and days(s) long projects for visual tweaks to the datepicker aren't at the highest priority at this stage (though eventually will be). If there was a simple solution I'd be all for it though.

The alternate field would be a great way to use some different format for input, but input isn't the problem… we're lucky to have strtotime() which can recognize nearly any known format. Instead, output produced by jQuery's datepicker is the problem. It needs us to specify a date format in a completely different way from PHP. To make it all work with the same format, both PHP's date() and jQuery's datepicker would have to recognize the same format for output. Because the two don't use the same format strings, the compromise was to just let jQuery's datepicker populate in a predefined format (ISO-8601 or another, it doesn't really matter which). I think that other CMSs resolve this by using predefined formats, and that may be the direction we eventually have to take.

I totally agree. But the jQuery dateformats are not the same as the PHP date formats. I don't want to have to ask the user to define the date in two different formats (PHP date, and jQuery datePicker format). If these two were the same, then that would be great, but they aren't: http://docs.jquery.com/UI/Datepicker/$.datepicker.formatDate http://www.php.net/manual/en/function.date.php The only way around it that I can see is to have something to translate one input format to another, or just offering predefined date formats. I decided it would be better to give the user the most flexibility by letting them use any date format, with the compromise of having the datepicker use it's own format. Let me know if you can think of any alternate way to do it. Note that the link I posted before was outlining formats that strtotime() can recognize for input (and there is similarity to the jQuery formats), but PHP doesn't recognize them for output (unless I've missed something), and we need the output formats to be the same. Input format doesn't matter too much since strtotime() recognizes near everything.

Ah I got it. Well I still need to try this when I'm back at my workstation. But even if just a fancybox-type thing, this same approach could be used for an embedded gallery. Is anyone offering such a service? New business idea!

See the note that accompanies the date input format in PW's field settings. It says this: What that means is that it has to be a format that PHP's strtotime() function understands. Meaning, you'll want to use dashes rather than slashes for d-m-Y. Here are the date formats strtotime understands: http://www.php.net/manual/en/datetime.formats.date.php As for the date picker populating the format Y-m-d, it does that because javascript (jQuery) and PHP don't use the same date format strings, so we have to use an ISO-standard date format for something that is automatically populated from a date picker. So we're using ISO-8601 (without time component) which is recognized in the same way by both JS and PHP. As soon as you hit save, it'll show you the date in your preferred format. So this all works, but there are those caveats. If you guys can think of a better way for us to do it, let me know.

Yeah I'm not sure why any web hosts would be using safe_mode when running PHP as an apache module, but it does point to possible issues at the host. However, I would like to find a way to make PW recognize and adapt to the situation if at all possible. Thankfully in PHP6 things like safe_mode and magic_quotes will be permanently gone.

Very cool 12345J, I'm thrilled to see you building these modules. I'm not familiar with the Galleria service, but just checked it out and it looks very interesting. If I understand correctly, this is kind of like a youtube embed, but for photo galleries? Some nice regex action in there – keep up the great work with these modules. While it's true that PW has good built in capabilities for building galleries and manipulating photos, I would also expect that a dedicated service like Galleria would probably offer some nice things that we don't. So this type of module may fill a niche that we aren't yet covering with PW. Galleria.loadTheme(\'modules/galleria/themes/classic/galleria.classic.min.js\'); That's a good point. I'm actually not sure how it's working at present because it looks like one would have to be in the /site/ dir in order for that path to work? When PW is rendering pages, it does a chdir() into /site/templates/, so I think the path above would technically be trying to access /site/templates/modules/?... (which doesn't exist). But I might be misunderstanding something about galleria or the module. 12345J how is this working at present?

Thanks I got your PM. The only thing I see as a possible issue in your phpinfo is that safe_mode is ON. I can't say as though I've come across a hosting environment with this turned on before. But my understanding of it is that if a server has safe_mode on, then the PHP script can't move/copy files unless it is the owner of those files. PHP appears to be running as an apache module rather than as a CGI on your server. So there is going to be some variation in permissions between your account and that of Apache. Usually not a problem at all, except when combined with safe_mode, that creates some headaches and could definitely interfere with file uploads. The first thing I want you to try is to create this directory and make it writable to all. Later on, once you know it's working, it'd be better to make it just writable to PHP (if you know what user it's running as). But if this is a dedicated server or the accounts are well jailed, then not a big deal. But for now create this directory and make it 777 (rwxrwxrwx): /site/assets/cache/uploads/ Then add this to your /site/config.php at the bottom: ini_set('upload_tmp_dir', $config->paths->cache . 'uploads/'); See if that resolves it. If not, the next thing to try is to see if your web host lets you create your own php.ini, or modify the php settings for your account. Many web hosts let you do this, but you might have to search around in their support docs. You will want to disable safe_mode, which can't be done at runtime with ini_set(). Let me know if you get to this point and I can help you figure it out. If none of those are an option, then I'd be willing to experiment on the server to find a solution if you don't mind giving me access temporarily. Btw, the site you have running on that server is gorgeous–beautiful design.

It's hard to tell because the conditions seem to be changing. It also sounds like session messages were appearing that aren't part of ProcessWire. It may be good to replace your /wire/ directory with one from a fresh download of ProcessWire 2.1. Though lets look at your phpinfo() first. That's good that the directory appears to be writable, but if your uploads aren't going there, then not good. If you want, PM me a link to your phpinfo() and I can have a look to see if there's anything about the server's configuration that might be causing a problem. To get the PHP info, just paste the following into your /test.php, and then send me the URL: <?php phpinfo();

That's unexpected. I have no idea what that would be. Doesn't sound like something coming from ProcessWire. I agree with everything Soma and 12345J said. When you get a "destinationPath is not writable" message, that only comes as a result of a permission issue. 12345J's suggestion was just to rule out the possibility that destinationPath isn't what we think it is for one reason or another, as well as to point out what the directory is so that we know what we're troubleshooting. But if you aren't even getting an error message when changing to his suggested code, that's a bit unusual. Why don't you just try changing it to this temporarily: if(!is_writable($this->destinationPath)) die($this->destinationPath . " is not writable"); That will halt execution and give you the message indicating exactly what directory isn't writable. Most likely there is a permission issue affecting the directory due to some change at the server or a site migration that didn't retain permissions. If you have shell access, a simple way to resolve it would be this: cd /your/web/root/ chmod -R og+rw ./site/assets If that doesn't do it, or you don't have shell access to do that, then I'd suggest creating a simple test script that you can use to help resolve it without having to upload an image every time. Place this in your web root in a file called test.php: /test.php: <?php if(is_writable('./site/assets/files/1/')) echo "Writable!"; else echo "NOT writable!"; If you know the ID of your page, replace the "1" in the path above with the ID of your page. For instance, ID 123 would be: ./site/assets/files/123/

If I'm understanding correctly, I don't think that you need that 'save' hook at all. Instead, you can just implement this function which is already part of the Fieldtype interface, and PW will call it only on the $page and $field that you expect: <?php public function ___savePageField(Page $page, Field $field) { if($page->isChanged($field->name)) { // your sendVideo code here - you should probably put it in a new function and call that function here } // since you aren't handling PW's DB save, let it do the rest: return parent::___savePageField($page, $field); } See this file which provides the full interface and functions that you can override in any Fieldtype: /wire/core/Fieldtype.php

Thanks–That's great! I look forward to it.

That's correct, the page is available only to those with edit access to it, and only by accessing it's URL directly. This is just so that you can preview it before publishing.

These Russian characters have been added in the latest commit.

Nice work 12345J You've gone from something very simple to something that I don't understand–a good thing when it comes to obfuscation. And it looks good! If you don't mind me asking, how does this work? I'm learning something new here, as I'd not seen create_function() before, but I'm intrigued by this. I'm sure I could figure it out by going through the code in more detail, but figure it might be good to include a brief summary of what it's doing in your module readme file for when we add to the directory (if you'd like me to). Also, how are you including the JS? I don't see any calls to include the JS. I'm guessing that one would include it manually from their template, but want to confirm? That's certainly a fine way to go. But in case you are interested, here are a couple ways to make it get included automatically: Add it to $config->scripts, like this: <?php $class = $this->className; $config->scripts->add($config->urls->$class . "$class.js"); When building sites, I recommend that developers include scripts (and styles) in this $config item in your own header include (or main template) so that modules can add scripts. So this is what developers would add to their sites, rather than individual links to specific scripts or stylesheets: <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; This is the method I use in my own sites, and this is also the method the PW admin uses. I think it's pretty handy because if I need a specific script or css file for a given template, I can just add it to those $config vars before including my header. For example, lets say I had a rotating feature on my homepage and wanted to include the jQuery cycle plugin to do it. Here's what the template might look like: /site/templates/home.php <?php $config->scripts->add($config->urls->templates . "scripts/jquery.cycle.lite.js"); $config->styles->add($config->urls->templates . "styles/home.css"); include("./head.inc"); // output homepage specific content and markup include("./foot.inc"); As handy as that is, it's ultimately up to the developer to decide whether they take that approach in their own templates. But I'm thinking we'll encourage people to do something like the above more and more in the future. That would make it easier for module developers to have a standard way of adding stylesheets and JS to site templates. Another method you can use that is not quite as pretty, but doesn't require the developer to do anything, is to add it to just do another string replace in your obfuscate() function. Add your script right before the closing </head> or </body> tag. i.e. <?php $class = $this->className; $url = $config->urls->$class . "$class.js"; $event->return = str_ireplace("</head>", "<script src='$url'></script>\n</head>", $event->return); This is probably the best way to go for simplest possible installation of a script into a unknown HTML output.

That move in the page tree refers to moving or sorting (they are synonyms in this context). Since your page can't be moved to another parent, it can only be moved within the same parent (aka sorted).

Use your title field for the term, and another field for the definition. For the parent of all these terms, set the default sort to be by 'title' on it's children tab. Then you'd code it something like this (below). I'll use a <dl> rather than a <ul> since a <dl> would be more semantically correct here. <?php function listDefinitions(PageArray $children) { $out = ''; $lastLetter = ''; foreach($children as $p) { $letter = strtoupper(substr($p->title, 0, 1)); if($letter != $lastLetter) { if($out) $out .= "</dl>"; $out .= "<h3>$letter</h3><dl>"; $lastLetter = $letter; } $out .= "<dt>{$p->title}</dt><dd>{$p->definition}</dd>"; } if($out) $out .= "</dl>"; return $out; } echo listDefinitions($page->children);

Good find Soma! It was a typo in the code, so the noSettings and noTrash were connected in a manner they shouldn't have been. Just fixed in the latest commit. Thanks!

Thanks guys, I could definitely use help testing. I didn't realize there were so many people wanting to do the upgrade, so I will try to get this finished sooner.

What's missing here is to move your file from $filetemp to $path + $filename. Once you've confirmed that the $filename is consistent with the format and extension you are expecting, and the size is consistent with a size you are willing to email, then you'll want to use PHP's move_uploaded_file($filetemp, $path . $filename) to the destination. If this is coming from a non-administrative upload form, you'll want your destination to be non web accessible. That means a directory off your /home/ or a directory blocked by apache. In a PW installation, everything is blocked from /site/assets/cache/, so that is a possibility. Here's how you might do it: <?php if(isset($_POST['submit']) && !empty($_FILES['file']['size'])) { $filename = $_FILES["file"]["name"]; $filetype = $_FILES["file"]["type"]; $filesize = $_FILES["file"]["size"]; $filetemp = $_FILES["file"]["tmp_name"]; if($filesize < 10) throw new Exception("File too small"); if($filesize > 1000000) throw new Exception("File too big"); $ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION)); if(!in_array($ext, array('jpg', 'gif', 'png'))) throw new Exception("Invalid file type"); $destination = $config->paths->cache . $user->name . '.' . $ext; if(!move_uploaded_file($filetemp, $destination)) throw new Exception("Unable to move uploaded file"); // fopen $destination and encode for your email // and remember to delete the file when done: unlink($destination); // then send your email } Written in the browser, so may need tweaks. Also, the messages posted this week from this thread may be helpful too: http://processwire.com/talk/index.php/topic,83.0.html

We could certainly add this and seems like a good idea. I'm not an expert with TinyMCE other than being familiar with some parts of it that I had to in order to make it work with PW. I do have plans to do more with it in the future, but it's admittedly not on the short term roadmap yet. If you want to take the lead on this I'll be glad to collaborate with you on it and we can get anything into the core that needs to be there to make it happen.

Ah I see what you mean. I think it's a good idea, but one I should probably leave for another theme developer. I'm admittedly not a fan of the plus/minus for opening/closing things just because I don't have the best eyes and those things are always too darn small for me to use effectively. But I do understand why others may like the ability to open/close children as being something separate from open/close page actions. And I would guess that it won't be long before we see a theme that does that. With regard to borders in the PageList: many of the sites I work on have thousands of pages and so the default theme is kind of designed around my own needs to be as minimal as possible when it comes to displaying page information. Extra borders and such are nice separators on small sites, but get in the way (for me at least) as the scale of pages increases. But perhaps I can make a variation of the default admin theme at some point in the future that incorporates things that others may prefer.