teppo

PW-Moderators
  • Content Count

    2,163
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by teppo

  1. About verbosity: I don't find it inherently bad either. Don't get me wrong – I truly enjoyed reading this post. There's always room for such text, and I love the way Ryan explains things. It just makes sense. That being said: if and when someone is only just trying to figure out how the API works – say, they're evaluating a number of platforms, and want to see which one makes most sense – it would be best for both us and them to have a short version available. Key points only: what are the methods they can use to access the API, where and why they should use each method, and finally "read more" -links for more details about each method. I've been digging into a lot of new tools recently, and I can say from experience that it makes worlds of difference for a newcomer how fast and easy they can get the basics in. It's the worst if you have to spend loads of time digging into terminology, long posts discussing philosophy and behind-the-scenes implementation, or other things that don't really matter at that point, just to know if this actually is the platform you want to invest your time in. It should be an incremental process: start from the basics in an easy-to-chew package, and continue building up from there. You don't want to drop a mountain of information onto a newcomer on one go
  2. The first bullet point seemed to answer my question from the previous thread: module's can't add features to the Functions API, it's immutable in that regard. The second bullet point, on the other hand, seems to contradict the first one: module developers can indeed create new functions for API variables, effectively adding to the Functions API – even if behind the scenes the implementation isn't identical. It might be worthwhile clarifying the wording here a bit, I at least found this part confusing. Leaving the "it's a very specific list of functions that doesn't change" part out and perhaps adding "By default" before "Only those that are likely" would be an improvement – unless I'm misunderstanding the whole thing? Also, a table of contents would be really nice for these longer pages. --- Overall I think it's great that there's now documentation for a lot of stuff that was completely missing before. I do agree with @adrian in that the new documentation is a bit verbose, though. It's a lot to browse if I simply want to get the facts. My own writing style tends to be extremely verbose, so I should know @ryan, would be possible to allow others to somehow make suggestions to the content of the site (and particularly docs) without having to open a new issue for every suggestion? It'd be amazing if we could somehow make some kind of change suggestions and submit them directly via the site, perhaps publicly – or at least for a limited group of volunteer editors. Trust me, I do realise that keeping everything up to date, managing the core, writing weekly posts, and whatnot must be an unbelievably time-consuming job. Just looking for ways the community could perhaps participate.
  3. teppo

    @rastographics, it looks like you're missing a semicolon (";") at the end of the line starting with "$f->description". Or was the screenshot cut off early?
  4. teppo

    Yes and no: the page those forms are rendered from isn't actually in the admin area. By default it's a regular page at /form-builder/. This page has a template file of its own, and when you access said page, it figures out the correct form and renders it – making use of some stuff bundled with the core for rendering the form and form fields. Technically you can do that with any module that produces output: just figure out when and where to render it, call a method that returns output, make sure that necessary styles and scripts are loaded, and output the... err, output. If you need to do something based on user actions, implement necessary endpoints with hooks, URL segments, or based on POST/GET data. I'm using something similar in ProcessChangelog for rendering the RSS feed generated by a Process module for front-end users: https://github.com/teppokoivula/ProcessChangelog/blob/master/ProcessChangelogRSS.module#L97:L103. ... but that's a really, really simplified version of it, and perhaps not quite what you're looking for yet. AdminBar makes use of the ?modal=1 parameter that Admin supports, in which case header/footer areas are left out of the response. I've used this method for injecting things like profile edit screens into the front-end for registered and logged-in users – though they tend to look a bit off in an iframe, so usually I use an actual modal instead – but it doesn't yet solve the permission issue. ProcessWire's permission system is relatively flexible, but as @bernhard already pointed out, there are always risks involved when you tweak such things Not trying to speak for Bernhard, but I believe the idea was to utilise the module architecture, probably Process modules in particular, to easily create front-end-oriented tools, so not really free-for-all editing per se. A booking system might be a good example – you may want to give guests a limited access to create new content or perhaps even edit/delete content based on specific set of rules, but this could also be useful for creating non-editable views. Front-end listers, anyone? --- I think that overall this idea has some potential. Not sure to what extent, or how feasible this would be, but it might be worthwhile creating a small proof-of-concept and trying things out. The permission thing is still a huge question mark, though. If I was to build something like this, I'd probably start by looking what ProcessController core class is doing, and how it's used by the Admin itself. Though correct me if I got the whole concept wrong, and this is actually about something different entirely. There may be other ways to use the module system in the front-end as well, but Process modules are basically what the Admin side is made of, so when you say "public backend pages" – well, that's what it sounds like to me
  5. teppo

    Literally days before this announcement I needed a private repository for a new project, and registered a Bitbucket account for that. Haven't migrated back yet, but probably will GitHub provides free private repositories for max 3 collaborators, while Bitbucket has a limit of 5 collaborators for a free private repository. Not a huge difference... unless, of course, you're running a team of 4-5 developers and want to save a few bucks
  6. teppo

    By the way, I was just wondering what might be the recommended alternative to defining custom API variables (particularly by modules) for the Functions API? Is there one? I for one have found these very useful, as they provide a way for module authors to add developer features that feel consistent with the "native" API. In case custom API variables are only feasible with the non-Functions API, then perhaps that should be documented as well; or am I just overthinking this?
  7. teppo

    Correction to this: in the blog post Ryan mentions the wire-prefixed Functions API methods and explains that they have the benefit of being always available regardless of config settings (essentially the same thing that the comments in the FunctionsWireAPI.php file say) – but there is a comment to the blog post in which he mentions that these are actually "for an internal core purpose". @ryan, this might be one of the things that should be clarified somewhere: if wire-versions of the Functions API methods are indeed not intended for public use, it should probably be mentioned somewhere (other than a single comment to the Functions API announcement blog post). If one reads the blog post and doesn't check all the comments, or checks the code / code comments directly (which is a common thing to do in our context), this is currently not obvious.
  8. teppo

    Right – I might've misunderstood those posts, thought you were referring to the demo site. Probably just me not paying enough attention I've been doing JS related work recently, and found it really helpful how some libraries provide these interactive code blocks on promo sites and/or docs: "here's our example, here's what it does – try modifying it and see how that'll change things." Another use case are incomplete (or even empty) code blocks urging the user to figure out how to produce some predefined output from them. Personally I dislike learning from docs alone, so this approach provides the best of both worlds: docs so I don't feel like I have to figure everything out myself, and editable/executable code to give me the opportunity to learn things by doing (and making mistakes along the way) Now that you mention this, I've done that on a few occasions too. While this may be a bit of an edge case, it's a good example of how something that may seems like an issue at first (overriding API variables by accident) can also be a good thing once you know what you're doing (By the way, it seems that the wire-prefixed versions of these were missing from those lists of "all the different ways to access one API variable". Not sure how often people actually use wirePage() etc... but they've probably found their way to some projects out there. And, as is explained in the blog post introducing Functions API and in the FunctionsWireAPI.php file, this version has the advantage (over regular Functions API) of always being available.)
  9. teppo

    I've been following this topic from the sidelines with mixed feelings. I've always considered ProcessWire's API exceptionally clean and easy to understand, and technically that hasn't changed, but I do find it confusing as well that there are so many ways to achieve essentially the same thing – except that some will only work on certain situations (bootstrap, templates, modules, multi-instance, ...) or may have performance benefits or perhaps won't be available on all sites depending on config settings, etc. I'm very eager to hear what you've got to say about this, and I'm hoping that it'll make everything crystal clear again --- Either way, the tab idea (different approaches in different tabs) is, in my opinion, awesome. Combined with per-tab instructions on where and how to use each approach (could be a tooltip with short summary and a link to full documentation page) this would be a huge improvement. If functions API calls are shorter, then show those by default – it won't take anything away from the marketing / functions API promotion perspective, and it may in fact give users a better understanding of what they're missing if they're not using the functions API. --- On a completely different topic, one thing I've been wondering is if it would make sense to provide some kind of "interactive editor" for the API features – "tweak the code and see the result here". I know, ProcessWire isn't a JavaScript app, and the API has loads of stuff that wouldn't make any sense to implement in JavaScript, but perhaps as some kind of a virtual box (not sure how one would set that up securely, though) or a limited scope JavaScript mock API with a set of mock data behind it? Just an idea for now.
  10. I don't think that there's an existing feature for this, but even if you could do this, I would still suggest not doing it. Usually it would be a better idea to display a smaller image in a bigger size in the front-end, rather than to make the end-user download a bigger image with essentially the same content
  11. teppo

    @flydev, thanks for linking that thread – I had already forgotten the whole thing. Will come in handy for a project I'm currently working on That being said, TDD or test-driven development is a pretty specific process: essentially you define what the app should do (success criteria), create tests based on that, and finally write code to fulfil those tests. Iterate this until you have a complete application. I haven't heard anyone developing ProcessWire stuff like that, but technically it's doable, although it obviously depends a lot on what you're actually building with ProcessWire. For most sites out there I'd argue that TDD probably isn't the easiest thing to pull off, or perhaps even the most sensible approach. In my opinion it's more suitable to application development. The front-end layer alone adds loads of complexity to the equation. I'd love to hear if anyone is actually doing this in our context though
  12. teppo

    This part sounds somewhat curious. HTTP 1.1 request to /processwire (seems to work), then HTTP 2.0 request to /processwire/login (doesn't work) – is it possible that the server is not properly configured to handle HTTP/2? What happens if you directly request /processwire/login/, i.e. type it to the address bar instead of /processwire/? Also, just to clarify: when you enter /processwire/ you get the error for /processwire/login/ right away? You didn't even see the inputs for username and password? If so, it might also be that there's something in the site or browser cache that breaks things. If your site is using default session management, i.e. files on the disk, you could start by clearing /site/assets/sessions/ of any session files currently in there. Also make sure that there's nothing odd in your browser cache by clearing that as well, or opening the admin in an incognito tab or something similar. If you've enabled database sessions, you'd probably have to clear them manually from the related database table (haven't used this feature, so not sure how exactly). By the way, the certificate error doesn't sound too good either. Did you have a certificate set up on the old server, and can you set up one on the new one as well? Although this seems unlikely, one possibility is that the server isn't properly serving HTTPS content. This is somewhat off-topic, but it seems really strange that a hosting company (assuming that this is the case) moves the site to a new server without informing you, and without providing proper support, or even making sure that things work as expected after the move. When that kind of thing happens, you might be better off looking for a new hosting provider. Just saying.
  13. teppo

    Here's another example from the VersionControlTests package: https://github.com/teppokoivula/VersionControlTests/blob/master/tests/VersionControlTest.php#L170:L179. It's in a PHPUnit test class so the syntax is a bit strange, but at least the last time I ran the tests this worked (though that was against PW 2.x.)
  14. teppo

    Sadly I don't have an answer to the issue raised here, as I have only just started to play with ProcessWire and Docker, but I've got a very similar setup on a MacBook Pro (4 GB RAM and 6 CPU) for WordPress development – and I have to say that it's often painfully slow. This does seem to be a relatively common problem, at least for Mac users. That being said, I'm running a fairly non-standard and complex WordPress stack, so it may strictly speaking be something other than the WP core which is the root cause – ACF or any of the other plugins, something in the theme, etc.
  15. teppo

    Thanks – I can see definite improvements already, and we can surely keep improving things after the initial launch as well! Regarding the target group I get what you're saying, but it's good to keep in mind that improved accessibility actually benefits us all – it's not (just) about catering for users with disabilities "While accessibility focuses on people with disabilities, many accessibility requirements also improve usability for everyone. Accessibility especially benefits people without disabilities who are in limiting situations, such as using the web on a mobile phone when visual attention is elsewhere, in bright sunlight, in a dark room, in a quiet environment, in a noisy environment, and in an emergency." (W3C WAI) My eyesight is way below average, and I can see a lot of artefacts and other signs of low quality in there. Just checking, but do you have a retina screen? Could be somehow related to resolution as well – I've got a 15" MacBook Pro with resolution set to "scaled" and "more space" set to the maximum value.
  16. teppo

    +1, forgot to mention this one. WCAG AAA requires that line length is never more than 80 characters, but depending on the source comfortable range can be around 80..100 characters, and sometimes as high as 120. Anything above that is way too long considering readability, and I'd recommend not going past the 100 character (or glyph) mark.
  17. teppo

    +1 to giving contrast more consideration. Overall the site could use a bit of brushing up in terms of accessibility – some quick observations: Providing a skip to main content link would be nice, and while we're at it, providing another one for certain long lists of items (such as the showcase items) could also be a good idea. At least on the home page the logo icon and the text next to it are separate links, but still lead to the same location – I'd recommend hiding one of them from keyboard / screen reader users. There are no focus styles for the top navigation, so keyboard navigation feels quite strange; the cursor seems to simply disappear somewhere. The search icon doesn't seem to have label for screen readers to read, so it's just "link: newsite". Same thing with the close icon for the search. One more keyboard navigation issue occurs once I reach the showcase section: again the cursor disappears, and I actually have to browse all items (even though visually nothing changes on the screen) before it reappears. This might've been mentioned already, but I for one keep getting the "home" link wrong, since (in some cases) the text link right next (which is visually connected to the logo and thus I would've expected it to lead to the home page as well) takes me somewhere else. This is one of those "oh, I see what you did there" cases: now that I've clicked the wrong link a couple of times I know how it works, but surprises like that don't exactly improve the overall experience Additionally I find it very confusing that the navigation hierarchy doesn't match content structure. For an example, if I choose "Docs" > "API Reference" from the navigation, I'm suddenly taken to another area of the site – and probably for that reason there's also no indication about where I currently am in the top navigation, since this new area isn't included in the navigation, even though it's hierarchically a top level page. Finally, I would recommend adding some sort of indication to navigation links that take the user out of current site. "Community" for an example is (a bit weirdly, in my opinion) linked to the Forum, which may come as a surprise to the visitor. I've always instructed clients to never, ever link to another site from their top navigation – but if we really have to do that, at least we should make it obvious what's happening .. and all that said, this is definitely an upgrade to the old site. Sure, there are rough edges, and I must agree with a lot that has been said in this topic, but I'm sure we'll figure it out. Great job, Ryan!
  18. teppo

    As a one-off example of putting Sanitizer to work, I'm currently working on a module in which I convert template names to pascal case class names, so recently added $sanitizer->pascalCase() came in handy there. On the other hand, $sanitizer->pageName(), $sanitizer->selectorField(), and $sanitizer->selectorValue() are probably what I've used the most. Even if I know that ProcessWire has some sort of validation built-in, I much prefer to filter data before passing it to ProcessWire: not only does this provide an extra layer of safety, but it also allows me to display more helpful error messages to the end-user. $sanitizer->option() and $sanitizer->options() are also useful. They're basically shortcut methods to whitelisting values, and who doesn't need a whitelist every now and then? Some Sanitizer features are more about formatting, really: $sanitizer->truncate() is a good example of this, as it's basically creates excerpts of longer text. Definitely useful. All in all, it really depends on what you're doing with ProcessWire, where you're getting your input, and so on. If you're handling raw user input a lot, Sanitizer is particularly useful. Similarly if you tend to enforce more specific rules for your data (say, only allow specific values, or specific characters, etc.) you can get a lot out of Sanitizer. Personally I'm also a firm believer in the "defence in depth" practice: can't have too many layers of protection By the way, in your code you mention that Inputfields run Sanitizer methods. It's probably worth noting that Inputfields won't interfere while you're storing data over the API, and thus they won't prevent anything from being saved to the database either. Fieldtypes handle data storage, and Inputfield settings kick in when you edit that value in the Admin.
  19. teppo

    First of all, I would recommend reconsidering your approach. ProcessWire's built-in admin is quite user-friendly, and building essentially the same thing on your own sounds like a lot of effort that you could use for something more beneficial. Not to mention that you'll have to be pretty careful to avoid any permission related issues etc. – all in all not something I would recommend unless you've got a really good reason for it. The answers to your questions, if you still choose to go this route, would depend on your needs: do you have multiple types of users with different fields, or are they all the same? What will these users edit – their own profile page, or something else? If it's their profile page, should it be publicly viewable? If not, how are you planning to control access – on a page by page basis, or based on groups, or something else entirely? ProcessWire supports multiple parents/templates for user pages, so that might be something you could look into: https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-templates-or-parents-for-users. Hope this helps a bit.
  20. teppo

    Textformatter for Google Maps https://github.com/teppokoivula/TextformatterGoogleMaps This module looks for Google Maps URLs (such as https://maps.google.fi/maps?safe=off&ie=UTF-8&q=disneyland,+paris) within paragraph (<p></p>) HTML tags and automatically converts them to embedded maps. Configurable options include embed type ("static" or "iframe"), API key, responsive embedding and Google Maps for Business settings. Other than that, it's pretty basic stuff. Original regexp for grabbing maps links was posted by Ryan (I believe) here on the forums, but I couldn't find that post anymore. I've altered it to better suit the needs of this module, added some configurable features (part of which, such as makeResponsive() method, are again based on Ryan's TextformatterVideoEmbed module) and so on. Hope someone finds it useful. (By the way: if you're going to use Google Maps for Business settings, please read the notes there carefully. Google doesn't exactly recommend storing your private key the way module settings are stored..)
  21. teppo

    $config->httpHost should return current domain (if it's included in the httpHosts setting) or the first domain from said setting if no match was found. Here's the related code for reference: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/ProcessWire.php#L308-L323. If you're accessing your site with the dev domain and this domain is included in the httpHosts setting, that should be what this method returns. If not, I'd make sure that related settings are properly configured, and that your server works as expected (particularly in terms of SERVER_NAME and/or HTTP_HOST). I'm not entirely sure what you're referring to with the "edit multiple URLs in the code" part, but generally speaking I'd recommend using relative paths etc. instead of fully qualified domains. This way it doesn't really matter which domain you access your site from. It's possible that you were actually referring to something else, so feel free to clarify this part Edit: actually there's one more thing to keep in mind here, which is that ProcessWire prefers the ServerName value from the Apache VirtualHost block ($_SERVER['SERVER_NAME']) over the host header provided by the browser ($_SERVER['HTTP_HOST']) when determining httpHost. ServerName is used at least if Apache "UseCanonicalName" setting is "on", but this behaviour may apparently vary between different Apache versions. In this case the solution would be either disabling the UseCanonicalName setting, or creating separate VirtualHost blocks for all domains you want to use with ProcessWire.
  22. That isn't actually necessary; Process module execute methods don't have to be hookable. (Gadgetto, in case you haven't yet looked into the hook system, three underscores are only required if you want to make the function hookable – i.e. allow code in template files, modules, init.php / ready.php files within site directory, etc. to "hook" into their execution. Otherwise it's fine to leave them out.) On a loosely related note, you also don't have to set up your own PHP version comparison. You can define required PHP version with the "requires" setting
  23. Sorry to answer a question with another question, but is there a specific reason you want subscribers to be users? You mentioned being able to use the MODX permission system, but what do you use it for? While there's no technical reason why you couldn't make your subscribers ProcessWire users, the reason I'm asking is that unless there's a solid reason for it, I'd recommend not going that route. You'd essentially have to build an open registration system, where anyone can create new user accounts. While that isn't necessarily a problem in itself, coupled with any kind of permission related issue things could get very ugly very fast. That being said, depending on your needs you could use users, or you could create a custom template for your subscribers, or you could even create your own database table(s) – though that last option would likely not be preferable, considering that you wouldn't be able to benefit from ProcessWire's API. Whether you go with a custom template or choose to build upon built-in system users, I'd recommend looking into $pages->findMany(). Thousands of users / pages shouldn't be an issue.
  24. teppo

    I'm not sure if it's still applicable, but there's an old module as well: https://modules.processwire.com/modules/pageimage-remove-variations/. Although I'm guessing that @horst already knew about it...
  25. teppo

    Old discussion, but yeah – the plus sides of this kind of naming are that 1) it's a common practice across different systems (which makes it easy for new devs to grasp), and 2) that it's a very commonly typed function – not to mention one that you often see in front-end (or "view") part of a site or an app, and thus it's good to keep it nice and short . Expanding on the second point a bit, in the view side it often makes sense to have short function names, even if they're not particularly descriptive. Think of PHP's short echo tags (<?= ... ?>) or various tags implemented by templating languages: the point is to create minimal clutter, thus keeping view files clean and easy to follow --- Note: this thread is not related to module development per se, so I'm moving it to the Getting Started area of the forum.