ryan

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.

Thanks for your continued updates to this translation pack. I think this is the most complete translation pack available! I have made the text in the Comments modules translatable, and am just doing a little more testing here before pushing to the source. But they should be there soon.

Is this site ready to announce and link from the main site? Let me know when...

@apeisa did you get a chance to try this one out?

Wanze, the latest commit should fix that bug.

How about: "Using URL segments to disconnect presentation URL from structure URL" or just "Real-world URL segments example" I'm not sure breadcrumbs need to be here, as that gets into specific implementations and not every site uses breadcrumbs. An individual's solution would just be to make the breadcrumb generation code aware of URL segments. // $page lives in /products/ and we want to show it in /categories/[first-cat]/product/ if($page->template == 'product') { // we need to base our breadcrumbs off some other page $parent = $page->categories->first(); // where categories is a page reference field held by product pages $parents = $parent->parents->prepend($parent); } else { $parents = $page->parents(); } // generate breadcrumbs foreach($parents as $parent) { // ... }

I'll assume you are logged in as superuser, just to rule out the possibility this is the result of access control. Check the template used by 'subpage' (Setup > Templates > that-template). Click the "family" tab. Make sure that template is allowing children. The lack of a "new" link would usually indicate the template doesn't allow new children, or that the allowed child templates have some setting on their Family tab that prevents them from being utilized there. Let me know if it still appears incorrect after reviewing those family settings? If so, try editing "subpage" and clicking the "children" tab. Do you have an "Add New Page" button?

$pages->get("name=mypage"); isn't a very reliable thing to do just because that query is within the scope of your entire site. Page names are only guaranteed to be unique within the same parent. So you'd be much better off doing one of these instead, which would be guaranteed unique: $pages->get("/path/to/mypage/") ... // retrieve by page path $pages->get(123) ... // retrieve by page ID Since the 'name' is guaranteed to be unique within the same parent, it would be perfectly fine to do this though, where $page is some page with children: $page->child("name=mypage")

Joss, that example you put in there is comprehensive enough that it probably belongs on it's own page in the Wiki. Thanks for putting it together. It's a rather nice tutorial in its own right. Is it possible to move it to a dedicated page?

Thanks for the PR Soma. If you solved this one, I owe you a beer (or a case of beer).

I think nateronn also mentioned this before. This will be one of the major drivers behind ProcessWire 2.4. I'm only concerned about actual bugs at this point for the 2.3 release. But it's a valid point and will make this look nicer soon. If using the same one as before, you didn't actually change the password. In this case, it literally needs the password to be changed.

if("$page->children->product_size") { This is not a valid statement, in PHP or in ProcessWire. If it were valid in ProcessWire, then you could just remove the quotes and it would work. Either that, or you could surround it with "{$page->children->product_size}". However, there is no "product_size" property of PageArray, and $page->children is a PageArray. I'm thinking that maybe you meant this? if($page->child("product_size>0")->id) {