Leaderboard

Latest version adds a "Panel Selector" panel to the debugger bar. I added this because I noticed that the overhead of having all panels loaded all the time can sometimes be a few seconds depending on the server. With this new feature you can pare down the main "Show Panels" module config setting to just the ones you want all the time and then use this new panel to quickly and easily enable additional panels for a specific purpose without having to go to the module's settings and mess with the defaults. The changes to the list of panels is stored in a session cookie, so as soon as you close the browser (or you use the "Reset Default" option), you'll return to your default set of panels. Hopefully you'll find this speeds things up for you. On this note, if you are finding things slow you may want to consider the config setting for switching to the stable version of the Tracy core (this was mentioned several posts ago, but in case you missed it, it can make a huge difference. Hopefully the Tracy guys will come up with a solution (https://github.com/nette/tracy/issues/157) for the master/dev branch before it is marked stable). I am also going to do some code review on all the panels in an attempt to speed things up - I am sure there are some things I overlooked in initial development that can be dramatically improved. Let me know if anyone has any ideas though.

I just installed the latest dev to see the images field changes. Some thoughts: instant previews are great d&d image replacement is useful when there's only one image added and entering edit mode, opening the lightbox and clicking on the image in the lightbox closes the lightbox but also closes the edit mode. This feels like a glitch. Clicking on "close" or on the overlay works fine though. Also, it would be nice to see these some time: viewing the file name somehow (as requested above) renaming a file for SEO purposes (as requested above) deleting all variations for an image, or maybe for all on the page. The "Variations" button could be modified to have a dropdown like the new Save buttons. the button "Crop" have other actions in the lightbox, so this could be perhaps renamed as "Edit". This would be a more appropriate naming even when adding new edit functions to the lightbox. Thanks for everyone involved, this could be a hard work with no doubt. We shouldn't expect everything working perfectly on the first iteration but it's a great start to build upon.

