teppo

There's a little gotcha related to this module: if you have it enabled on a late version of ProcessWire, it could break the language translation UI if one or more of your translation strings include the phrase "</head>". ProcessPageDelete inserts a script block in front of all of those, which breaks the scripts on the page. None of such phrases in the core (by default) as far as I can tell, but it is found from some rather popular modules (Minify, FormBuilder). Not sure if this module is even needed on newer installations – just happened to have it installed on a site I'm currently updating from 2.x to 3.x, ran into this issue, and thought I'd mention it in case it will save someone else a bit of debugging time

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