• 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,468 Excellent

About teppo

  • Rank
    Captain Earth
  • Birthday 08/21/1984

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

36,990 profile views
  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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"
  6. 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.
  7. This sounds familiar: https://www.magnolia-cms.com/blogs/christopher-zimmermann/detail~&hybrid-headless-cms~.html.
  8. 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
  9. 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.
  10. On the other hand some languages seem to promote (or at least make it easy to author) fewer lines of code or fewer characters over readability. In my experience expressive syntax often results in code that is easier to read and grasp. Of course you can write unreadable or readable code either way, so again it's very much up to the developer
  11. 7.1 introduces a number of backwards incompatible changes, so 7.0 support might not necessarily imply 7.1 support. @Mirza, please report any issues you see via the processwire-issues GitHub repository or this forum so that we can deal with them. Thanks!
  12. Kind of pointing out the obvious here, but that could be asking for trouble. A number of modules (including core ones, such as Repeaters) perform cleanup etc. with hooks. Unless you're really careful, you could easily leave a ton of orphaned data behind with this method.
  13. Depends on a) your point of view and b) what you're doing with it. While I might recommend something else for a programmer just starting out, that's mainly because PHP is a major abstraction layer and most PHP devs never get a proper idea about all the stuff that goes on behind the scenes. Also if you're doing something requiring a specific set of tools – such as working with big data and statistics – you'll probably find a language that is better suited for that particular task. That being said, PHP is a decent language if you're primarily working on the web. It's rich in features, well supported, properly maintained, very widely spread, and so on and so forth. Additionally many online "this is why PHP sucks" lists focus on issues found from early PHP 5.x releases – or, better yet, PHP 4. These days there are a ton of things going for PHP, and not that many going against it. (Much of this could also be said about WordPress, but... let's just not go there. It's not the same thing.) ... and, like @horst pointed out, in many cases the language isn't the most important thing to consider. You can do a lot with PHP, and the good thing is that (if you're doing something it's suited for) you can usually get it done fast. Surely there are languages that have technical advantages over PHP, but those usually apply to either specific situations or somewhat extreme cases, such as "I'm running Facebook"
  14. I'd say that technically ProcessWire probably isn't a headless CMS – but it can of course be used as one, and quite effectively for that matter ProcessWire is very much a border case, but my impression is that if you can build a front-end with(in) a CMS, it's no longer strictly speaking a headless CMS. And you can build a front-end with ProcessWire. Sure, you interact with an API, but it's a "local" or "in-app" API, not (only) an external one. Hope that makes sense. And, mind you, I'm not saying that ProcessWire is worse than a "real" headless CMS – in fact I'd argue that it's a better choice for many use cases, but that's obviously up to debate