ryan

That was never meant to be used on the front end. I'm impressed you actually got it to work. That module really does need to bind itself to page-edit permission just for the security of the admin. But what you might want to do is copy that modules files to your own dir in /site/modules/ and rename them, and rename the class to something like ProcessPageEditImageSelectCustom. From there, you can modify it to do what you need.

I agree with Joss that repeater sounds about right for what you've mentioned. But if you need infinite scalability, I'd suggest creating a new template to represent your data table, and then make each entry of it a page.

Not sure that I understand. Date modified is not the default sort order. The default sort order is manual, which naturally looks like 'date created' order, until you drag a page in it to a different order. The default sort order for a page's children can be specified either at the page level or template level. If specified at the template level, you won't see the option at the page level.

Currently the CommentsManager is available to users with 'page-edit' permission. I'll add some custom permissions for the next version of this. But if you want to change the behavior now, edit the ProcessLatestComments.module file and change this line (near the top): 'permission' => 'page-edit', to this: 'permission' => 'comments-edit', Then go to Admin > Access > Permissions, and add a new permission named 'comments-edit'. Then assign this to any roles you want to have access to it. If you only want it to be superuser, then you don't need to assign it to any roles.

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.