teppo

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.

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 tool for massive JavaScript applications, but that's not what the admin is all about either. Also, 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 a 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.

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.

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

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

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

You know what they say about opinions and everyone having one, but... I must disagree In my opinion the new top bar is a step up from the old one, and having a separate h1 is a good thing. That being said, the h1 is too large for its own good, so you might want to decrease its size. I wouldn't be strongly against making the top bar a bit smaller either, but in my opinion current one looks better than the old one.. not to mention that it looks less like something we borrowed from Craft (Half joking about that last point.) The biggest problem I have with the top bar as it is now is related to accessibility: the active link/tab should be clearly visible, and preferably have an underline or border. Currently the difference between active and non-active sections is so vague that it's hard to notice, even for someone with no visual impairments. Also, and please correct me if I got this wrong, did you say that clicking the ProcessWire logo opens a sidebar? If that's the case, I'd suggest rethinking this part. It is a well established convention in the web that the logo is a link to the nearest "home page" – which, in this context, would be the admin root. I would advice against breaking the convention, as it will lead to two issues: unexpected behaviour, and a useful feature that gets easily overlooked by users. Overall I quite like the new design. It's fresh, yet it still looks familiar enough. Great job!

@apeisa: sorry, not yet. Slowly working my way towards it...

Sorry, @houseofdeadleg and @szabesz. Looks like one of my previous performance improvements caused this module to require PHP 5.5+ , which is probably the source of the issue you experienced. The latest version pushed to GitHub reverts that particular change, so upgrading to the latest version should fix this issue.

I might be misunderstanding what you meant by "discounting of the value" and "counted", but the sources I've read so far seem to say that, behind the scenes, duplicate content is automatically bundled together under one canonical URL by Google. In this case it could mean that, for an example, all links to example.com/foo and example.com/foo/ would count towards the version that Google deems "primary", and it would also be the only one they display in their search results (unless the user specifically chooses to show duplicate content). Possibly the most common problem with duplicate content is that Google could choose a different version as the primary one than what you might prefer, unless you use canonical tags to advice them. Probably the most fearsome problem, on the other hand, would be that they could think that you're trying to copy same content over and over as an attempt to "cheat", in which case they could remove some pages, or even the whole site, from their search index. But again, I highly doubt that they could ever interpret a trailing slash issue as such an attempt I must admit that crawl budget was a new concept for me. After reading a bit about it, I'd say that it definitely won't be an issue for the vast majority of us here (first of all in a blog post they say that it usually only affects sites with thousands of pages), but it's definitely something that very large sites, or sites that auto-generate URLs in some way, should take into consideration. Anyway, thanks for sharing this point of view!

If you want to see the current situation real-time, you could install the built-in Session Handler DB module. This changes ProcessWire to use database sessions (instead of storing session data on the disk) and also provides a handy overview under Setup > Sessions that displays currently active users, when they last did something, and where they are on the site right now. I'm not aware of a module that would track this kind of data in the long term and/or store it in a log file, but I'm guessing that it wouldn't be terribly difficult to build one on top of the database sessions module. Someone else might have a better idea about this though. The Login History module tracks when users last logged in, but it doesn't track logouts, so it's probably not much of a help in this case.

At this point my best suggestions would be DropboxAPI, just plain Dropbox, or perhaps DropboxUpload... though that last one only if you are sure that you'll never add anything other than upload support for it

Thanks for sharing this module, @psy! Will definitely give this a try soon. Just one observation at this point: only Process modules should have the Process prefix in their name, and since this isn't a Process module (i.e. it doesn't extend Process), I'd suggest considering another name for clarity. Perhaps just dropping the Process prefix?

The reason for that is that the global keyword always refers to the global scope, i.e. the highest scope possible. In this case $gsAPIKey is first defined in a function scope, not in the global scope.. so no help from the global keyword You should either define $sgAPIKey within send_email(), as shown in the example above, or you could define it earlier and pass it as an additional param to the function.

Try $this->config->paths->root instead ... or the wire() function, as @adrian suggested above.

Actually require_once() works just fine for your example. I'm not sure what kind of a problem you're having, but I'm pretty sure that it's not related to require_once() not working in a hook, at least. One issue I can spot right away is your comparison, where "if ($page->template == user) {" should probably be "if ($page->template == 'user') {". It also seems that you've omitted some closing curly braces, but if that wasn't even supposed to be a fully working code sample, so perhaps this was intentional

@flydev: hey there! Just checking, but is there a particular benefit to using WireFileTools instead of PHP's own include() or require()? Haven't used it much myself, so mostly curious. From the first look it seems to me that regular include() or require() would be more efficient and possibly also easier to grasp, but it's entirely possible that I'm missing something important here

@szabesz: that seems pretty weird indeed. I guess it could have something to do with different timezone settings and such.. or not. For the time being I've updated the module to use the DATE_RSS constant instead of the 'r' date format for RSS feed dates, but as far as I can tell that should not make any actual difference. Just a precaution, really. Anyway, let me know if you figure out anything new

The post you linked to actually mentions two reasons why this might be bad: it could be identified as duplicate content and it could have a negative effect on crawl efficiency. Neither is something you should really worry about in this case, but then again: Google is a black box (it's impossible to say for sure how their algorithm works), that article is from 2010 (things have changed a lot since then), and some SEO experts do seem to love their micro-optimisations Although in that article they go on to say that their indexing process "often" automatically detects and corrects this issue, it is also true that this is one of those things that are so easy to fix that, even for a tiny theoretical chance that it could affect your rankings, you should stick with one URL format. According to various sources there's no penalty for duplicate content, especially not in cases like this. It would seem that the only way you can get penalised is if Google thinks you're trying to deceive them somehow with said duplicate content. I highly doubt that the trailing slash issue would count.

Thanks, @szabesz. You should probably check if the actual RSS feed has the items in correct order. Just open it in your browser and see how it works there.

@Vayu Robins: thanks for your suggestion, but to be honest I'm a bit hesitant when it comes to this module and tracking values. I'm hoping to update my Version Control module to PW3 sometime soon, and perhaps after that I'll revisit this idea. Just to be clear, there are a couple of reasons why I'm hesitant about this: First of all that would require storing a lot of additional data, which could quickly become a performance issue. Sure, I could make this an optional feature, but all things considered I'm just not sure if it's really worth it. Second of all storing and outputting such data would get really complicated really soon. It's easy as long as we're just talking about simple text or textarea type fields, but what about HTML, fieldtypes with a bunch of different data columns, and files or images? The easy way out would be to only support a limited set of fieldtypes, but I'm worried that this would be a slippery slope And, finally, I'd like to draw some sort of a line between this module and Version Control. Version Control is the rather complex beast that allows you not just to view what was changed, but also makes it possible to switch between different versions of a page. Changelog was always intended as a simple tool for quickly checking who changed what and when.