teppo

This may be just my impression, but I think that this side of your modules, particularly FromBuilder and ProCache, would be worth exploring a bit further. I find myself extending both modules quite often for different client needs, and in my opinion third party extensions to these modules could bring in notable extra value. That, at least, is how it works for their WordPress counterparts. (Not saying that you should start mimicking Ninja Forms or Gravity Forms etc. but I do think that they have handled the extension thing pretty well.) Please don't. While Pro modules are better featured in other places, this is a good way for third party commercial module authors to get some extra visibility. That alone is a very good reason to keep this category around and even develop it further (Oh, and sorry if I misunderstood and you just meant that you might remove your own Pro modules from there. That's fine by me, though it'd be a shame; I like the idea of being able to quickly check out what the commercial module market for ProcessWire looks like.) Thanks for considering this. Perhaps you're referring mainly to new users bringing this up "out of the blue", but I for one tend to avoid bringing up topics that are, for an example, already listed on the roadmap. I'm probably not the only one who thinks like this, which might be one of the reasons why it doesn't come up that often

We've been using UserGroups for this use case for a few years now. This might be one of those unmaintained projects you were referring to, but if that's the case, it's mainly because it has been working just fine. No need to fix what isn't broken That being said, we haven't been using UserGroups with ProcessWire 3.x, so can't really say for sure how well those two work together.

Thanks for clarifying, that makes sense to me

While you say that it's legitimate traffic, what kind of traffic is it? What I'm wondering is what exactly happens during that spike: are there more requests to a specific feature than usual, etc.? While a code review could definitely result in some ideas about what to optimise, usually the best and first thing you should do is properly analyse the data you have, i.e. your log files. Find out any abnormalities in the requests, see which requests were particularly slow (you should get this data from the web server logs), and see if the MySQL slow query log (if you have it enabled) contains any additional clues. As an example, one site I help maintain recently got a lot of heavy traffic all of a sudden. Turns out it was a result of a campaign where each request included a similar GET param, and that in turn made the site skip cache. Note that I'm not saying that this has anything to do with your specific case; it's just something I couldn't tell from the amount of traffic alone, but it was really obvious once I took a closer look at Apache logs On a related note, it could also be that this has nothing to do with the code itself. It could simply be that your server -- or server configuration -- is the bottleneck. That too could be a result of an increase in a specific type of request, so again taking a closer look at the logs is where I'd start from. Edit: It seems that you're running an nginx reverse proxy in front of your site, but for every request I get a response header X-Proxy-Cache: MISS. Doesn't seem that this proxy is doing it's job too well if none of the requests are served from the cache. I'm not an expert on this particular topic, but in my opinion there's something fishy about your setup

Hey there, Robin! May I ask you what the actual use case for this was, i.e. why did you need to hide this menu item? Mainly just curious

Definitely a good point. Just for the record, I'm moving this topic to the Module/Plugins Development subsection of the forum

Moved

Personally I think that this thread already includes so much great content that it'd be a shame to abandon it -- not to mention that it's more than likely that folks looking for details about this module would end up here anyway. It's your choice obviously, but if you want, I (or any other moderator here) would be more than happy to move this thread to the modules section. Just let us know when you have decided what to do with it

