teppo

Not really sure where to go from here. The latest error itself seems to indicate that $config->preloadCacheNames is null, so either that setting is missing, or the entire config is not working right. Some things you might try: Make sure that /wire/config.php exists and is readable for your Apache user Check if $config->preloadCacheNames is set in /wire/config.php (value should be an array) Make sure that you aren't overriding aforementioned config setting in /site/config.php I must admit that I don't have a slightest clue about what has gone wrong here, so these are just random ideas. In theory it could have something to do with ProcessWire being installed in a subdirectory (haven't done that in ages myself). According to your server, the PHP version shouldn't be an issue here, and since you're running on Apache, it's unlikely to be a web server issue – at least unless your host has done something strange for their setup.

There should be an "unselect" button next to the selected page. Similar to the select button, this also becomes visible when you hover over the page. If that doesn't appear for you, I'd recommend submitting a new issue at GitHub.

That's a pretty good idea right there If that doesn't help, I'd start by checking if /wire/modules/Inputfield/InputfieldInteger.module exists and is readable to your Apache user. In case you have a /site/assets/cache/FileCompiler/ directory, I'd also clear that, just to be sure.

Just chiming in to point out that this sounds like something that might be better solved by the Field Change Notifier module. I'm not sure what the state of said module is, and it doesn't currently seem to support selecting notified user based on the page being edited either, but perhaps it would be easier to adapt to this need?

Sorry for the delay, folks – been a bit busy lately, but I'm now slowly trying to work my way through your reports Version 2.1.6 includes a couple of fixes related to this one: Revision tables are now vertically scrollable. This isn't necessarily a perfect solution, but at least the UI is now usable even if the inputfield itself is very narrow. I've also added some UI hints to signal if/when scrolling is expected. InputfieldColumnWidths() is triggered after showing/hiding a revision table, so the first thing mentioned here should be fixed now (hopefully). I couldn't reproduce the 1px overlap. Might've already fixed that one, or perhaps I just wasn't able to recreate the setup needed, but I'll get back to that if it's still an issue. The absolute positioning thing I kind of covered in my previous post (I'd prefer to avoid that), and the panel thing is exactly as mentioned above: they seem to require an URL, which is then opened in an iframe, and that would be a bit problematic (to say the least) for my use case here.

I think you're looking for something along these lines: $data = file_get_contents('php://input'); See https://stackoverflow.com/questions/8945879/how-to-get-body-of-a-post-in-php for more details. And no, to my best understanding this is not something that $input API var handles

Having built a number of complex projects with tens or hundreds of thousands of pages with ProcessWire, I can say for sure that ProcessWire works very well for all sizes of projects. That being said, it seems to me that your current use case does indeed differ quite a bit from how ProcessWire works right out of the box, and in that case it shouldn't be such a huge surprise that in order to get exactly the result you want, you'll need to modify the system in one way or the other. My point is that it's simply not feasible to add settings for every single use case one might face – and since we're talking about a system such as ProcessWire that already provides a ton of hooks that allow you to modify its behaviour programmatically, there's really no need to do that either. Im not trying to deny that what you've suggested here makes sense, at least in your context, but that's still just one of the million use cases for ProcessWire. Some things to consider: As others have explained above, in ProcessWire "admin pages" are Process modules. Creating a new Process module is surprisingly simple, so rather than customizing the Page tree I'd really suggest that you give them a try and then consider hiding the Page list for roles that don't need to see it. Like LostKobrakai pointed out above, depending on your permission related needs you might be able to get by with one of the third party modules already available – in your case I'd suggest checking out Dynamic Roles and UserGroups. You've mentioned that Page list should be paginated, and it already is. By default pagination is set to display 50 child pages (I think) before paginating the rest. This setting can be tweaked via ProcessPageList module settings. If you have any specific questions, please let us know – we're always happy to help. That being said, if you're going to expect for the system to cater for every possible use case right out of the box, you're definitely going to be disappointed. Just like you'd be with any other CMS, for that matter

Thanks @Robin S, I'll take a look at these ASAP. Part of the reason the new UI works as it does (in context, not overlay) is so that it could play nicely with some admin theme quirks and differences. Another reason is that overlay UI's are a bit of a problem from usability point of view, so I'd rather steer away from them. Anyway, I'll see what I can do about these. The part about checkbox is a bit of a surprise to me. This also means that other icons, such as the default "collapse" icon, disappear when the field gets expanded, right? Seems weird to me, but perhaps that's how it's supposed to work. Not sure how I managed to miss this earlier

@maxf5, I have just removed certain remark from your earlier post as a moderation action. Also my apologies to @cmscritic – you definitely shouldn't have to see that kind of language here. A friendly reminder from the moderating team: please keep the tone of discussion polite. Crude or discriminative remarks and insults of any kind will absolutely not be tolerated on this forum. As a community we're committed to keeping this forum a safe and welcoming place for everyone. Think before you post.

Unless my memory fails me, all I did was add support for multiple answers and user-submitted suggestions. Might've made some general purpose (JavaScript/CSS?) tweaks too, not entirely sure anymore. Once the current version stabilises, i.e. I know whether the updates from @BitPoet get merged in, I could set up a new PR for these

Thanks for letting me know. Self-correcting issues, what fun

@adrian, I'm not seeing that issue here. Any chance you could check your login page for a hidden input with name "javascript" and value "1"? This is how LoginHistory knows that you've got JS enabled, so if that's not there, then it's probably going to report it wrong. Then again, if that doesn't exist, it shouldn't be able to get screen and window dimensions either (are those missing too?) You're not using a custom login form, are you?

I might be in the minority here, but at first I had absolutely no idea what an "input mask" is. This cleared things up nicely: https://css-tricks.com/input-masking/. Seems like a nice addition – either for the core, or as a third party module.

Got to agree with Kongondo: if that is doable for you, i.e. both sites sit on the same server, bootstrapping ProcessWire is probably your best bet. Otherwise I'd recommend checking out the REST API site profile and/or ProcessGraphQL. To my best understanding both provide the ability to create content via the API, and both have some sort of authentication mechanism available. Authentication is basically the main thing here: it's really easy to create a ProcessWire page that takes POST requests and creates pages etc. but you don't want, under any conditions, that to be publicly available without some sort of authentication. This is why I'd recommend checking the existing solutions first, and only rolling out your own solution if it's absolutely your only option

The steps I can think of right away would be... Moving the site files to the server. This is should be quite straightforward: use the scp command, or an SFTP application, or whatever you prefer. Just get the files to the production server somehow. The database part depends a bit on the tools you have available, but basically you need some way of exporting it as an SQL dump from the dev server to the production server. If you're familiar with command line tools, mysqldump is one way to do this – here's one guide for that. If you have a tool like phpMyAdmin installed, it has tools for both exporting (on the dev server) and importing (on the production server) SQL dumps. Note that you may have to create the database and related MySQL user on the server beforehand. This, again, depends a bit on your particular server setup. Check your /site/config.php on the production server and make sure that the domains and database credentials in there match the ones you're using in production. ... and that's pretty much it, I think. Hopefully I didn't forget anything important – my own process is a bit different, so I don't really do this that often Obviously there will be some more generic things to take care, such as connecting a domain to your production server, and so on and so forth. For these I'd refer to any instructions your hosting provider might have.

@Robin S: it's the latter case. I had originally some weird issues with image fields and such, but got those fixed at the last minute, so was a bit worried that there might be other issues I just hadn't noticed yet. Also the UI of the 2.0 branch could be a bit unstable: I've been moving things around, trying to figure out what works best, and I'm still considering rebuilding the History tab from the scratch. That being said, if you're using PW 3.x, I'd definitely recommend going with the 2.0 branch. Current master branch works fine with PW <= 2.7, but not so much on 2.8 or 3.x. Also, if you do run into issues, please let me know so that I can take a closer look at them

@ukyo: first of all, thanks for extending WireMail. I think this makes your module more useful in the long run. Now, sadly there's a bit of a downside to this: a week ago Ryan pushed an update to the dev branch (related to this issue) that changed the way WireMail modules are found by the core. In short, the class name must now start with "WireMail". One can get past this auto-detection feature by manually specifying (in a config setting) the name of the WireMail module to use, but in order to work optimally both now and in the future, I'd still consider renaming this module to something that starts with "WireMail". Thanks again, and sorry for the trouble

Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be. I'd say that unless you've got a very good reason not to extend WireMail, you really should. That being said, thanks for your work on this module.

Sounds to me like there's a bit of a misunderstanding here. First of all, fields are connected to templates (home, basic-page, etc.) and field values are applicable to pages using that template, so technically there's no such thing as a field with the same global value everywhere. You can solve this in a different way, though. Taking a step back, what you originally asked for was ... The easiest way to achieve this would be adding those fields to an existing template – such as "home" – and filling in the values for a page using that template – in this case your home page. Then you can do something along these lines in your _foot.php file: <?php echo $pages->get(1)->footer1; ?> In other words you can fetch a specific page ("1" in this case means the page with ID 1, i.e. your home page) and then output the value of the field ("footer1") from that page. From what you've written above, it sounds like you might've created a new template called "footer", added fields to it, and then perhaps created a new page using this template too. Sound familiar? If so, you can also use that page as well (instead of, say, your home page) to store your footer values: in your _foot.php you can get that page and output the value from it with <?php echo $pages->get('/footer/')->footer1 ?>. Does this make sense to you?

Was just wondering why people suddenly started starring my module repositories. Cheers, @adrian

Code Blocks Textformatter is a tiny Textformatter module I cooked up to add support for code blocks to text/textarea/RTE fields on some of the sites I work with. Unlike a full-blown Markdown Textformatter – which is something that we already have in the core – this module simply adds support for fenced and inline code blocks. The syntax is based on the GitHub code block documentation, so please refer to that for additional instructions. The README at GitHub also includes some basic examples. As with any Textformatter, in order to enable this one, install it and enable it via field settings. Note that there's no syntax highlighting built in (at least for the time being), so use a tool of your choice for that – personally I prefer Prism.js. Since this module doesn't use a Markdown tool behind the scenes, but rather some home baked regular expressions, there's always the possibility that I've missed something – but please let me know if you use this module and run into any issues. On the other hand this module should be relatively fast and unobtrusive, as there are no unnecessary bits of code to run GitHub repository: https://github.com/teppokoivula/TextformatterCodeBlocks Modules directory: http://modules.processwire.com/modules/textformatter-code-blocks/

You need to add pagefileSecure-setting to your /site/config.php file, and set it to "true": $config->pagefileSecure = true; More details here.

Hi there. Not a complete answer, but first of all I'd suggest taking a closer look at this post, which has a link to an article hopefully resolving some worries regarding encryption of data: Other than what you've described above I don't have a rock-solid solution for you. I would assume that, as long as you're taking care of other parts of the regulation – such as breach reporting, removal of data on request, and so on – and you encrypt all traffic targeted at personal data (HTTPS), you should be safe. But then again: IANAL, so please don't take my word for it. I'm just assuming some common sense, really. With current technology it would be next to impossible to encrypt all personal data, while still collecting all the necessary data in the first place. Think of things like server log files etc.

Some loosely related observations re PWA vs. native:

Just pushed a fix for this issue to the 2.0 branch