teppo

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

A lot of it boils down to communication, and this is where very clear description of what will be built tends to help. If the contract (and/or related documents) state things clearly enough, including descriptions of noteworthy features (and in the case of web projects, preferably even rough sketches and/or wireframes), there's not (too much) ground to change that later, unless both parties agree that it's the better choice. At least around here it's also not too uncommon to specify amount of "comment rounds", especially for things like layouts -- it's always better to not have to rely on such clause, but it does provide a safety net of sorts to the designer/developer (and it's much better to agree on such things beforehand than trying to force such restrictions later on).

@totoff: I guess that's pretty close to what I described earlier, i.e. something like a separate project to get the concept straight, though it sounds like you're also including project costs in some form here. Sorry if I sound a bit too inquisitive here, but.. what I'd really like to hear is that do you estimate the final price at this stage already, or are you simply stating what your hourly rate is and that the final amount will depend on the concept stage? Or do you perhaps provide another quote with more specific details (about prices and the features of the end product) when the concept is finished?

Sounds reasonable, but does this mean that you define the actual costs later? Or are you billing by hour or stuff like that? Mostly just curious, since I've been pretty strict about spending/getting enough time for cost estimation before client gets any prices at all..

Totoff pretty much nailed it already. Only thing I'd like to add is that, if you can tell right away that the client has unclear image of what they want/need, you can always offer your consulting services as an entirely separate project, with the end result being a specification/plans for their upcoming site/project/product. Price it reasonably (but avoid being too cheap so that the client won't be surprised when they see your final quote) and explain that this has to be done sooner or later anyway. You might also mention that, if they so choose, they can always contract someone else to build the final product. Consider it kind of a probation period for both you and the client Common sense is always good thing to have; how much do you want/need this particular client, what's the probability of your "free hours" going to waste, do you have other (better) things to do at the moment, etc. Personally I find half an hour very short time to really get to know the client and the project properly, but I guess that too depends on the kind of (and scale of) projects/clients you usually work on/with

@Mats, that might be an interesting project, but seems to have one major shortcoming. Since it's something you'd use in your templates (or in a module) instead of at the database, it's going to cause various performance issues; you'll have to fetch entire dataset before performing the fuzzy search, or iterate smaller result sets one by one. They even mention performance on the TXP plugin page as a "known issue" (though there might code-related causes for that too, not just the point at which the fuzzy search is triggered). In either case, I guess this is fine as long as you know you won't have to consider scalability, but for me that's a pretty big no-no ProcessWire does perform in-memory searches too, in which case this would make more sense, but at that point you'll be filtering a pre-fetched list of pages, which kind of misses the point of fuzzy search IMHO.