In my opinion there are two sides to this problem: Many client's know WordPress and ask for it specifically, which in turn means that the companies building sites find it an easy product to sell. Even if the client doesn't know WordPress, they just need to be told that it's the most popular CMS out there. "You can't go wrong by choosing the most popular product in the market." Many web developers first dive into the CMS world via WordPress. Once they know it, it's tempting to use it for everything. Even if it's a struggle to create anything more complex with it, they a) don't know that there are better alternatives, and b) going with another system would require a whole lot of un- and re-learning. I try to advocate for ProcessWire every chance I get, mainly because I believe it's truly a great product, and fits many needs amazingly well. Obviously it's not for everyone, and in fact I have once or twice actually recommended going with WordPress instead. Funny you should mention this, as I was literally just today thinking about how the commercial modules fit the ProcessWire landscape, and once again came to the conclusion that it was a smart move from Ryan to make FormBuilder as cheap as it is. If you think it's "not very cheap", you probably don't really get how much it does for you Before Ryan released FormBuilder we were contemplating building our own form module, but just thinking about how many things such a module has to handle makes me shiver. It's a heck of a lot of work to build a module as flexible as FormBuilder, and making it easy enough for anyone with no technical expertise to build complex forms is not easy either. Agency license for FormBuilder is $289, and I can pretty much guarantee that building a module like that on your own will cost you at least ten times that amount. On the other hand we were considering buying another commercial module a while ago. The cost for a single license for that particular module turned out to be four digits, and eventually we decided not to buy it. I've been working on a module that matches our needs specifically, for a cost that is notably lower than we would've had to pay for the third party module. We're planning to release this particular module as open source when it's finished. It's true is that you generally can't add a completely new feature to a site, let alone build a new site from the scratch, without at least some basic dev skills. That's also not the market we're in. I think those who want to do that would be much better off with a DIY website builder platform such as Wix or Squarespace. This kind of thing is not really the forte of WordPress either – building a complex site from (sometimes) badly written, barely compatible plugins requires a whole lot of work, at least in my experience This depends on your definition of a "big company". Avoine is, in my opinion, the best example in this category – they've done some pretty amazing stuff with ProcessWire. Everyone in our line of work should know them, at least. I'm not an official spokesperson for my company so I prefer not to go into more detail, but at Fonecta we also use ProcessWire in some of our projects. You've probably heard of us before. If you're into command line tools, check out wireshell. Depending on your setup there are other solutions too, probably the easiest being the built-in multisite support, where multiple separate sites share the same core code.

Having a proper front-end framework power our.. umm, back end.. is a great idea. While keeping dependencies as low as possible makes sense and has, in my opinion, proved out to be a great strategy so far, this is one of those cases where an outside component just plain makes sense. My hope is that this will also simplify the workflow for module authors trying to match the look and feel of existing admin theme(s). Currently you basically have to target a certain admin theme, and even then you'll probably end up inventing a few UI features / components of your own. Not a very good situation for providing a consistent experience for end users Have to agree with @Robin S. I enjoy simplicity as much as the next guy, but the default tab component in Uikit is just plain bad in terms of both usability and accessibility. Another thing that slightly bugs me in current design (which we probably shouldn't be commenting on, considering that it's obviously not the final one) is the low contrast: that's a really common mistake in terms of accessibility, but luckily it's also really easy to fix.

Generally speaking you're, of course, right -- in most cases one should use built-in visibility settings and permission-related hooks, but it's not unheard of to check permissions in a template file either. Depends a bit on the use case. And yes, you're right that in such cases it may be preferable to avoid installing such a module at all. Obviously this is mainly a problem with systems that include a enabled-by-default (or always enabled) built-in public API, and less so when enabling/installing the API itself is a conscious choice. Either way, it's good to understand that exposing your content to the world via a publicly queryable API may uncover some surprises. This is one of the reasons why I find certain value in the idea of crafting the API per current needs and so that it only exposes the minimum viable amount of data Note: don't get me wrong, I'm definitely not against this module. What I've said here is mostly theoretical. I also think that your idea of being able to manually define queryable templates makes a lot of sense. While I'd still suggest enabling a selector instead, you obviously know the use cases (and the implementation) better.

This sounds good, and that's basically everything that a "generic", publicly accessible API can do. I've got no complaints here What I've found out while playing with the WP REST API a while ago is that even though permissions are sensible, it may end up showing more than the public site. Part of it is about things like (not just page but) field level permissions, and part is about pages that exist and are publicly viewable for technical reason, but are not *intended* for public consumption, if you get what I mean. Surely it would be best to always use native permission rules to limit the visibility, but sometimes a site may have content that is viewable only if you know the direct URL, and a public API like this may make it "more public" than the developer intended. Another thing is that there may be a code-level permission check in place, and a module like this would have hard time figuring that out. That being said, have you already implemented or are you considering implementing custom selector support for such limits? I.e. allow the developer to manually define a selector that returned pages must match, or alternatively should never match? I think that could make a lot of sense from a security point of view, particularly for public API endpoints, where it might actually work best as a per-endpoint setting