Hey Pwired, thanks for taking the time to post your compliment and reply. Hope all is well in Spain. Your reply brings up more than one issue that I've been thinking about on and off for a while now. As I mentioned in my post, I'm not building sites for a living at the moment. At best I hope it is to become a part time endeavor. How realistic is that goal? I'm not too sure at the moment. I'm one of those 'old programmers' you hear about sometimes Some may laugh, and that's ok.. but I still enjoy creating software and learning new things, though I try to pick and choose wisely what I put my time into. I did spend a more than a few weeks of evenings experimenting with Wordpress after looking into it , seeing the numbers which are hard to ignore, on it's usage and popularity, etc.I was at a point where I was able to put a decent template together from scratch and I was starting to feel comfortable with the Wordpress flow. Ultimately though, I did not really enjoy working with it. It was not easy to pass on it after the time I spent on it. Sometimes you do have to invest more time than anticipated to evaluate a piece of software, especially a 'framework'. And yes I know , many don't consider Wordpress a framework or a CMS. I'm not big on semantics so forgive me ( Interesting read here on that topic if you're interested ) One of the priorities for me personally is, if I'm not enjoying what I'm working with, I'll pass on it for now. I feel much more positive about working with PW than I did with Wordpress. The code/design is MUCH easier to follow for me personally. My hat is off to Mr. Cramer and the others closely involved with development and maintenance. I'm not saying Wordpress is garbage. I'm just saying I have more respect for the internals of PW vs Wordpress. Again, not claiming to be an expert on these things, it's just my personal feeling about the matter. I would be interested, for my own benefit to see an example of what you mean by the more recent versions of PW requiring more code to accomplish a given task. Yes, I can see where a site could be put together faster with Wordpress than with PW. I would guess we're talking about relatively simple sites though? And really, who puts together a site from scratch anyway? It's not difficult to see that PW very much lends itself to creating site templates and yes it can be done with WP too, but which would be easier to implement with a satisfactory degree of flexibility? I personally feel that PW's whole Page->Template-Field concept provides great flexibility. Now I realize that WP may have plugins / themes that offer similar flexibilty. I am just not familiar with them personally. And yes, it can't be argued, Wordpress users have a huge number of plugins at their disposal and this of course might give them the edge in development speed if a similar plugin isn't available for PW. Anyway, as usual, I have rambled enough. Another fine example of tl;dr I'm afraid. Worried I might be banned from submitting posts after this. The scary part is I had more to add, but I will just save the thoughts for a post of my own sometime. Again, thank you again for taking the time to reply. On a parting note, I will only add 'Raise your rates!!' ... ( just joking.. sort of.. Have a good day.

I think this thread is classic and I'm glad I stumbled upon it. A lot of grins and nods while reading through it. It touches upon many points of frustration that any coder, no matter what the platform , is going to run into. Speaking from my own experience, as the cliche states, there are only so many hours in a day. Only you can make the decision how you want to spend them. OK.. so a little background... I am not a full time web developer at the moment. I was a full time developer for many years up until recently, working on different platforms along the way - IBM mainframe , HP, Unix and of course Windows. I have had the great pleasure of learning more than one language that eventually fell to the wayside for one of many possible reasons ( Powerbuilder anyone? ). Of course I had to put the time into learning those languages. I am not bitter though After you've been a coder for even a short time, you come to see this is just the nature of the beast and I don't consider it time wasted. It kept me employed . On the other hand, if you value your time, you learn to sit back and ask yourself, do I really need to use this? Is the benefit I get from learning it going to outweigh the time and effort to learn it? Does this seem to be a product that will be around for a while or is it the product of some talented individual(s) making a go at becoming the next Zuckerburg? Maybe they will and maybe they won't. These are just a few questions I think most of us ask ourselves before we go off on a tangent to learn yet another piece of software. Case in point regarding this article : Grunt vs. Gulp. On many occasions I came across many threads where either of the two happened to be mentioned but I held back from taking the first step. I had other priorities at the time ( Like looking over PW for instance ). My first exposure to either came this weekend. I did some Googling and read enough to get the impression that more than a few people switched from Grunt to Gulp. Ok so I read a little more and got the second impression that it might not have much of a learning curve. So then I ask, could I get by without it? The answer was yes, I could simply write a PHP script or even vbscript for that matter, that would accomplish what I needed. I was a little conflicted because I saw some potential benefits with learning to use it. Just small conveniences, nothing major. I also had the suspicion that I could probably find enough sample code to throw together what I was looking to accomplish with it, and sure enough, that was the case. This is just a small example, there wasn't much at stake with playing around with Gulp, and along the way I learned a few small things about Node.js. I am a Node newbie, so it's all good. I have written way more than enough here and see that I have not really made any specific point, and I've just reiterated points already made by others. To summarize it, I'd say choose your battles wisely. Don't lose sight of your current priorities. Weigh the potential advantages against the potential time investment. And also, are you willing to put software package 'A' on maintenance mode in order to take on the new, shiny product 'B'? Have a good day

Sorry - another minor improvement. You now have "Once" vs "Sticky" options. "Sticky" behaves like the previous version - the selected panels will remain until you reset or close the browser. The new "Once" option will only change the panels for the one reload that happens when you click the button. This should make it even easier to quickly view a panel you rarely need like PHP Info for example.

No problem - thanks for clarifying and for helping to sort this out. Latest version includes that style. Let me know if there are still any problems.

https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#new-module-file-compiler-tags

Echoing some other sentiments here, I definitely would need the ability to toggle to some view where one can see descriptions and/or tags on the main view. In other words, it will be essential for quite a few of my existing sites to be able to see at once the tags on each image without clicking edit on each one...

Just installed PW3 so I could get a closer look at the new images field. The appearance and interactions are both really slick. Some feedback: I think having the option to get an overview of which images in the field are landscape vs portrait, which have descriptions and which have tags is very important. The aspect ratio thing could perhaps be solved with a toggle between fit and fill for thumbnails. But for the description and tags I think we need to be able to toggle to something like the old list view. Not being able to see these things across all images would be a real annoyance in some situations. I think there needs to be a max-height set for images in the enlarged view. As @titanium pointed out, some images could be very tall and narrow and at some point the enlarged view will get excessively tall. Perhaps the enlarged image area should be defined as a 1:1 ratio and the image scales to fit.

Hi, Please don't hate on me but I'd also like to mention Visual Studio Code. I vaguely remember checking it out quickly a while ago and wasn't too impressed. I came across a reference to it this weekend while reading a thread concerning Gulp. ( Don't ask ) so I decided to take another quick look. I've installed it and have been using it not even two days. I like it a lot for what it is and will probably stick with it.It's more geared for developing HTML, CSS, Javascrpt and Node but it does have extensions for PHP and it hooks up to xdebug very easily. It's got some features that I think will be time savers, once I get used to them. I've been using NPP for quite a while and have no complaints with it, and I finally have a pC that can handle Netbeans easily enough. My method has always been to use NPP first for straight coding, and break out Netbeans when I need to really study code I'm not familiar with. I have briefly looked at Atom, Brackets and ST3. They are obviously all good products. So many editors (and CMSs, and Javascript frameworks, and CSS frameworks and...) , so little time. For me personally, I was comfortable with VCS from the get go and I'm guessing it might be in the same league as the others. I want to think that any missing and desirable feature will eventually be provided by some 3rd party extension. Wishful thinking perhaps. Extensions are written in javascript, and the means exist to create them on your own if you choose. Anyway, I didn't want this to turn into a commercial. Just wanted to mention it after having rediscovered it this weekend.

