ryan

I may be the starter of the project but there are lots of team members here. ProcessWire is everyone's project. We probably need to highlight that more on the site. You don't see collaborators in the GitHub tree simply because of the current workflow--I don't [yet] use GitHub to merge pull requests directly. As a result, collaborators don't show up in that tree, but are always highlighted in the commit notes. Regarding PHP compatibility: ProcessWire is already compatible with PHP 5.4. It's unlikely that newer versions of PHP would break ProcessWire, but if for some reason it did, we'd update it. We will soon be dropping support for PHP 5.2, so that we can take advantage of what PHP 5.3+ offers.

Also want to add that it's a pretty simple matter to take a theme (like a WordPress theme) and adapt it to ProcessWire.

For anyone else following this thread, Horst and I are collaborating on building a module for this, but the discussion moved to email.

Hehe, no magic here. Maybe you have a magic computer?

O'Reilly is having a pretty good e-book sale on PHP books: http://shop.oreilly.com/category/deals/php-owo.do?code=WKPHP

it is valid. Though you could also just specify $template (without the ->name). Any calls to a function that returns a PageArray (like $page->children(), $pages->find(), etc.) are going to exclude pages that are hidden, unpublished or otherwise inaccessible to the user. To make it include them, you can specify one of these: include=hidden -- includes hidden pages. check_access=0 -- Includes pages the user doesn't have view access, as a result of role permissions. include=all -- includes all pages with no restrictions.

This is a setting I don't use very often, as I find it kind of a pain. But others here like Soma are experts with it. If you search for TinyMCE and "styleselect" (one word) it should turn up some information on it. Here is another link that might be hepful: http://wiki.processwire.com/index.php/TinyMCE#Adding_Styles Basically, you create your own css file for TinyMCE and place it somewhere like /site/tinymce/custom.css. Then you edit your field, click on the "input" tab and open the fieldset for "TinyMCE custom/advanced settings". From there, you can specify a link to your custom css file. You would then add the styleselect option to your buttons. Also look into the Bramus CSS Extras TinyMCE plugin, which is mentioned in these forums often, as it improves what you can do here quite a bit .