Translation files are located in the /site/assets/ directory, as files under the language page itself. If the ID of your target language page is 1010, the translation files should be under /site/assets/files/1010/ as separate .json files. As long as you copy / sync your assets directory to the production server, these should work as expected

First of all, I think this looks great. I'm not entirely sure if I'll ever need something like this personally, but a module like this would no doubt be useful for some cases To my best understanding the main point Ryan was making about REST was that since it's easy to add new views (or whatever you choose to call them) for a ProcessWire site, a separate module doesn't make as much sense as it does for a system that doesn't provide similar flexibility. I've got some, albeit very limited, experience with the REST API in WP, and in their case it definitely makes a lot of sense. There's also the question of security: there may be cases where something is technically speaking public, but not accessible via your existing web site, and a "generic" REST API could result in some surprises there.. and, of course, if it's not read-only, that's a whole another thing to worry about. All that being said, I'm looking forward to seeing where this module goes. An easy-to-use plug-n-play GraphQL API sounds like a great thing to have in one's toolbox

I posted something like this a few years ago, but that's obviously not up to date with current versions of ProcessWire. Would be interesting to create an updated version and compare these side by side, just to see how far we've come since then

This module was launched before 2.3.1, which introduced conditional autoloading. Aforementioned change seems reasonable, but means dropping support for 2.2. ... although dropping support for 2.2 at this point doesn't seem like such a huge issue

If you're talking about manual cropping, check out Croppable Image:

You've probably seen this already, but this old post from Ryan includes some general tips: Like Horst pointed out above, the name doesn't really matter that much, as long as it makes sense to you. That being said, https://martinfowler.com/bliki/TwoHardThings.html

@LostKobrakai just a quick heads-up: your elixir link was broken, so I pointed it to elixir-lang.org. Hope that's the correct destination

I've used method 3) before, though I don't consider it a hack at all. That being said, I chose this route mainly because I strongly dislike a) complexity and b) dependencies, and that right there is a straightforward way to get some asynchronous PHP magic up and running in no time. I also didn't have any need to track the return values etc. of started processes, so no real need to keep track of them either; that alone adds quite a bit of complexity, and may be a valid reason to use something like React instead. Anyway, I think @netcarver's solution makes most sense here. I'd also opt for a JavaScript based solution. If the generated data is going to require some heavy lifting behind the scenes, you should consider (pre-)caching it, but other than that a client-side implementation often makes most sense.

When you request $page->url, ProcessWire generates it on the fly, kind of: it's a combination of $config->urls->root and the path of current page. Root URL is defined when the system is started, and $page->path is constructed from the names of parent pages. Similarly $page->httpUrl is a combination of protocol, hostname and $page->url

Just a quick heads-up: I'm moving this topic to the module development subforum.

I wouldn't mind having a $page->depth property (in my opinion depth is more descriptive than level, but that might be just because I'm used to it from other systems) available out of the box either, though I do also wonder how useful it would actually be? Right now I can't think of any past situation where I would've needed this for selectors, and on the front-end counting the number of parents is so simple that it hardly makes sense to have a dedicated feature for it. In my opinion it only deserves to become a built-in property/feature if it's indeed a (very) commonly needed thing. If not, it should be implemented on a case-by-case basis as a hook or module or whatever

Database. If it was an in-memory query, the first find() operation would need to return every single child page along with the pages actually matching the query. I don't know anything about your structure, but it appears that you have "room pages" below /bookings/ and each room page has a variable number of booking pages as it's direct children, right? In the first query, if you're only interested in the direct children of /bookings/, you should use children() instead of find(). You should get a notable speed bump from this alone. Additionally: while this is probably not production code, please note that with every find() operation that has the potential to match a large number of results you should use limit, or otherwise you'll risk running into both performance and memory issues at some point.

I can think of a few reasons, and while some are purely technical and some are related to what Ryan already explained before, think about it this way: if a page is omitted from URL because it's currently not viewable, what happens if it becomes viewable later?