Sorry for not being clear! Version 1.4.9 did not solve the problem of the labels sliding under the checkboxes, so if it is ok, please to add those styles to Tracy. Since you mentioned it, I also tried to fix the issue with "all: initial", but could not figure out anything that cloud work.

Thanks Adrian! Probably this change made the checkboxes clickable. As for the css issue, I could fix the issue of the boxes covering the labels by applying these rules: #tracy-debug input[type="checkbox"], #tracy-debug input[type="radio"] { width: 12px; height: 12px; position: static; } Sure, the radio version is not needed in this particular case, but my css "framework" also define its rules for that selector, so just in case... Position was absolute, so that is why the labels slid underneath the checkboxes, and dimensions were also quite "incompatible", so to speak. I will look into my performance issues as well (when I have the time) and report back. I've also noticed the new version being released in the meantime. Keep up the good work, your fans – including me – love this gem!

Is the Validator panel ajax-driven? That could speed things up too I guess.

If you want editors to have frontend access, but not be editable you should either allow editors to have frontend access by default or create a editor-frontend role. If they shouldn't be editable then they are not the same as other members anymore. Edit: An alternative approach (more cumulative) could be superuser editor member frontend guest Give frontend to both editors and members so you only manage this role once, and allow editing of members to prevent editors from being edited.

Thanks Adrian! I could speed thing up considerably (especially by switching to stable from master, but turning off two additional panel helped too.) However, I cannot use the checkboxes in the Panel Selector panel. Probably my css rules conflict with the ones needed for this panel to work. The checkboxes are situated over their "labels" respectively and the click event is not handled at all, not matter where I click, nothing happens. I did not spend too much time to investigate what causes this, so I don't know it yet, but by turning off all linked styles (by using Chrome's Web Developer extension by Chris Pederick) the layout of the panel is back to normal and the checkboxes work as expected. Isn't there a way to make sure that this panel works whatever css rules the underlaying page has?

Is Adrian actually a French Canadian called Tracey DeBugger ? :-/

