teppo

PW-Moderators
  • Content Count

    2,179
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by teppo

  1. teppo

    Actually I would recommend posting this as a GitHub issue. It's not really a "problem" per se, but I also don't see any point in storing all those decimals, so they're just unnecessary clutter. Hard to say if Ryan will consider it worth acting on though
  2. teppo

    Well, it might be technically possible, but there's no core support for it, and I wouldn't recommend it In this case you would probably have to modify index.php, .htaccess, and at least some other core files: wire/core/ProcessWire.php, wire/modules/Process/ProcessLogin/ProcessLogin.module, and wire/modules/Process/ProcessPageView.module. Modifying core files is never a good idea, as it makes updating ProcessWire difficult (usually you can just replace certain core files and that's it), and there's also no guarantee that some third party module etc. isn't expecting the core to remain as-is. So, long story short: if you really have to, you can of course modify it, but there's no guarantee that things will work as expected afterwards. If possible, I'd recommend developing the ProcessWire site elsewhere (subdirectory, or another domain, or locally) and then replacing the old site in one go.
  3. Hey @adrian. Just wondering if this thread might've served it's purpose already, or do we still want to keep it pinned to the Modules/Plugins area? I'd say that it's been long enough, but it's your call
  4. teppo

    Moderator note: the "Modules/Plugins" forum section of the support forum is intended for module-specific support threads only, so I've moved this thread to the "General Support" section instead.
  5. This module tracks changes, additions, removals etc. of public (as in "not under admin") pages of your site. Like it's name says, it doesn't attempt to be a version control system or anything like that - just a log of what's happened. At the moment it's still a work in progress and will most likely be a victim of many ruthless this-won't-work-let's-try-that-instead cycles, but I believe I've nailed basic functionality well enough to post it here.. so, once again, I'll be happy to hear any comments you folks can provide http://modules.processwire.com/modules/process-changelog/ https://github.com/teppokoivula/ProcessChangelog How does it work? Exactly like it's (sort of) predecessor, Process Changelog actually consists of two modules: Process Changelog and Process Changelog Hooks. Hooks module exists only to serve main module by hooking into various functions within Pages class, collecting data of performed operations, refining it and keeping up a log of events in it's own custom database table (process_changelog.) Visible part is managed by Process Changelog, which provides users a (relatively) pretty view of the contents of said log table. How do you use it? When installed this module adds new page called Changelog under Admin > Setup which provides you with a table view of collected data and basic filtering tools See attached screenshots to get a general idea about what that page should look like after a while. For detailed installation instructions etc. see README.md.
  6. teppo

    This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.
  7. teppo

    RedBeanPHP is a simple and easy-to-use ORM, and this module is a lightweight ProcessWire wrapper and/or loader for it. The main task of the module is loading and setting up RedBeanPHP with database credentials from $config. There are some config settings for defining how RedBeanPHP should behave, and the module also exposes some often-used methods, but that's just about it. For more details (including a rant about why one might prefer separate ORM in some cases), take a look at the README file. Please note that, for almost all use cases, the data modeling features of ProcessWire are much better choice than a separate database structure of your own, but in those rare cases where that's not the situation, it's good to have options. This module was a side product of one of my own projects, and I thought I might as well share it with you folks. You can grab the module from GitHub: https://github.com/teppokoivula/RedBeanPHP.
  8. teppo

    Quick update: version 2.0.0 of this module is now available via GitHub. This version includes updated RedBeanPHP library, various new config settings (including the ability to disable automatic setup of RedBeanPHP, and an option for choosing one of the trimmed down library versions with support for specific database type only), and various other updates to the module. I've also dropped support for PW 2.x and PHP < 5.4, and updated module requirements accordingly. For pre-3.x or pre-PHP 5.4 users the legacy branch still contains old version of the module.
  9. teppo

    Hey @ryan. I'm wondering if it would be possible to set up a repository for the new site, so that we could submit pull requests and report issues there? Personally I'd still like to suggest some usability / accessibility related changes and fixes, but currently that's a bit difficult to do – and it basically requires me reporting the issue, and then you having to figure out how to fix it for the site. If there was a repository, we could a) reliably keep track of issues that have been fixed or closed for other reasons (avoiding duplicate reports), b) submit changes so that you don't have to do everything yourself, and c) experiment with the site with ease. If the site has features that can't be made public, a repository containing partial site profile would of course do, but the best solution would imho be a full site that we can install locally, makes changes to, build, test for regressions, and so on. Or perhaps you could only share access on a case-by-case basis, since even GitHub now supports private repositories? Thanks for considering this!
  10. teppo

    I'm probably a well-known nay-sayer around here already, but I'm still going to add my +1 to this discussion. I feel that (particularly when it comes to API design) one clean and consistent solution should be preferred, unless an alternative approach provides major benefits. Multiple options only tend to make things more fragmented and more difficult to grasp, and doubly so when you're a new user. As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added. Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x. There are, and always will be, features that should be added to the core (shameless plug: FiedltypeDecimal), but on the other hand alternatives without major benefits or major user base, and modules that may not be particularly often-used should, in my opinion, be stripped out. A module I've been working on recently has an "alias" feature (that isn't even that important to the module, to tell the truth), which was getting way out of hand. You could provide its arguments in five different formats, at least, which all required their own handler methods. I was working on this feature on Sunday (once again), and finally got fed up with it, stripped all those alternatives out and replaced them with one unified solution: callbacks. Sure, a bit of syntactic sugar might've been lost in the process, but I also got rid of probably 75% of the required code, and the documentation page is now actually readable. So, yeah – I know exactly what you're talking about
  11. teppo

    Hi @Guy Verville. I took a quick look at TemplateEngineFactory.module.php, and this is what I've found out so far: Preview feature is essentially a couple of lines of code in ProcessVersionControl.module. Since we're doing this in an execute method of a Process module, current page is under admin area, and has template "admin". Before we even get to the preview method, autoload modules have already run their course. TemplateEngineFactory initiates itself in a ready() method, and bails out early if current template is "admin", which means that its features won't be available for us. Without modifying TemplateEngineFactory itself, I currently see two options: reworking the preview feature to do something else (though not quite sure what.. perhaps it could define a custom template or something like that), or trying to overwrite current page (to fix the $this->wire('page') reference in TemplateEngineFactory.module.) Latter option sounds more feasible, yet I'd have to test this properly to make sure. I don't have a proper setup for that available right now, but I'll see if I can get to that sometime soon. That being said, if you could provide me a stripped down site profile to test this with, that'd make things easier for me
  12. teppo

    That's a nice find, and I believe that a tool like this would indeed be a nice addition for users that don't generally require a screen reader. That being said, those who do require such assistive technology will already most likely have their own individual setups, and a separate tool won't really help – so the accessibility argument is somewhat questionable. Perhaps even misguided, since it may give some folks an impression that this is enough to take care of all screen reader related accessibility needs. Accessibility, particularly referring to screen reader users, is not just about enabling "text-to-speech voice for the relevant content" (at least the way I understand their selling point), but rather about making sure that the entire user experience takes screen reader users into account. In other words: providing a read-out-loud button for the main content is not enough, if some users can't even navigate the site with ease
  13. Hey @J_Szwarga! Is this related to the FormBuilder module? If so, you should really be asking this on the VIP support area. If you've bought FormBuilder, you should have access there – and if not, you should contact @ryan. I don't have an answer to your question, but perhaps someone else will be able to chime in, here or on the VIP support area. Note: the "Modules/Plugins" area of the forum is for dedicated module support threads only, so I'm moving this post to the "General Support" area of the forum.
  14. teppo

    Please be a bit more specific. Why is this so important to you, and how would you envision it being implemented in the context of ProcessWire? Have you considered the possible solutions mentioned in this thread, and if so, what made you decide that they are not good enough? We're always happy to discuss new ideas and suggestions, but on the off chance that you're only posting these things in order to cause an argument, be aware that such behaviour won't be tolerated here. Thanks for giving your posts a bit more consideration from now on, and have a great day!
  15. 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
  16. 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.
  17. 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?
  18. 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
  19. 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
  20. 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?
  21. 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.
  22. 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.)
  23. 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.
  24. 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
  25. 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