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

About teppo

  • Rank
    Captain Earth
  • Birthday 08/21/1984

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

36,806 profile views
  1. 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.
  2. 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
  3. 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!
  4. 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.
  5. 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"
  6. 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
  7. 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.)
  8. 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.
  9. 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.
  10. I'm not strictly against ditching jQuery in favour of Vue / React / whatever it is that all the hip developers use right now, but it's true that this would be a major change, and I'm not sure how much sense it would really make. "That's what others are doing" is not a very good reason in itself, but if it would enable us to do something that we currently can't, I'm all ears (Note: in the end this decision is obviously up to Ryan, and as far as I know there are currently no plans for ditching jQuery / jQuery UI.) Personally I'm still somewhat fond of jQuery. It simplifies a lot of stuff, deals with browser incompatibilities, and provides polyfills for some missing features. It's not the best imaginable tool for massive JavaScript applications, but that's not what the admin is all about either. Minified and gzipped jQuery 3.x is 32Kb, so anyone calling it "huge" could use a reality check. Sure, it is huge if you're only using it to implement a simple slider or menu or something along those lines, but that's a rather limited use case. That being said, it is true that the core is currently using relatively old version of jQuery, so going up a couple of major versions could be a good first step? --- On a related note: at least a couple of third party modules already use Angular, and back in the day Antti even released a module that automatically loads it. For third party stuff it could make sense to build a set of modules for loading common frameworks and then require those as needed. That won't solve the problem of having to load jQuery and it won't make the entire admin a Vue/React/whatever app, of course.
  11. The main point here is that each ProcessWire site is unique. There's no 100% sure answer we can tell you without digging deeper into your codebase. That being said, you could try changing the lines you've posted here to something like this: $static_translations['telephone']['default'] = "Τηλ:<br><a href='tel:2821011111'>2821011111</a>"; $static_translations['telephone']['english'] = "Phone:<br><a href='tel:+302821011111'>00302821011111</a>"; Please be aware that this might not work as expected, and it might look awful if your site's stylesheet don't expect these numbers to be links. You should also test both versions afterwards to make sure that they actually work as expected – i.e. result in a call.
  12. Wouldn't mind having this feature in the core either. Just saying Admittedly my first impression was "oh man, not again". Some sites (Basecamp, Dropbox) have recently implemented their own flavors of "breadcrumb dropdowns", and in my opinion both get it wrong. In Basecamp clicking what seems like a link to the previous item actually opens a dropdown with that item and its children, while in Dropbox deeper down all but the last two levels are removed from the breadcrumbs and the first item turns into a dropdown. Both make sense in their own ways, but a) break the "open this link in a new tab" feature and b) are totally unexpected and confusing, at least to me. Your approach makes use of the spacer items, which not only makes more sense in this context, but also doesn't break the familiar breadcrumb pattern. Thumbs up for this
  13. Definitely. One of my pet peeves is desktop-sized images being served to mobile users. Now that browsers have a decent solution for this, there's no excuse not to do things properly. In our case there are also some useful modules for handling the "tricky" parts
  14. I'd say that this depends entirely on your use case. For an example, we have a couple of sites with a large amount of pages, where each page potentially holds a very large number of images, and those images tend to be highest possible digital camera quality. If there wasn't a limit in place, the site would get unmanageably large in no time. At the same time we know where and what those images are used for, and for those use cases ~1200px width/height is more than enough. On the other hand if you know that there won't be a massive amount of images or you have a notable amount of disk space to spend, and you really do need images in 2400px+ sizes, then by all means keep the full versions. In most cases I'd argue that a sensible limit makes sense, but obviously some cases – storing images used for print stuff, very large header images, etc. – demand that you set the limit pretty high, or even leave it off. Just thinking out loud, really. Probably nothing there that you didn't already know