ryan

I have no experience with Amazon's setup here, but definitely curious. Have you tried enabling PW's debug mode in /site/config.php just to see if maybe some errors are occurring that might be getting missed? It'd also be interesting to know if any errors show up in your JS console. I'd also be curious what versions of MySQL and PHP are in use here. If you PW login and a phpinfo(); link you can PM me I'll be happy to take a look.

require_once isn't ideal for prepend/append template file settings. When you call $page->render(); you want to know that everything you expect to be included is included. A lot of us call render() methods on other pages, which a require_once() could break. If there are things that need to be require_once (like function or class definitions) you can always move those to another file and require_once them from your prependTemplateFile. My prependTemplateFile usually looks something like this: // initialize page regions with default values // this will be output eventually in _main.php $headline = $page->title; $browserTitle = $page->title; $body = $page->body; $sidebar = ''; // include shared function libraries require_once('./includes/finder.php'); require_once('./includes/render.php'); As for your particular case, it sounds like you've got some logic running after output has started. You want to move that logic to somewhere before output starts. Given that, prependTemplateFile is not an ideal place to output header markup. However, if you want to continue doing that, then you may be able to place this at the top of your prepend TemplateFile: if($page->name == 'http404') return;

The unzipping in that part of ProcessWire doesn't use ZipArchive, and it needs to be updated. ZipArchive didn't used to be very common, so calling an unzip utility from the shell (what PW does) used to be more reliable across servers. Unfortunately that method doesn't work on Windows servers. Also, ZipArchive is very common now and this part of PW just needs to be updated to use it instead of the older method.

Also, you ideally want to sort these before they come out of the database rather than after. That happens in your $pages->find() or $page->children() or whatever code comes before the code you posted that populates $results. i.e. $results = $pages->find("template=blog, sort=-blog_date, limit=3");

You should be able to do categories with form builder in this case. But note that your 'category' field will have to be a field of type 'Page' both in your form and in your ProcessWire fields. I'm guessing that you've currently got 'category' as a regular select field (rather than Page field) in Form Builder?

I didn't realize this aspect of the file fields output. I've put this on my to-do list for the next version of the module (actually for ProcessPageSearch, which is what this module uses).

The only more complicated stuff stored in the session would be CSRF protection. But I don't think that was the problem here, otherwise you'd get an error message telling you about forged requests. What browser were you using before where it wasn't working?

