teppo

Hi there, Which version of ProcessWire are you running, and have you installed any modules? Which ones? What about your server, anything special there? What PHP version are you running? So far this sounds like a module would be hooking into page save and causing issues, but without knowing a bit more about your setup, that's just about all I can say. At this point it could be something entirely different too.

I believe that OP was referring specifically to D8, and how it relates to PW. According to the Drupal team, they've changed a lot since D6-7, so I don't think it's such an unreasonable question to ask, and personally I'd love to hear some proper insights on the matter -- preferably from someone with solid D8 knowledge, not just past experiences with earlier versions Taking a look at the D8 marketing materials, it seems like they're going to a good direction. Some of their new features I like, some I don't like, but in the context of Drupal they probably all make sense. Either way, it seems to me that much of what they've been adding ProcessWire, one way or another, already provides. The way they're touting HTML5, mobile first, etc. makes me think that the markup generation part, which is one of the biggest problems (in my opinion), might not have changed much either. The developer API and theming system still seem complicated to me, but I'm used to working with custom applications, application frameworks and ProcessWire specifically, so my views are probably biased. It also seems that these are very much separate entities, quite unlike how it works in ProcessWire, where the API is a key to everything, everywhere. Anyway, this is exactly why I'd love to hear some unbiased opinions

Hi there! Your first image seems to be 500x500 in size, actually, just scaled down using styles. Could that be the original size, perhaps? Second image has "500x500.300x0" in it's filename, which looks a bit weird (are these both added by ProcessWire?) and is actually 300x300 in size. Guessing this is the downscaled version. Haven't tried these with ProcessWire, but I've seen image resizing destroy animations in GIF files before. That might be happening here too -- Horst should probably take a look at this, he's the one who knows best what's happening. A very quick Google search resulted in this thread, which seems to suggest that GD resize might need extra work to support animated GIFs For the record: if possible, I'd suggest that you create a new GitHub issue for this.

In my opinion these don't belong to the official language pack, where we should stick to what one gets by downloading ProcessWire. Additionally, FormBuilder and ProCache would be particularly problematic, as they're neither open source nor free. Some sort of central repository for 3rd party module translations is definitely a good idea, though. Anyway, that's just my opinion -- would like to hear what others think about this.

Well said! - Happy Emacs user (Though, on a more serious note, Emacs is actually actively developed. I just haven't upgraded in a long time. Why bother, when it already does everything.. and a bit more.)

@Fokke: looks great, thanks! Not sure if it was intentional or not, but there are also translations for some site-modules -- should those be in there?

"If it's translatable, it's meant to be translated". Just my five cents If Finnish translations continue to be hosted at GitHub, should we consider different ProcessWire versions there? Branch for each PW version, with master being "current stable"? Tags would work too, but AFAIK that would make updating earlier versions impossible.

First of all, this is how ProcessWire asset management works, so instead of asking "why does it do this", I'd ask "why wouldn't it do this"? Files, including images, are tied to Pages, and live under page-specific directories under /site/assets/files/. If you really need to change this behaviour, you probably can, but it'll require quite a bit of work -- and thought, as you'll have to find new ways for keeping asset names unique (two pages having a different file with same name and so on), handling secure files, removing files once they're no longer needed, etc. In a nutshell: this is not something you can easily do. If you're ready to really get your hands dirty and rewrite a lot of what ProcessWire currently does with Pagefile, Pagefiles, PagefilesManager, ImageSizer, etc. then by all means do it (and we'll try to help), but I'd suggest against it. Also: you should make sure that you have a really good reason to do this first. What are you trying to solve by moving assets to template-specific (assuming that's what you're referring to here) directories? How does it benefit the system, or the user? How does it scale, what kind of benefits and/or drawbacks does it introduce, etc.? If there's something specific you're trying to achieve by this, please let us know. Perhaps there's an easier way to do it.

Like the idea, but it really does seem a bit vague. Would love to see this taken further, though I was also wondering about translations (like @yellowled said earlier) and the roles; you mentioned "admin" and "user", but I can think of quite a few cases where those won't be enough (some modules define a bunch of permissions, use cases may vary between roles or groups of users, etc.) Would you see this as something that is bundled with the module as a file (perhaps something like modulename.docs.md) or a module setting, or what? Should superuser be able to completely override the docs without touching files in the module directory? Mostly thinking of cases where we might require something specific -- or just felt that a different angle would better fit particular client. Sorry, it's getting late here and my head seems to be full of questions I guess this depends on your point of view. In terms of docs Linux tools tend to be lightyears ahead their proprietary competitors, and a lot of open source projects I've worked with have had (at least) quite extensive code-level documentation (i.e. comments). For most parts ProcessWire is a good example of this

Going to agree with Philipp there. Especially in the light of some of the "high profile" vulnerabilities uncovered lately, I believe that security is one of the true strengths of ProcessWire. While exec(), shell_exec(), system(), passthru(), etc. are powerful and very useful in controlled environments, they also introduce a whole new set of risks, and IMHO are rarely something you'd want to include in the core of an open source platform. That being said, there's nothing stopping you from using them in your own modules

@Joss: not too far-fetched, but you could always try the Hanna Code Helper module too. Not trying to advertise it or anything, but I feel it's pretty convenient to see the tags right in the context where they're actually needed. Slightly longer description would be great thing to have, either way

Marvin, any news on this module? Have you had a chance to look at my previous questions? Just checking..

If you want results in a specific order, use "sort": $pages->find('parent=/blog/, sort=sort')->last(); // and if you want just one item, don't forget limit // (or use get(), and check viewability separately) $pages->find('parent=/blog/, sort=sort, limit=1')->last();

Really like your first and second lazy ideas. Second one might work even better with something "less obtrusive", such as AsmSelect