In addition to @teppo and @szabesz, there are more usecases what are currently seems not to be covered well. I must admit that I first also have thought that we need the list view too. But now, after playing around a few times in the last two or three weeks (with an unofficial beta, thanks to @Lostkobrakai) I'm not even torn. I have learned to live without the listview. Usecases that are not well covered atm, for example are image rows with 20 motives that all look the same, where you need the filename, and I mean the filename of all files at once. What I come up and tested (in context of the croppableimages extension) for this are two things: one can toggle visibility of filenames over the thumbs using a little textbox for filtering by filename This is even faster than looking through an endless list of filenames. Another usecase sometimes may be to directly see the aspect ratios of all images at once, not a nice looking centered cropped square. But you will not get that WOW-effect with a visually cluttered grid, also covered with filenames all over. So IMO it depends on the usecases and the user preferences: As you also can see in the second screen, media queries are respected. This isn't what I have done, this is already in the new core imagesfield! (@szabesz: there must be a glitch somehow with your device / version) I simply have extended the new core image field and was able to use comfortable supported hooks from the core field. Here seems to be all usecases already covered on the developers side! Conclusion: with every newly introduced thing, first part is a confrontation with no more able to behave the same as before (we, the users / developers) (sorry for maybe long and bad describing words, but I think you get it) Phase two should be to find some time, play around and try out that new thing, and if you find a usecase that isn't covered well now, don't simply say we need to implement the old way here for that. I personally think I'm oldschooled in many things and also not a friend of often changing things, but I'm so happy that I have had the chance to get my hands that early to the new imagesfield and in addition also found the time to play around with it! As one result, now I have improved my own behave / workflow in some usecases and are also able to give my clients a very well looking edit page, so that they can see and say: WOW! EDIT: and sorry if it looks that I shamelessly promote the croppable extension here. The new core imagesfield from @Renobird and @Lostkobrakai allone is responsible for all the ongoing new things. I wouldn't have done anything without it and also simply wouldn't be able to do things like I now could do. This all depends on the core imagefield. Most things what I have done to adapt the croppablefield with it, was to strip out great parts from the PW2 version so that all the design and magical stuff is delegated / handled from the core imagefield.

If you are able to do, I would suggest to create a simple testsite with latest PW 3.0.16 and enable the IMagick ImageSizerExtension. Would be interesting to compare the time on the exact same server.

Are you sure you want this? If you do, you'll have to define for yourself what makes a browser a "mobile" device. Nowadays, neither UserAgent-sniffing nor screen resolution or touch feature testing alone are enough as a sorting criterion. Any libraries I've seen out there use a mix of all those, and they need constant updating as browsers change their features and mobile devices grow larger screens. A lot of laptops support touch now too, but you don't want to serve the mobile version to a 4k-displayed ChromeOS notebook just because the browser window doesn't take up the full screen width at the moment it visits your page. I'd call successful separation of regular and mobile devices a science for its complicatedness, but for a science, it's far too imprecise. If you decide to go down that path anyway, there are a number of libraries out there, just googling "Javascript detect mobile browser" gives me quite the list. You'll have to decide yourself which version supports the features you regard as distinctive. I'd then use a JS popup to let the user decide if they want to go mobile or stay on the main site, add mobile/full version links on every page and add another site directory for m.mydomain.com with the mobile templates and auxiliary files.

Hi Jürgen, I was looking for something like this and built something similar which is more generic I guess - but I haven't tested it with complex fields so far. In my module it is possible to set specific templates which are able to "give" field values and specific fields which are able to receive values. Then, any field of a newly added page adopts those values according to the settings. https://processwire.com/talk/topic/13183-adopt-field-values-as-defaults-from-parents/ Maybe this might also be useful for you. best wishes Steffen

