• Content count

  • Joined

  • Last visited

  • Days Won


teppo last won the day on October 10 2016

teppo had the most liked content!

Community Reputation

3,294 Excellent

About teppo

  • Rank
    Captain Earth
  • Birthday 08/21/1984

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

35,924 profile views
  1. 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
  2. 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.
  3. Thanks for clarifying, that makes sense to me
  4. 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
  5. 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
  6. Definitely a good point. Just for the record, I'm moving this topic to the Module/Plugins Development subsection of the forum
  7. Moved
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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