Usually when I need to truncate something it's because it needs to be a summary that fits appropriately in a defined area and consistently with other items of the same type. As a result, having HTML in the truncated text is no good, so I'll include a strip_tags() as part of the truncation process, then wrap it in my own <p> or what not. Most of my sites have a shared truncateText() function somewhere in there that works kind of like this. Maybe there should be one in PW's core, not sure. function truncateText($text, $maxlength = 200) { // truncate to max length $text = substr(strip_tags($text), 0, $maxlength); // check if we've truncated to a spot that needs further truncation if(strlen(rtrim($text, ' .!?,;')) == $maxlength) { // truncate to last word $text = substr($text, 0, strrpos($text, ' ')); } return trim($text); } $summary = truncateText($page->body); echo " <a href='$page->url'>$page->title</a> <p class='summary'>$summary</p> ";

Just tested here and Chrome and it seems to be working for me. I'm on dev 2.3.7, though I don't think it would matter to comments manager. Are there any other factors you can think of or steps to reproduce?

Here you go: Events Fieldtype/Inputfield

This module serves as an example of creating an editable table of data as a Fieldtype and Inputfield in ProcessWire. In this case, we create a simple table of events each with date, location and notes. This pattern can be adapted to nearly any table of information. Note that this module is intended as a proof-of-concept. If you find it useful for the example scenario (events) then great, but keep in mind it is not intended as a comprehensive events solution, where using ProcessWire pages may be a better fit. This is a pattern I've used for creating tables of data in ProcessWire for many different Fieldtypes/Inputfields and thought it would be good to setup a proof-of-concept example like this to share. Module Page / GitHub Page Install Copy the files for this module to /site/modules/FieldtypeEvents/ In admin: Modules > Check for new modules. Install Fieldtype > Events. Create a new field of type Events, and name it whatever you would like. In our examples we named it simply "events". Add the field to a template and edit a page using that template. Output A typical output case for this module would work like this: foreach($page->events as $event) { echo " <p> Date: $event->date<br /> Location: $event->location<br /> Notes: $event->notes </p> "; } This module provides a default rendering capability as well, so that you can also do this (below) and get about the same result as above: echo $page->events; ...or this: foreach($page->events as $event) { echo $event; } Finding events This fieldtype includes an indexed date field so that you can locate events by date or within a date range. // find all pages that have expired events $results = $pages->find("events.date<" . time()); // find all pages with events in January, 2014 $results = $pages->find("events.date>=2014-01-01, events.date<2014-02-01");

This has been added in the latest commit. I also updated CKEditor to 4.3.0.

The $map->render() requires either a Page with a 'MapMarker' field or a PageArray with multiple pages, each containing a 'MapMarker' field. If you are giving it a PageArray of multiple pages, and it's only showing a marker for 1 of them, then chances are that only one of the pages you gave it has a 'MapMarker' field. Keep in mind the field must be named consistently with what you tell it. Meaning, if you are calling $map->render($features, 'MapMarker', $options); then every one of the pages in $features must literally have a map marker field named 'MapMarker'. If they don't, then chances are that $features is not the group of pages you really want to send to render(). But $placepage clearly isn't either, since that's just 1 page (which is only going to print 1 marker). Based on looking at your code, I'm guessing this might be what you want? $features = $pages->find("parent=/events/, bfd_day.name=$todayday, bfd_month.name=$todaymonth, sort=bfd_year"); $markers = new PageArray(); foreach($features as $feature) { $markers->add($feature->bfd_events_places_id_list); } $map = $modules->get('MarkupGoogleMap'); $options = array('width' => '100%', 'height' => '400px'); echo $map->render($markers, 'MapMarker', $options);

I've not had experience with the DataTable module, so replying more to bump the topic up to someone that has. But everything you've mentioned sounds feasible to me (outside of any specific module), but would no doubt involve significant development.

The term "repeater" in our context means repeating the same type. What's being described above is essentially ProcessWire's pages system, and repeaters aren't meant to replace creation of page structures or groups of different pages. If there were a repeater type field that did that, there would have to be a different name for it.

I'm guessing he thought it was running under the same software as this forum (IP.Board) since it uses the same usernames and often the same avatars. But yes the modules dir is powered by ProcessWire and I can't imagine using anything else for it.

Page Inputfileds have to have directions on what pages should be selectable. Only you can know what pages you want to be selectable. The most common scenario is all pages having a certain parent. In that case, you'd set the parent_id property to be the ID of the parent page having those children. Another common scenario is all pages using a certain template, in which case template_id would be the property you'd want to set. There are also other options, like findPagesSelector where you specify a selector string to find the pages that should be selectable. If you'd like you can create+configure the field how you want it in Setup > Fields, then view the entry in PhpMyAdmin in table fields column data to see what options it stored.

There have been some good threads in the past getting into WireUpload usage, though not sure any of them were ajax specific. But it'd be worth browsing through some of these just in case. ProcessWire's InputfieldFile.module also uses WireUpload with AJAX so that might be good to look at as well. Using $_FILES[tmp_name] probably is not ideal because that's just the temporary PHP name and not the actual filename. Also, your code above is taking values from $_REQUEST without sanitizing them. In that particular case, I'd recommend pulling from $_POST (or better yet $input->post) rather than $_REQUEST, and running them through the $sanitizer->text(); function before populating to the page's title. Also, make sure you are validating the files that get uploaded, especially if only using $_FILES.

Are you sure that /stats/ is readable and that you are using it with a trailing slash, i.e. /stats/ not /stats ? ProcessWire should not take over unless Apache tells it to. There is a directive in our .htaccess that says "don't give control to ProcessWire unless the file or directory doesn't exist": RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d As a result, you shouldn't have to do anything else. But perhaps there are some other factors, like another .htaccess file somewhere or permissions on the /stats/ directory not being quite right. You shouldn't have to do this, but you could always add this to your .htaccess file to specifically say "stop processing these rewrite rules if the URL is /stats/": RewriteCond %{REQUEST_URI} !^stats You'd add that right above the other two mentioned above.

Based on your code, from what I can tell, you need to pass $features to the $map->render() rather than $placepage.

Since you are using language support, I think it'd be worthwhile to use the dev branch (2.3.7) either way. This also sounds familiar, like a bug that's already been fixed in dev. Though please let me know if you find it's not.

Any rich text editor is going to add a lot of overhead. I would probably limit your rich text editors to the admin rather than inline. Though there may be some combination of factors in your case that increases the overhead? What is dropzone.min.js?

Good idea, I'll add that. I agree. It could be problematic with some scripts. Perhaps it should be a configurable option as to whether scripts should be minified or not. Or better yet, an extra attribute on the script tag: <script minify> so it knows it's fair game. True, but we're talking about inline scripts in this case. I'm too lazy to go and re-minify inline scripts every time I need to change something.

You can use repeaters for smallish tables of data. In my own projects I usually create a custom Fieldtype/Inputfield for managing highly custom tables of data like rate tables and such. This is the most efficient way to do it, though not the simplest. But it may be simpler than you'd think. Most inline editing tools are 3rd party javascript plugins. It is possible to use just about any of these with ProcessWire, especially for text-based fields. But as ProcessWire does not get involved with the markup on the front-end of your site, it's something that you would need to implement. ProcessWire's API makes it a relatively simple job, but it's still development. You might also want to take a look at the Fredi module, a nice approach to front-end editing, even if not inline editing.

I'm not familiar with this. Is this something that there is broad demand for among other users here? Pete (forum administrator): if you are reading this, are you familiar with this and whether it's worthwhile to implement for this forum?