teppo

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.

@szabesz: so far I've been unable to reproduce this issue or figure out it's source. The RSS feed should use the timestamp column from database, and that in turn should be the date of the edit (according to MySQL, as this column is automatically set to CURRENT_TIMESTAMP). Are you sure that this issue only shows up at the RSS feed and not the main Changelog view too?

@Vayu Robins, to be honest I wouldn't be surprised if it wasn't. Repeaters, I believe, are somewhat supported, but Repeater Matrix is a lot more complex, at least as a concept. I'll look into this as soon as possible. @apeisa, I'll look into that image issue too. Unless that's really easy to fix, it might be time to release a 3.x branch of this module though. Could probably solve a bunch of things more cleanly now. API level tests still look good, so I'm thinking that this file issue might have something to do either with the "recent" UI updates, or perhaps the temp file thing..

@clsource: sorry for the delay. Weekly.pw RSS feed should now work as expected

Just for the record, we used to see similar issues, and the easiest solution was to convert all instances of \r\n to \n. Can't remember all the details, but this tweak has been in use at least for a year or two now, and so far we haven't encountered any additional issues. I know that the RFC specifically demands \r\n, but for some reason certain recipient systems seem to mess up HTML emails with that in place. It is my experience that \n works much better, regardless of the standard. And yes, we use a separate SMTP server (which in turn uses another SMTP server). Obviously it could be something about that setup, but if you google around a bit, \n instead of \r\n is a surprisingly commonly used solution

Regarding commercial modules you should definitely ask the author of the module first, this may or may not be an issue for them. My opinion (IANAL) is that you can freely bundle open source, non-commercial modules with the site even though you're selling it "like a theme". Only exception to this would be a module with a license that doesn't permit this, but personally I'm not aware of any (non-commercial) modules like that. The point here is that each module is a separate entity that can (and should) declare a license of it's own. If, for an example, you want to bundle a GPL licensed module with your commercial "theme", that's fine, but you cannot change the license of said module. Basically this just means that whoever buys a theme from you may not redistribute your theme as a whole (unless you permit it) but they *may* still redistribute bundled modules individually.