You could go with simple text replacement. Lets say you wanted the icons in the body (though it wouldn't matter what field). You'd just instruct the client to visit this page and select the icon they want. That page shows both the icon and the name. You would have them copy the name and then paste it into their copy, wherever they wanted it to appear. Then in your template code, you'd run $page->body through something like this before outputting it: if(strpos($page->body, 'icon-') !== false) { $page->body = preg_replace('/\b(icon-[-a-z]+)\b', '<i class="$1"></i>', $page->body); } So if the client typed this: They'd get this in the markup (which would display the relevant icons): This would be another case where you could use simple text replacement before output: $page->body = str_replace("<h3>", "<h3 class='someclass'>", $page->body); Though if you needed to support different kinds of h3 tags or classes in that copy, then you'd probably want to use TinyMCE advanced settings to setup the 'styleselect' option. This would also be a good option: just targeting those specific h3's with a CSS selector. I think I'm going to go grab some icon-coffee.

You are basically getting the date of value "0". Double check that the timezone is a valid one. Double check that the field you are viewing has a value. Try entering it again.

We do provide hooks for adding any kind of additional server-side validation. But like Soma mentioned, the HTML5 pattern option may be adequate for typical admin input. While not present as an option on any fieldtypes at present, it is pretty easy to add directly in the DB. And I've left it that way just because the need is so rare, and easy to do when/if needed. You can just add a 'unique' index to the 'data' field in any field_* table. A good example: ALTER TABLE field_email ADD UNIQUE data_unique (data); I'm not 100% sure what you mean, so I'll cover a few possible answers: You can relate pages using the 'Page' fieldtype You can group two or more fields using the 'fieldset' or 'tab' fieldtypes You can concatenate the values of two or more fields using the 'concat' fieldtype This is what hooks are for (again, as already mentioned by Soma). Lots of fun possibilities here. Just let us know if you need help setting one up.

You can't put a repeater field inside another repeater field at present. Perhaps we'll be able to do that in the future, but I'm not yet sure how to support that. I did test it out at one point, but it seemed to be very problematic with some fieldtypes.

From an SEO standpoint, I think it's clear that you'd be making some compromises by putting everything on one page. It means less-specific pages in terms of content, so less likely to match specific keywords. But for a site that really benefits from being on one page, maybe those benefits outweigh the SEO aspect. I think that the more you focus on catering to what is right for your audience and content, the less SEO even matters. If you put up something that's going to drive quality incoming links, the value of those links is going to carry more weight than anything you compromised in structure. But seems like it'd be possible to also do it without compromises as well. You could build it as a multi-page site and then have the single-page nature derive from javascript ajax calls. Meaning, if you visit on a JS-capable browser, you get the progressively-enhanced version. If you visit on a non-JS browser, you get the multi-page version. Just so Google doesn't think you are trying to do some JS monkey business (if they can even tell?), you'd probably still want to make the multi-page version accessible to the enhanced version, perhaps via footer nav or sitemap link.

Do you mean Edward Tufte? I've got a couple of his books -- great stuff. That guy is serious!

I agree with Wanze. Using the API is the simplest way to go here. Actually this is exactly what I was doing yesterday... importing from a feed into repeaters. Though it was from an XML feed rather than from a CSV, but that doesn't make much difference.

I would bet that this web host is not reading the .htaccess file or does not support RewriteEngine. Put a bunch of junk characters at the top of your .htaccess file, like "alkjaefkjafjkef" and save. You should get a 500 error when you try to view anything on your site. That means it's working. If you don't get a 500 error, then your web host is not reading your .htaccess file and you need to ask them to fix it.

Sounds like it's an incomplete install or files are missing or unreadable somehow. Please remove all files from the installation and download a fresh copy from http://processwire.com/download/ and try again. Make sure you are using the default profile that comes with ProcessWire (just to rule out any profile-specific issues at first). Make sure that all tests pass on the installer's first [compatibility] screen. Please let us know how it works out. If it still doesn't work, also report your PHP version and if possible PM me a link to a PHP file containing: <?php phpinfo();

Horst, I think I can help with this. I don't think that XML feeds will apply since you are pulling from email and putting directly into ProcessWire (rather than Tumblr, where the XML feed is used). I think a PW site profile or module that essentially does this: "read image attachments from email and post to pages" would be pretty fantastic… I'd use it myself. It seems like you are already mostly there. Just spouting off ideas, which you may have already covered, but: Email sent to a confidential email address from a recognized sender's email (any other security necessary?) Create a new page in ProcessWire using a predefined template and parent. Use the email subject line as the 'title' of the page. Use the email body as the 'body' of the page. Add any image attachments to an 'images' field. I wanted to make sure I understood the code side of what you've already got. Is the source also available to these includes? require_once( dirname(__FILE__) . '/mime_parser.php' ); require_once( dirname(__FILE__) . '/rfc822_addresses.php' ); require_once( dirname(__FILE__) . '/pop3.php' ); require_once( dirname(__FILE__) . '/sasl.php' ); require_once( dirname(__FILE__) . '/hn_basic.class.php' ); require_once( dirname(__FILE__) . '/hn_picts.class.php' ); Also wanted to mention a typo: if( preg_match( '#^image/[jpeg|png|gif].*$#', $p['Headers']['content-type:'] )!==1 ) You want to replace the "[jpeg|png|gif]" with "(jpeg|png|gif)" -- basically replacing the square brackets with parenthesis. Otherwise, the regex is asking "Match any one of these characters: "jpegpnggif|". Whereas I think what what you wanted to ask is: match either "jpeg", "png" or "gif".

ProcessWire needs that screen, for the reasons mentioned in the thread JeffS linked. But automatically generated title and name fields in your case would mean your installation may not need it. So long as you understand that ProcessWire needs to have a page that exists in the DB before ProcessPageEdit operates on it, you can replace ProcessPageAdd with your own Process that does whatever you want. The way you go about it is to copy /wire/modules/Process/ProcessPageAdd/* to /site/modules/ProcessPageAddCustom/. Then rename the files in that new directory to reflect the directory name (i.e. ProcessPageAddCustom.module rather than ProcessPageAdd.module). Likewise, edit the module file and edit the class name to be the same. You now have a new module. In PW admin, go to Modules > Check for new modules. Click install for your new ProcessPageAddCustom module. Now edit the 'add' page in the admin by going to Pages > Admin > Pages > Add Page. Change the 'process' field from ProcessPageAdd to ProcessPageAddCustom. You are now in control of whatever happens on that 'add' screen. In your case, you may want to make your ProcessPageAddCustom.module auto-generate the page and then $session->redirect("../edit/?id=$page->id") to edit the page immediately.

Nico, what should the link on the main site say? I typed "ProcessWire German Site" into Google Translate and it gave me "ProcessWire deutsche Website" -- is that right? Or what is the best phrase/words to use here?

Well you've come to the right place, because a very high percentage of messages posted here have snippets of code. At least half of the messages I post have at least some code snippet. But we really try to focus on using code snippets to teach, and not so much for copy/paste. The reality is that ProcessWire is quite simple once you have a few basic concepts down. And once you've got them, you won't care about copy/paste, because you'll know how to do anything you could ever want. So our goal here is always to teach you how to fish rather than give you fish. That being said, there are no rules in that regard and all useful snippets are welcome.

@Nik: Thanks for testing testing and finding the bug. Attached is the file that fixes it. think this is close to ready to commit to the dev branch, so it'll be there soon too. FieldtypeFile.module It actually pulls it from the file system modification time (filemtime). But those probably end up being the same. I was thinking that the 'created' date would always reflect the date the file was added to the system, but the 'modified' date would reflect whenever a change was made to the description or tags. So I think this disconnect is probably okay, unless you can think of a situation where it would matter. I figured this makes sense, given that ProcessWire doesn't actually let you modify a file itself… so the 'modified' is really more about the meta data.

Thanks Soma, I've brought this in and just testing locally so it should be in the dev branch very soon.

It shouldn't matter in terms of performance. If your "name" is one you aren't going to be using again, then you should be totally fine to use it.

If include() works and include_once() doesn't, then it means the file was already included, so it got skipped the second time. The question is, when/where was it included?

I see what you mean. Row quantity really isn't a problem so long as the indexes are good. So I suspect even a single table would scale just fine. But if you still prefer a file-based storage option, using the existing $page->filesManager->path might be a good place to do it, as ProcessWire will maintain one directory per page (i.e. /site/assets/files/[id]/. You wouldn't want the version files to be publicly accessible, so you'd probably want to put them in filenames that PW prevents direct access to (like .php). Either of these seem like good options too. One table per field would be consistent with the way PW stores its fields... though that's for DB-related reasons that wouldn't apply to the case we are talking about. I guess the main benefit of splitting things into separate tables per field or fieldtype would just be to allow the possibility of versioning different data types. But your table with the single mediumtext column still allows for it, because all PW field data stored in the DB can be reduced to an array or JSON string: $data = $field->type->sleepValue($page, $field, $value); // convert to array $json = json_encode($data); // convert to JSON string Once it is stored as a string in the DB, then it's no longer "findable" except by possibly a fulltext index. But it seems like these versions probably would not need to have that search accessibility for storage anyway. I think you've got a lot of good ideas here. Though I'm not sure that you necessarily need anything more than what you've already got, with regards to data storage. From what I can tell, the data doesn't need to be selectable by anything in the data itself... just indexed attributes of the data: page_id, field_id, user_id, date. That combination would always be unique regardless of row quantity. It doesn't seem like you'd ever have to worry about potential for "full table scan" in MySQL. But there may be things I'm not thinking of. I haven't had my morning coffee yet. I do agree that splitting tables by fieldtype or field sounds better… but I don't know if it would ultimately matter. It would be interesting to take a table with 1m rows and a field_id index, and compare that to 10 tables with 100k rows and no field_id index. Assuming just straight selection from the table by page_id (no joins) and date-sorted results, would it make any difference? I have a feeling it would not, but haven't tried. But having it in one table you could select all field versions for a page in 1 query and your date-based maintenance could do its thing in 1 query. From a scalability standpoint, probably the only thing it would need there is just some limit on the number of versions it would load at once [25, 50, 100]? I'm assuming it doesn't load the actual version "text" here (it looked like you were doing that with ajax), but just the attributes. So maybe it would just need some kind of pagination or "older versions" link that loads the next block of [25, 50, or 100]. Either that, or you could just have version 1.0 say "we will store a maximum of 100 versions and no more", which would probably be fine for 99.9% of folks. No pagination worries. I think this is what the 37signals guys would say to do, at least for version 1.0.