• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. teppo

    Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be. I'd say that unless you've got a very good reason not to extend WireMail, you really should. That being said, thanks for your work on this module.
  2. Sounds to me like there's a bit of a misunderstanding here. First of all, fields are connected to templates (home, basic-page, etc.) and field values are applicable to pages using that template, so technically there's no such thing as a field with the same global value everywhere. You can solve this in a different way, though. Taking a step back, what you originally asked for was ... The easiest way to achieve this would be adding those fields to an existing template – such as "home" – and filling in the values for a page using that template – in this case your home page. Then you can do something along these lines in your _foot.php file: <?php echo $pages->get(1)->footer1; ?> In other words you can fetch a specific page ("1" in this case means the page with ID 1, i.e. your home page) and then output the value of the field ("footer1") from that page. From what you've written above, it sounds like you might've created a new template called "footer", added fields to it, and then perhaps created a new page using this template too. Sound familiar? If so, you can also use that page as well (instead of, say, your home page) to store your footer values: in your _foot.php you can get that page and output the value from it with <?php echo $pages->get('/footer/')->footer1 ?>. Does this make sense to you?
  3. teppo

    Was just wondering why people suddenly started starring my module repositories. Cheers, @adrian
  4. Code Blocks Textformatter is a tiny Textformatter module I cooked up to add support for code blocks to text/textarea/RTE fields on some of the sites I work with. Unlike a full-blown Markdown Textformatter – which is something that we already have in the core – this module simply adds support for fenced and inline code blocks. The syntax is based on the GitHub code block documentation, so please refer to that for additional instructions. The README at GitHub also includes some basic examples. As with any Textformatter, in order to enable this one, install it and enable it via field settings. Note that there's no syntax highlighting built in (at least for the time being), so use a tool of your choice for that – personally I prefer Prism.js. Since this module doesn't use a Markdown tool behind the scenes, but rather some home baked regular expressions, there's always the possibility that I've missed something – but please let me know if you use this module and run into any issues. On the other hand this module should be relatively fast and unobtrusive, as there are no unnecessary bits of code to run GitHub repository: https://github.com/teppokoivula/TextformatterCodeBlocks Modules directory: http://modules.processwire.com/modules/textformatter-code-blocks/
  5. You need to add pagefileSecure-setting to your /site/config.php file, and set it to "true": $config->pagefileSecure = true; More details here.
  6. teppo

    Hi there. Not a complete answer, but first of all I'd suggest taking a closer look at this post, which has a link to an article hopefully resolving some worries regarding encryption of data: Other than what you've described above I don't have a rock-solid solution for you. I would assume that, as long as you're taking care of other parts of the regulation – such as breach reporting, removal of data on request, and so on – and you encrypt all traffic targeted at personal data (HTTPS), you should be safe. But then again: IANAL, so please don't take my word for it. I'm just assuming some common sense, really. With current technology it would be next to impossible to encrypt all personal data, while still collecting all the necessary data in the first place. Think of things like server log files etc.
  7. teppo

    Some loosely related observations re PWA vs. native:
  8. teppo

    Just pushed a fix for this issue to the 2.0 branch
  9. teppo

    Thanks for letting me know. That makes sense: the page level snapshot feature makes use of timestamps, so timezone settings being off could make it misbehave. Field level features work just based on revision IDs, so this issue wouldn't affect them I should probably add a note about this somewhere..
  10. teppo

    I ran a poll about PWA's in #174 of ProcessWire Weekly and included a couple of useful links: https://weekly.pw/issue/174/. Check out https://pwa.rocks/ too, some nice examples there Google calls PWA's "a new way to deliver amazing user experiences on the web", which obviously explains absolutely nothing about them. The A List Apart article mentioned above is a great resource, in my opinion, so definitely check that one out. Ionic also has a pretty good introductory article: https://blog.ionicframework.com/what-is-a-progressive-web-app/. In a nutshell PWA's make use of various Web APIs and technologies, such as JavaScript, Service Workers, etc. They provide a "native like" experience, but are not native apps – so, to answer your questions the best I can, I'd say that ... as far as it's doable with web technologies (yes), as long as you can do it with JavaScript (yes), and I'm pretty sure you can, but I have no idea how, except for the point that since a PWA is essentially a "website with superpowers" (not my quote, but can't remember the source right now) it's probably mostly the same process as with any "regular" premium website. That being said, I've also got native mobile app development on my bucket list, where it'll remain even taking PWA's into consideration. For certain things native apps are still a better choice, and serious game development is one of those.
  11. teppo

    Version 2.1.0 of VersionControl was just pushed to the 2.0 branch at GitHub. Note that this update changes the field-level UI quite a bit (see screenshot below). Personally I like this UI better anyway, but the main reason for the change was that it would've been a major pain to get the old UI to work with both the (current) default admin theme and AdminThemeUikit – let alone any third party admin themes. The colour theme is currently hardcoded, so it doesn't adapt to whatever changes you might've made to your admin theme. It's also exactly the same for both built-in admin themes. I could make some parts configurable at some point, but for the time being this is better than nothing. Next up: more testing. I'm pretty sure that there are a few bugs here and there that I've managed to miss, and I'd like the core features of this module to be as solid as possible. I'm also contemplating giving the History tab a major facelift, but that's not exactly the first item on my list right now
  12. teppo

    I have to agree: this is a good discussion, but doesn't belong to module support thread. Any mods up to that? I hope I'm not causing any unnecessary confusion – and I may not see the full picture yet, so perhaps I'm missing the point entirely – but when it comes to snippets, there's already https://processwire-recipes.com/. If you have useful snippets for common tasks etc. I'd suggest submitting them there. Similarly I'm leaning towards collecting ideas for improving the existing modules directory rather than creating a competing platform. In the 2018 roadmap post Ryan listed modules directory as one focus point for this year, and I'm sure he'd be happy to get some feedback on exactly how it could be improved.
  13. teppo

    Loosely related request in GitHub: https://github.com/processwire/processwire-requests/issues/56. I've also been having a number problems with the current behaviour, but I hope that one day we can get past this whole filename mangling silliness Edit: just realized that you're trying to do pretty much exactly the same thing as I was when I last encountered this issue. If you do find an elegant way around this, please let me know as well
  14. teppo

    Haven't seen any issues either, though the latest message was sent three days ago. There are indeed some related issues in the mailgun-php repository, but they all seem to be closed. For an example: https://github.com/mailgun/mailgun-php/issues/174 (includes a reply from the MG folks too). Looks like they've made some certificate related updates – see the linked issue for more details and some suggestions for fixing it.
  15. teppo

    Just wondering, but how long has this been happening? In somewhat similar situations I've had delays of hours .. days. Another thing I noticed is that your (current) robots.txt has a max-age of 30 days. According to Google's docs, they may "increase the time" a robots.txt file is cached based on this header, so in theory they could still be holding on to the old version. In that case I don't really know which steps to take, but first I'd wait for a few days to make sure that it isn't just Google's regular delay
  16. teppo

    So far I've been unable to reproduce either one of these. Perhaps it's something that I fixed by accident, or perhaps it's something about my setup, but revisions seem to work fine and history tab pagination returns me to the history tab. I'll keep an eye out for these, though Adding #VersionControlHistory to the pagination probably wouldn't hurt, so I'll try that in the next update.
  17. teppo

    Version 2.0.0 of Version Control was just pushed to the 2.0 branch at GitHub. While I'd be happy to hear how it works for you, please note that this should be considered a beta release: so far it seems to be working with basic text fields and file/image fields, but honestly I've not tested it much yet (got the file field part working literally minutes ago). Note also that this version bumps the required ProcessWire version to 3.0.62 – the current master/stable version. Technically this release should work in 3.0.16 or 3.0.18 as well (the versions that introduced major changes to the image inputfield), but I don't plan to test this module in anything older than the master branch.
  18. Please do! Not a bad idea either. I've usually relied on a few bullet points, so not sure how a "book" about this would look like, but I would love to see that
  19. teppo

    Quick update: there's now a 2.0 branch and 2.0 milestone for this module at GitHub. For the time being the 2.0 branch is identical with master branch, but it's a start. I'm going to get another project I've been working on out there today, and after that I should have some time to work on VersionControl 2.0
  20. teppo

    Got to agree with @Pixrael. While page.js seems nice, it's probably overkill in this case, and since you already have ProcessWire to provide routing, it makes sense to just add JavaScript-powered transitions on top of that. I've used http://barbajs.org/ in the past for this purpose. As a bonus compared to pure JavaScript approach you won't have to worry about search engines, non-JS enabled browsers, etc. as they'll still get the "regular page load experience"
  21. Was just about to say something about how flock() alone probably won't be a massive problem – it's only used in FileLog, so with it disabled ProcessWire won't be able to write anything to log files, but technically speaking everything else should still work – but the chmod issue sounds like a real showstopper. Some hosting providers have their own guides for configuring things like uploads "properly", but honestly speaking it sounds like you should look into switching to another hosting provider as soon as possible. This one sounds like a major pain in the a*s.
  22. teppo

    This sounds familiar: https://www.magnolia-cms.com/blogs/christopher-zimmermann/detail~&hybrid-headless-cms~.html.
  23. teppo

    There's a setting for this in Template Cache also, found from the Cache tab when you edit a template: In fact Template Cache is disabled by default for logged-in users, unless I'm somehow mistaken
  24. teppo

    One thing to consider here would be offline or LAN use, where you may not have access to GitHub.. and of course GitHub being offline, though that doesn't happen too often these days. That being said, I personally think that we should limit the starting site profiles to a bare minimum – three or four being the absolute maximum in my opinion. Offering an online site profile installer as an additional option in case none of the starting profiles feel just right would be pretty awesome.