BitPoet

Is the form data actually sent (what does the browser's network console say)? Is any 301 redirection happening for the request to the proceed page (and if yes, does adding a trailing slash help)?

@David Beesley: I haven't tinkered with the modules in a while, but I'll try to find the time to run some tests over the next few days. I'll post back here.

The two sql_mode settings incompatible with ProcessWire should be ONLY_FULL_GROUP_BY and STRICT_TRANS_TABLES. The dev version (>= 3.0.37) removes those by default for MySQL versions >= 5.7.0. It might make sense to file a request to run that logic for all MySQL versions that support these settings. Also, for *= and ~= to work, the search string needs to be 4 characters or longer. See the selector operator documentation (especially the two paragraphs before the "Negative Operators" heading) for details.

You can set the classes to be used for left, center and right alignment in the configuration settings of ProcessPageEditImageSelect.

The pages views IMHO aren't really in a critical range if you have halfway decent hardware, though if you're really trying to squeeze milliseconds out of the system and be prepared for spikes in page hits, a (carefully tuned) redis approach might be the best option. As an intermediate solution, you may also consider storing hits in a (non-pw-field) InnoDB table (entry id with auto increment, page_id, timestamp, plus arbitrary non-key columns) to avoid file level locks and repeated seek()s to the end of a potentially large log file. I'm using the InnoDB approach for our intranet with > 50.000 page views / day. In a nightly cron job, I switch the stats table for a new one (create table stats_new like stats; rename table stats to stats_[timestamp], stats_new to stats) and process the data from the then idle table.

I can't spot anything wrong, but try to re-upload the file to the live site and make sure that there is no linefeed conversion active. Also, you should probably remove the closing php tag (?>), as it might simply be an issue of trailing (and perhaps even invisible) characters after that tag.

That's a nice workaround. Didn't think of that.

You should file a bug. WireDatabaseBackup::getAllTables() caches the list of tables in a static variable $tables across instances when it is called without parameters like WireDatabaseBackup::backupPDO() does. Since getAllTables() is only called once in the file (and not called by any other core file), I'm not sure if the caching option is necessary at all.

You can edit the json configuration for the admin template in the database (table "templates") and set the value for redirectLogin back to its default value of 23.

This might be the same problem as in issue #55.

Comparing the (ajax) request URL and the value of the Location: header sent back should normally clue you in to what is going wrong. Missing trailing slashes or missing language names in multilanguage URLs have been known culprits for such behavior, but there are probably dozens of possibilities that trigger a 301 redirect. If you pass an absolute, hard coded URL to the ajax request, a missing "www" in the domain name or a protocol mismatch (http vs https) might also lead to a redirect.

The module adds two image fields to the language template, one for published and one for unpublished status.

I don't use ProCache (yet, since all the PW sites were highly dynamic ones and speed wasn't an issue so far), so I can't speak from experience, but with ProCache I'd likely set up a script in a (system) cron job instead of a ready.php snippet and interate through all pages with a selector like "replacement_active=1, replacement_date<=$now", then perform the replace as above and save. I believe ProCache should update the cache on its own after page save (correct me if I'm wrong).

A bit similar to @arjen's approach: Duplicate the field as yourfield_replacement labelled "Your Field Label Replacement" and add it to the page's template Add a new datetime field replace_after labelled "Replace field at" to the template In site/ready.php, check if $page->replace_after <= current timestamp and $page->yourfield_replacement has content If yes: replace $page->yourfield with the content of $page->yourfield_replacement, empty $page->yourfield_replacement and save page This way, editors can edit new content in the added field and schedule replacement whenever they want. The replacement will happen the first time the page in question is accessed at or after the date+time in $page->replace_after. You can make it a little more elaborate and safe by adding a checkbox to activate the replacement logic and reset it after successful replacement to avoid accidential replacements, which are likely to happen when editors hit "save" after changing the replacement content without having adapted the replace date first.

Is /usr/bin/php in fact a client sapi build? Is there a /usr/bin/php-cli (or php5-cli) binary on the live system that you can call from cron instead?

@blommie: I'm not sure JsonNativeField is going to fit your bill. While it supports an arbitrary number of entries, those are key => value pairs, much like regular fields with a name and value. You might want to look at the ChosenSelect Inputfield, which behaves as a tagging field and allows creating new "tags" (which are actually PW pages behind the scenes with the tag value as the title) on the fly if you enter a new name. Repeater and Page field types don't need you to have the pages used in them to already be present in the system. A page is just an entry in a table in the database, and if you use repeaters, the template configuration for these pages is even done behind the scene when you define the repeater field's parts (fields). If you're coming from other systems, the concept of using "full-blown" pages for simple data might seem a bit much, but because PW keeps things simple under the hood, it actually doesn't get much leaner database-wise.

It's actually still on the list, but there were a lot of other things that took priority. While I did incorporate some of the changes mentioned above, I'm currently not happy with the behavior in the page list, so this needs some extensive and careful tinkering. Currently, changing online/offline status from the page list reloads the tree each time, which is too time consuming. Since it's in use in production in an ever-growing intranet page, that will become urgent sooner or later, so chances are high I can fit the overhaul in before Christmas.

That's great to hear. Thanks for testing!

Well, you haven't tried what I did to the code yet But if you want, just grab the newest WireMail.php here. It would be great if you could give me some feedback.

So there's good news and bad news, as I'm almost done testing. The good news is that I'll be able to wrap up the content nesting code some time tonight. The bad news is that fixing the problem of subject lines > 76 characters is basically impossible, since PHP's mail() function messes up all attempts at wrapping the subject header, mb_encode_mimeheader or not, on my system. This is likely a Windows oddity, but it's reproducible across PHP versions. Strike the bad part, fooled myself there. So chances are high there'll be a working, thoroughly tested git branch by this time tomorrow.

@jmartsch: I had this already in the back of my mind, but since PW doesn't enforce the precense of the mbstring extension in the installer, I want to tackle this problem with a viable fallback for non-mbstring systems. Assembling a failsafe wrapping solution without mbstring is a delicate subject though, so I want to give any code I propose a really thorough testing. I'm trying to get another pull request for WireMail out in the next few days. That patch will also have proper nesting of multipart types so that the HTML is rendered in all clients (especially Outlook) when attachments are present. Currently, some ignore the HTML in favor of the text part since all parts are treated equal in multipart-mixed.

@jmartsch: is your source file that sends the mail definitely saved as UTF-8? I'm just doing some really extensive testing (including running mails through different sorts of mail servers along the way). I've spotted one issue with the position of quotes in the from: and to: fields but that is only triggered when there's a comma in the name, and there's a slight problem with HTML mails with attachments which should have nested parts since text + html should always have a multipart-alternative parent for the HTML to get displayed. I couldn't reproduce your or @Juergen's issues yet, though.

The way I read the code in ProcessWire.php, this notice should only ever be triggered if you're bootstrapping PW and passing in a URL as the second parameter that contains a hostname not listed in $config->httpHosts. Is this generated by a bootstrap script? Which PW version do you use?

No, you've removed all the necessary HTML markup. You need to echo that too if you want the output to be the same.

The latest version of mPDF (7.0.0) already supports PHP 7, so it should be just a matter of pulling the latest sources into the module (unless there were breaking changes since 5.7).