• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. Hey @MischaK, just wanted to say thanks for going through the trouble of explaining your findings here. Very much appreciated I'm also glad to hear that there's still demand for versioning the content. I originally developed the Version Control module when we were in the process of migrating from an earlier, in-house CMS to ProcessWire. Since our old system had extensive versioning system built-in I thought it'd be a necessity for the new system as well, but at this point I'm ready to admit that I might've been somewhat misguided. It's been years since that migration started, and so far I've had a handful of clients request some method of content versioning. The times I've had to solve an issue where content was accidentally removed and couldn't be found anywhere can be counted on fingers of one hand – and yes, we've dealt with some pretty big sites. Talking about dozens of content editors and thousands of pages of content. My conclusion at this point is that it's rarely a real necessity to have content versioning in a CMS, but you're absolutely right that it's a great safety net to have. I guess it's also more important (and more useful) for users that are already used to having it in, say, a system they've used before. Kind of like how you see devs build software without any kind of version control system in place: to me it seems like a horrible nightmare, but they don't know any better – and if they've been doing that for a while already, they've probably developed other approaches to versioning or backing up their work
  2. teppo

    @zoeck, it seems that you're talking about the issues caused by jQuery incompatibilities: currently the front-end editor doesn't play well with jQuery 3.x. That's a real issue, and it needs to be addressed. That being said, front-end editing is a difficult topic. That's one border case where ProcessWire really has to step into the "developer's domain", i.e. inject it's own features (scripts, perhaps even styles) into the front-end of the site. So far I think it's been handled relatively well, but it's no surprise that some issues are going to surface. I'd give it some time. We'll get there, eventually. Also: if you don't want the backend system (ProcessWire in this case) to touch anything at all in the front-end of your site, you should probably steer away from front-end editing altogether. As the name says, it's a front-end feature — and as such, using it is completely optional
  3. 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.
  4. teppo

    Just noticed that ProcessWire is listed at the new RedBeanPHP website's "frameworks" page, with a link to this module: https://www.redbeanphp.com/index.php?p=/frameworks. On a related note I should probably update this module to a newer version of RedBeanPHP
  5. Seems to me that built-in approach requires domains, which of course can be temporary/fake/local domains and not real ones. If you google something like "xampp custom domains" you'll find a few articles / threads on this, but general process involves editing your hosts file (whatever that is called in Windows) and adding these domains to Apache (via VirtualHost block somewhere, unless there's a GUI for this in XAMPP). Best practice seems to be using .test domains for local development, i.e. site1.test etc. ProcessWire doesn't care that much about which domain you use, so having multiple rules ('site1.test' => 'site', 'site1.com' => 'test') shouldn't be an issue, but alternatively you could add some kind of test (ENV?) to choose which domain to pick.
  6. It's my first post in this area and this barely validates as a "showcase case", but: I've finally managed to update my own Web presence, resulting in flamingruby.com. It's primarily a blog, but some of my projects are on display there too. This site has actually been up for months already -- wasn't going to post it here, but thought it'd be nice to prove that I've actually built something with PW after all.. Being responsive is fairly standard stuff these days. In this case no frameworks were involved, though; it's all hand-made, built from mobile first perspective and based on content alone, instead of predefined breakpoints. Some details I'm still not happy about, so it'll probably get tweaked every now and then, but at the moment things are pretty much in a stable state. Since it's a personal project, I've been slowly adding small tricks here and there, none of which really count as anything "special." One addition made just today, mostly as a proof-of-concept, is a combination of a simple module and new subdomain (static.flamingruby.com) to automatically serve assets from (at least in theory) cookie-free location. This is described in more detail here. For home page I built an importer module (with AngularJS GUI, which was actually quite fun) that periodically pulls content from various feeds.. a bit like what Nico did with his social timeline, but nowhere as cool as that. At the moment content is being pulled from GitHub (for which I had to put together MarkupLoadAtom) and Twitter (which kindly killed it's RSS support just in time, so I'm using rssitfor.me instead.. although that site interestingly spits out Atom and not RSS like one would expect.) That's just about it.
  7. teppo

    This module was already introduced in another thread yesterday, but since each module should have a thread of its own, here we go. Login Scheduler adds a couple of new fields to user template(s) and provides support for disabling login for non-superuser accounts either instantly (with a checkbox, "Login disabled") or by specifying a time range ("Login allowed starting from", "Login allowed until"). If a user is already logged in when login access is disabled, logout should be triggered during next session validity check (usually next page load). Starting from version 1.1.0, superuser accounts are not affected by this module at all. This is a safety mechanism and prevents you from locking yourself out of the whole system. You can grab this module from GitHub: https://github.com/teppokoivula/LoginScheduler.
  8. teppo

    @thlinna, could you specify what kind of issues you were experiencing? I've just installed this on a PW 3.0.118 site, and so far no luck: the module installs as expected, fields show up in user editor, and a user with login_disabled checked cannot log in or use the admin. The module wasn't exactly verbose about what it was doing during install/uninstall, so I'll push a new version that lists fields and template(s) affected during both install and uninstall. Other than that this version doesn't really change anything, since I'm not seeing any issues here yet
  9. 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.
  10. teppo

    Hey @adrian and @zoeck, Sorry for not responding to this – I've been kind of tied elsewhere, and totally forgot this question. Bad excuse for bad communication, I know I'll have to dig into this. I didn't intentionally strip any features from 2.0, but it's entirely possible that something in Admin Theme Uikit (assuming that you're using that) or the updates I did for 2.0 did indeed disable Repeater Matrix support. I had to put the development of this module on hold since there were some difficult (or at least time-consuming) UI issues to tackle, and I just didn't have the bandwidth for that. I'll do my best to try to find some time soon(ish). Sorry, but can't really promise any kind of timeframe right now.
  11. teppo

    Hey @thlinna, thanks for the report. I'll schedule some maintenance time to later today
  12. Note: this topic was moved to the "Module/Plugin Development" subforum. "Modules/Plugins" area is intended for support threads of existing modules, and any module development related questions or discussions belong here
  13. teppo

    Note: I've just moved this topic to the "General Support" section of the forum. Since this is a core module thing, it doesn't really belong to the Modules support area
  14. teppo

    Hey @LAPS! Sorry, I can't really help you with your issue, but wanted to mention that I've merged your question into the Pages2PDF support thread. Module-related questions should be posted to appropriate support threads whenever possible. This keeps things nice and clean on the forum side, and it's also the best way to get answers
  15. Another "me too" from here. In fact when @apeisa first introduced me to ProcessWire, I wasn't that enthusiastic about it (some things about templates and fields just didn't seem to make sense), but having Ryan walk you through all that was a real game changer. We could use an updated video, though
  16. Got to agree: there are a number of ways to get past this, but I'd argue that it's less about the syntax itself, and more about the way you structure your templates. In my case (and yes, this is a shameless plug) I'm using pw-mvc so that I can move anything I see as "code" to a separate controller file, and only include simplest loops and output statements on the view side. Sure, this project doesn't force any such restraints, but as a general rule of thumb I try to make my views as "dumb" as possible: as long as they have absolutely no idea how variables they output are generated, they a) remain clean and b) I can easily modify just the view, or just the controller. One way to handle structures that need a bit of pre-processing is to loop through $projects twice: once in the controller, where you store just the required fields (formatted to your liking) in an array, which you then pass to the view, where you iterate over it second time. Two loops is not optimal in terms of performance, but typically the performance hit is questionable at best, and this approach can make your view files much cleaner. Another approach I like to implement are separate render-functions: renderThumb(), renderNewsBlock(), renderHighlight(), etc. Depending on the project I often include a common functions.php file with these functions somewhere before markup is generated, and then abstract any complex, repeatable stuff there. Sure, that way you're kind of mixing HTML with code as well (in functions.php), but your views remain nice and clean
  17. It's common sense to name things based on meaning -- search, sitemap, home, basic-page / default etc. -- but I'm interested in hearing if you folks are defining / following more specific rules than these. This is something I've been thinking quite a bit lately and unfortunately I feel a bit lost here. IMHO this becomes an important thing especially when you have multiple developers working on / providing support for same projects, which they aren't necessary familiar with. It's one of those things that make it easier for a new developer to jump on board of a project and instantly understand what's happening under the hood (or at least make educated guesses.) So after this (longish) explanation, I'd really love to hear what you think about this subject -- what kind of naming conventions do you apply for your templates and/or fields? (If any.)
  18. If you pasted that code here as-is, the issue seems to be that there's an extra space after self::new – it should be "self::new($items)" and not "self::new ($items)". A FileCompiler issue, perhaps? Could also try manually replacing /wire/core/WireArray.php with the one found from GitHub, just in case. Ping @ryan
  19. I know you already rest your case, but still wanted to point out that Uikit is actually very configurable, meaning that you can pick and choose the components you need. You don't have to include the full framework, and when using SASS or LESS you can easily recompile the framework at any time. There's also another thing that in my opinion makes it a great fit for ProcessWire: Uikit also includes the concept of hooks. You quite literally modify it the same way as you'd modify ProcessWire. The point behind front-end frameworks is that you don't have to reinvent the wheel every single time. In most cases our grids, carousels, cards, and whatnot are not really that different from project to project. Sure, they are styled differently, and may even behave differently, but the basic structure and function is similar. So, why write a new component every single time when you can reuse the old structure/behaviour and just give it a brand new bespoke look and feel? What you're essentially claiming is that every Uikit site looks the same (or requires a lot of hacks to not), yet I disagree. Again if you take an out-of-the-box version of Uikit and use the ready-made default theme (you did notice that using it is completely optional, right?) then yes, it's going to look like... well, an out-of-the-box Uikit with a ready-made theme. Just don't do that, and you'll be fine. Yes, with a framework there will always be some amount of configuration and hooking/overwriting involved, but that's a small price for the benefits you reap. For arguments sake: if we thought that all pre-made components were pure evil, we shouldn't be using ProcessWire either. ProcessWire doesn't dictate your sites look and feel, but it sets a baseline for how it'll work behind the scenes. Uikit does the same for the front-end. Both are easily configurable and modifiable. One might even go as far as say that they are natural allies – two parts of a whole. For the record, before writing this post I was not fully convinced of Uikit: I've been using Foundation, which in my opinion is superior in many ways, and has a rather different method of modification – essentially a massive config file for modifying pretty much every single thing you can imagine. But diving into the Uikit docs made me like it a lot more, and not least so because it really does have certain similarities with ProcessWire itself. In short: Uikit is a great choice for the new processwire.com.
  20. teppo

    You don't necessarily have to change that approach with ProcessWire I've done a few projects with a similar setup, and the easiest method (in my opinion) is to use either sessions (if you're happy to involve PHP in this) or cookies (for a JavaScript only solution) to keep track of the products that were added to cart: When "Add to cart" (or whatever you call it) button is clicked, use JavaScript to add product info to cookie or submit an AJAX request to a PHP based processor in which you sanitise and store product details in PHP session. Note: if you use a PHP processor, you might want to consider making that button a form submit with product ID / details as a hidden text field. This way even if the user doesn't have JavaScript available/enabled, you'll still be able to process the request. When the user reaches the order form, autofill a hidden field (textarea) with contents of the cart. I've handled this part with FormBuilder forms, but obviously you can use a custom form as well. As long as you're essentially just sending a list of selected product names, sanitising data is a simple task, and even if someone does figure out the "hidden form field" trick and goes on to modify the data manually, there's no real harm in that. Or you can just leave that field visible , if it's fine that the client adds more details before sending the enquiry – or perhaps even replace it with a neater UI. Hope this helps a bit.
  21. teppo

    This is an old thread, but just wanted to point out at least one major benefit of Slack: it is extremely popular among web devs. IRC is obviously popular as well, but – and this is just my opinion, so take it with a grain of salt – mostly among folks who've been using it for a long time, and of course those who've got a problem with using proprietary platforms in general. In my experience new users tend to very much prefer the slick interface and easy setup of Slack, and since a lot of us are already using Slack for in-company stuff, client communication, and even for other (open source) projects, it'd be easier if ProcessWire had an official Slack workplace as well. In some ways it's the same question as for why use GitHub even when there are decent (and even more powerful) free/open alternatives: because it makes ProcessWire easier to approach for new users. Because that's where the users are, and that's how they find us. At least that's how I see it (Note: I've been an IRC user since the 90's, although not so much during recent years, so in my case it's not that I can't use IRC. It's just that all my other dev-related discussions currently happen in Slack, and I'm not too keen on getting back to IRC. I guess I've grown accustomed to what Slack is and how it works, and I see a host of benefits in it.)
  22. teppo

    Hey Thomas, Thanks for this module, looks really interesting, and I'm looking forward to giving it a go. Just a quick comment on this part of the README: I think that a configurable endpoint name would definitely be a worthwhile option – or if that turns out to be difficult, perhaps you might want to consider something slightly more descriptive, such as /rest-api/ or something? To be completely honest I'm being a bit selfish here: I've got the bad habit of using /api/ for any site-specific API implementations I might need, and that would pose an issue for this particular module Reminds me of the "two hard things in computer science" thing. This thread already covers both: cache (well, token...) invalidation and naming things
  23. teppo

    Great read! A bit off topic (hey, this is the pub) but this is part of the reason why I love reading about old-school software development, and game development in particular. You know, when folks had to figure out how to run complex software while dealing with various limitations – such as being limited to something between 32 and 64 KB of memory in total. Good times. For the record, there are some awesome videos about old school development and hardware at YouTube by user The 8-Bit Guy. Not only does he clearly know his "old-school" computers inside out, he has also released amazingly polished new games for old hardware
  24. teppo

    From a core development perspective I'm going to agree with this – but while the core probably shouldn't include a pre-built, "full featured" page builder (at least for the time being, since no one really knows what the future holds), there's no reason why third parties should be discouraged to create such tools. I also know for a fact that there'd be a market for that
  25. Hey @pwired The point is that when you do this ... <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item): ?> <li><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> </ul> ... it looks a bit cleaner (as in "less like code mixed with markup") than doing something like this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { echo "<li><a href='" . $item->url . "'>" . $item->title . "</a></li>"; } ?> </ul> ... or this: <ul> <?php foreach ($pages->find("template=news-item, limit=5, sort=created") as $item) { ?> <li><a href="<?php echo $item->url; ?>"><?php echo $item->title; ?></a></li> <?php } ?> </ul> I wouldn't say that there's anything wrong with using selectors within template files, although personally I try to avoid even that when possible. What we're discussing here is simply the syntax used in template files: if you use "full-blown", especially multiline <?php ... ?> code blocks it can seem like you're mixing view side (markup) with business logic (code) even if you're not. On the other hand (probably not what you meant, but just to clarify) if you're wondering why business logic and markup should be separated in the first place, there are a number of reasons to do that. In my case the biggest benefits are a) the ability to alter data structure (model), business logic, or representation (markup) without touching other parts of the site or app, and b) the ability to switch entire view – or use multiple views simultaneously – without having to duplicate any actual "code". (There's a sh*tload of stuff about this in the web, so I won't go into too much detail here. Just google "separation of concerns".) --- Slightly off-topic, but regarding selector use within markup, and why I personally prefer to avoid that: this is in part because in my opinion it looks cleaner, but also because this way I can tweak template names, data structures, etc. without having to modify my views at all. This in turn becomes more useful when you have multiple views for the same data. So, once again, "depends on the use case"