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..

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.

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

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.

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

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.

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

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.

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.

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

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

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"

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.

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

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

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.

Somewhat related:

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

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!

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.

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"

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

This may be a bit off-topic for this thread, but I was actually kind of surprised at how many features I had to manually install after updating PHP: php5.6-xml, php5.6-mbstring, php5.6-mysql, php5.6-curl, php5.6-mcrypt, and now php5.6-gd. All features that I would've expected to be there by default. I guess it's a good thing that there's not too much clutter by default and there are different use cases, but like I said, some of those caught me by surprise. (Note: I'm using ppa:ondrej/php, so the default Ubuntu package, for an example, might have a different set of features enabled by default.)

If I'm getting this right, you're talking about short open tags? That's not exactly a new thing, but rather something that users have been discouraged to use for a very long time. Though you can still enable short open tags with the short_open_tag php.ini setting, if you've still got code that relies on short opening tags, you should consider updating it to the regular <?php opening tags That being said, in PHP7 they did remove some utterly obsolete tags: the ASP style tags (<% %>) and the script tags (<script language="php"></script>). My guess is that most users probably didn't even know that those existed.

Thanks for pointing me to the right direction Stumbled upon this issue after moving to a new version of PHP (5.6.x.) Working with Ubuntu here, so in my case the solution was "sudo apt-get install php5.6-gd" followed by "sudo apache2ctl restart" – and the issue is now gone.