teppo

Hey there, @theo! Just wanted to notify you that I'm moving this topic to the "Module/Plugin Development" subforum. The "Modules/Plugins" forum area is where support boards for existing modules live, while all module development related topics belong to the "Module/Plugin Development" subforum. Thanks, and sorry for the disturbance ?

@Thomas108: this is a Textformatter module, so you need to enable it via field settings: Setup > Fields > your-fieldname > Details > Textformatters.

@horst, sorry to bother you with this (and sorry if it's a dumb question in the first place), but what's the current state of this module like? I'm in desperate need of "pixel perfect" pre-defined crops, and while the focus and zoom feature is really cool, it solves a different problem entirely. Reading some of the posts here I'm wondering if this module is still something I should go with, or do I just need to wait and hope that @ryan decides to add pre-defined crop areas to the core one day? Thanks! ?

Depends on your use case, but.. that's not entirely true. When you embed an image into a CKEditor field, for an example, you get to choose from which page you want to pick the image from. Similarly you can request an image from any given page via the API in your template files. So no, an image is not strictly tied to one page: you can embed images anywhere, and you can indeed use them in multiple places on your site. There are also some modules that make reusing media easier, such as MediaLibrary (free) and Media Manager (commercial). It is true, though, that behind the scenes an image is always connected to a single page, and because of that ... A) you can't have a single image showing up in image fields of multiple pages, B) only one copy of each image file is stored in a page-specific directory under /site/assets/files/, and C) if you have restricted access to a given page and enabled $config->pagefileSecure, access to files (including images) on that page will also be restricted.

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

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