ryan

Minor typo in my prev example, it should be if(strlen($value) < 4) unset(...

We could use a favicon, and I've actually been working on an icon of sorts, but havent settled in it yet. For variation of admin/site/theme design, I'm relying on the community to build new admin themes and Soma has built a nice one called teflon that you may want to check out. Over time I'm sure more variation will continue to evolve throughout. With languages I was meaning to use the terms coder and developer synonymously. When you want to investigate a language, tune out the noise and then look at what's been built with it. Folks who get hung up on languages are not the ones who make things happen. So if somebody is really defensive about their language choice, be that Ruby, PHP, Python, etc., don't listen to that person. Likewise if they are condeming about someone else's language choice, don't listen to that person. Instead, go and code--build something cool or make something happen. And let the amateurs debate languages. Ultimately it's the coder that matters. When a coder doesn't matter, they must compensate by becoming a language critic. Glad you like the name ProcessWire. I like it too. So that makes at least two of us

I'm wondering if it was the browser cache? That's the only thing I can figure. Though i regularly use the same filenames and haven't run into that before, but will try here again. Are you using PW 2.0 or 2.1? And what web browser?

PW already removes stopwords from the query (and I think that "by" is one of them). Take a look at the %= operator as that works the same as *= but has no stopword or length limitations (at the expense of being slower). But using Adam's example (which is a good one), you could recode that array_walk part like this: foreach($queryArray as $key => $value) { if(strlen($value < 4)) unset($queryArray[$key]); } I've never used array_walk before, and dont know what the error you got is, but I think the above would do the same thing.

Edit your /site/config.php and locate the line that says $config->advanced = false; Change it to true. Now when editing our template, you'll see a "system" tab. Click on that tab and check the box that says to show the name field on the content tab. Save. Your name field should now show on the content tab for pages using that template. You don't want to keep $config->advanced on as it's meant for PW core/system development rather than regular development, and it can get you in trouble (I always keep it off unless I need something in it temporarily). So go back immediately and edit your /site/config.php and set advanced back to false.

Welcome to the forums! Absolutely, I think you will find PW extremely flexible in this area. Any page can call upon any other page's content as easily as it's own. See these: http://processwire.com/api/templates/ http://processwire.com/api/variables/pages/ http://processwire.com/api/selectors/ Yes, yes and yes. The system is very secure. For the same reason, features like user registration are left up to you. A fresh install of PW is not setup as a forum or blog style community-driven site. But it is a great foundation for building such a site. However, a CMS like Drupal is more focused in these specific items and if your needs are centered on those things it is worth looking at too. You are in full control of the markup and stylesheets, so the answer is absolutely yes. Same answer as above. You are in full control of the markup/output. From an SEO standpoint, this means there are no limitations and PW really supports the needs of professional SEOs. For someone that really knows their way around SEO, ProcessWire is hard to beat. But for someone that knows little about SEO, ProcessWire isn't going to fill the gaps either. While you can do this in PW, those that can edit their profiles are assumed to be administrative users of some sort. PW is not setup on the front end as a login/user community, although it's a great foundation for one. But you'll have to code more than you would in markup generator CMSs like Drupal. PW is part CMS and part framework. The features you are talking about ready-to-go are more common to a non-framework, markup-generating CMS. For non-major versions, it is very simple. For most upgrades, it is a matter of typing "git pull". If your site isn't version controlled with git, then it's just a matter of downloading the latest ProcessWire version and replacing your entire /wire/ directory with the one from the latest version's ZIP. All of your site specific files are stored under /site/, so your files don't get touched during an upgrade. So the short answer is that all you have to do is replace one directory, and your site is upgraded. PW's API can make this a whole lot easier than other CMSs. There is also the ImportPagesCSV module which can be handy for some types of imports too.

Mickaël, thanks for our feedback and welcome to the forums. Good question, and there are so many reasons. PHP (5) is the language I enjoy using the most and fits my style better than the others. PHP doesn't step over boundaries I don't want it to, and it leaves me in control in the places where I want it to. Some people dislike PHP for these very same reasons, and beginners can get in trouble because of them. There are those that find languages like Python and Ruby ideal for them, and I think that's great (I rather like those languages too). But ultimately they are looking for different things than I am. PHP is perfectly balanced for our projects and allows us to get stuff done fast … more results, less chatter. Other factors are that I come from a background in C/C++ and always liked the syntactic and naming similarities. I also like PHP's balance of similarities (and differences) with Javascript. PHP has been used at a larger scale online than any other language I know of, powering the world's busiest site and serving as the backbone for several other of the world's busiest sites. PHP has proven it's scalability and strength in real life like no other language. Lastly, an open source project written in PHP will have the opportunity to spread farther, run on more servers and get more use than those written in other languages. Most truly experienced developers realize that languages really don't matter, coders do. But if you are building an open source project, it does matter … no other language can approach PHP's availability and adoption rate: factors that matter quite a lot for open source. PHP is a great language all around and even if you remove all the other factors, I just plain love using it.

Soma, this looks like it might be exactly what we need. Thanks for your efforts in putting this together. I'm offline for the holiday weekend but will get this working with the date inputfield early next week. Thanks again.

Thanks Pete–that's great!

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.