From a noob on the outside looking in, I feel a need to state the obvious. I have been spending a fair amount of my time lately installing and working with a few of the 'popular' CMS offerings. I haven't honestly decided what product I'm going to go with yet. For the type of sites I hope to be doing, PW might be overkill. But that's off topic here. Just speaking from my own observations so far.... The Processwire forums and community easily outshines the others ... overwhelmingly. I am not going to name names and I'm just guessing that the accompanying argument from the competition would be something like 'Well , there's only so many hours in a day, and we're a small group of developers with other jobs, family , etc , so whatever time we can spare, we put it into development , patching, etc.'. And that argument is a completely valid one. The point is though, that it appears a number of people involved with PW, with I'm sure the same obligations, ARE taking the time to make the community here what it is - very knowledgeable , very friendly and VERY valuable to those who otherwise might be Googling for hours on end looking for a solution, and we all know how much fun that can be. Well maybe not all of us, but I know I have been there on more than one occasion because the so called documentation was outdated, couldn't find an answer in the 'forum' and I wasn't in the mood to walk through the code with XDebug that day. Anyway, I have rambled enough. Thanks again to ALL. You ALL have a GREAT community here.

Hi ngrmm You probably tried to upload an image that has too many pixels, so your allocated memory to PHP is not enough to process your image. I advise you to get that line back in... Your images will look strange without it at some point. You have two options if my assumption is correct: 1. Increase the PHP memory to the maximum 2. if that doesn't help, shrink your images before uploading them. Hope this still helps

Sometimes I feel horrible that I'm not using the cool kids tools, but truth be told I think none of my projects are that complex to really need this setup. Am I being lazy here? Should I actually try this tools to actually see the possible benefits? I mean, I do want to become a better webdev, just really haven't seen the need, I just feel that all that minification and optimized workflow works for complex stuff and when that time comes, I will make my move, meanwhile it feels like an overkill.

I can imagine how overwhelmed you feel right now. It's like wanting to start playing the guitar, but being confronted with amplifier settings, guitar brands and whatnot right within the first minutes. When you only want to learn one single chord first and build upon that. I guess you already stumbled upon Chris Coyiers close-to-perfect intro to Grunt? http://24ways.org/2013/grunt-is-not-weird-and-hard/ ? My advice would be: Choose either Grunt or Gulp (both are great, capable, and have all necessary functions as plugins), stick to that decision for a couple of projects, don't let distract yourself by the usual developer tiffs, and once you build your own Grunt/Gulp boilerplate and feel confident with it, reach out for optimizations (and maybe read these links here again). But then you'll already have entered the amazing world of task runners and will most probably consider them as a crucial part of your development workflow Also, here's a super simple Gulpfile from processwire-recipes.com, just dealing with SASS and gluing some JS files together (Please ignore the messed up indentations in the file)

The biggest difference, is the pain in your arse, if you come in a project, where tools are used that you don't like. So, just learn to love them all! I use gulp and love it However, from time to time I have heard(german) that gulp feels a bit weird, if the project gets larger and your list of tasks growth. But, I have never reached this scale. Another point is speed, gulp uses streams (for parallel execution of tasks), what makes things pretty fast. While grunt does not did. Since v0.5 or so, grunt supports piping data, so the speed could be nearly "the same". If you do it right, the result is the same, really. Do you like neither? It is ok/Es ist ok, try npm or use both!

I have to admit a static site generator is something I would also be interested in. I have used similar plugins for other systems (wordpress, modx etc) and found it useful in various situations. I often use processwire for prototyping an idea on my local machine, and being able to quickly share that with clients or team members to get feedback requires copying the db and code over to the server (not a massive task but still takes time and effort). Having a one click export to folder or zip file for sharing would be a huge time saver. If you set that up with a dropbox folder and a service like site44 (http://www.site44.com/), you could have a pretty neat publishing workflow. Instant one click publishing - just like FrontPage 98! Another interesting use case, if you made the static site generator flexible enough, would be to use it for exporting to epub, pdf and mobi formats - a kind of ebook export module. This would fit in nicely with an idea I have been thinking about - a simple book publishing platform with PW - something similar to the booktype project by sourcefabric ( http://www.sourcefabric.org/en/booktype/ ) or the Leanpub site ( https://leanpub.com/ ), which could be used for writing books or documentation. Also, similar to httprack application suggested by teppo, If you are on a mac and want to create local copy of a website, site sucker is very good (and free) http://sitesucker.us