teppo

@Vayu Robins, to be honest I wouldn't be surprised if it wasn't. Repeaters, I believe, are somewhat supported, but Repeater Matrix is a lot more complex, at least as a concept. I'll look into this as soon as possible. @apeisa, I'll look into that image issue too. Unless that's really easy to fix, it might be time to release a 3.x branch of this module though. Could probably solve a bunch of things more cleanly now. API level tests still look good, so I'm thinking that this file issue might have something to do either with the "recent" UI updates, or perhaps the temp file thing..

@clsource: sorry for the delay. Weekly.pw RSS feed should now work as expected

Just for the record, we used to see similar issues, and the easiest solution was to convert all instances of \r\n to \n. Can't remember all the details, but this tweak has been in use at least for a year or two now, and so far we haven't encountered any additional issues. I know that the RFC specifically demands \r\n, but for some reason certain recipient systems seem to mess up HTML emails with that in place. It is my experience that \n works much better, regardless of the standard. And yes, we use a separate SMTP server (which in turn uses another SMTP server). Obviously it could be something about that setup, but if you google around a bit, \n instead of \r\n is a surprisingly commonly used solution

Regarding commercial modules you should definitely ask the author of the module first, this may or may not be an issue for them. My opinion (IANAL) is that you can freely bundle open source, non-commercial modules with the site even though you're selling it "like a theme". Only exception to this would be a module with a license that doesn't permit this, but personally I'm not aware of any (non-commercial) modules like that. The point here is that each module is a separate entity that can (and should) declare a license of it's own. If, for an example, you want to bundle a GPL licensed module with your commercial "theme", that's fine, but you cannot change the license of said module. Basically this just means that whoever buys a theme from you may not redistribute your theme as a whole (unless you permit it) but they *may* still redistribute bundled modules individually.

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.