teppo

@everfreecreative: make sure that you've got the latest version from GitHub. This bug was supposed to be fixed a (short) while ago.

I'm not entirely sure what you're asking here, but still: ProCache won't affect any other aspect of these page speed tests other than server response time. Expires headers, page structure related stuff, minified scripts & styles & markup etc. still apply. Your content just gets served from files on disk without PHP and/or MySQL slowing things down. So, did this answer your question?

This is kind of related to this issue and this commit at GitHub: it sounds like Fancybox has problems affecting IE10 and since Fancybox is being replaced by Magnific Popup in 2.4 these issues should be solved at that point. Another question entirely is whether it's worthwhile to fix Fancybox issues in current (stable/master) PW release.. Oh, and no worries, Joe; your IE-situation is very familiar

The module Antti has been working on is actually pretty nice, as you can see from this site. It has most of the basic shop features, including cart, different payment methods (and support for adding new ones), variations etc. built-in already, so I'd argue that it's really much further than an alpha release. I'd still advice treading careful here if you're serious about those shop features. This is an area where you don't want to develop your own solution unless you're ready to invest a lot of time in it or only need it for small-scale / personal use. Just take a look at the feature list of some of the more robust solutions, such as Magento or Bigcommerce, and try to guess how hard they've worked putting all that together For the record, I'm not saying that you'll actually need all of those features or that ProcessWire + Antti's shop module wouldn't already include many of them, just pointing out that there are lots of full-featured alternatives you could just grab and start using now if you don't mind not having everything built with one system (i.e. building a site with PW but integrating shop from another platform). Just my five cents. @einsteinsboi: +1 for legendary dev.

Ryan: are you certain about this? I was just about to post that this little CSS rule in Font Awesome stylesheet is an awesome (pun intended) example of doing it wrong: [class^="icon-"],[class*=" icon-"]{... .. but based on above comments it seems that they've already realized and fixed this. The issue is that these aren't exactly "unique" class names and will collide with classes used in some existing Process modules (or, for that matter, in any other external stylesheets / styles that are also doing it wrong), which is not very nice behavior. Sure, another approach would be to fix any collisions elsewhere and keep these rules as-is, but that feels kind of wrong, considering that this is apparently supposed to be a drop-in will-work-out-of-the-box font library (or whatever the correct term here would be.) So.. perhaps we could implement fa-* style class names after all -- or if that seems too fa-specific, re-brand them to pw-* or something else "vendor-specific"?

Joe, I think I read your original post slightly wrong; I thought you meant that there would be a limit on how many pages can be created with each template -- while you probably meant a limit on how many children could each page with given template have. Considering this you can pretty much forget that template part in my first reply.. Also, I said that in ProcessPageAdd you could use "some hard-coded limit or a value of a field in some custom-created setup page (or a custom setting in site config, whichever you prefer) to see if a page can be added below given parent based on the number of existing children." If I'm reading your post correctly now, you'd find the template of the parent page of the page currently being added and get that limit from there, then count existing children for that parent and only then add the page. Makes sense, actually. One more thing I forgot to add to my original reply is that even if you checked in ProcessPageAdd if a page could be added, you'd still definitely want to add additional check at Pages save() just to make sure that two users weren't adding pages at the same time via ProcessPageAdd..

@leftblank: I know you kind of ruled this out already (at least I think you did, based on the comment that it wouldn't be very user friendly), but I'd still suggest taking a look at Hanna Code module. To improve it's usability a bit I created another module called Hanna Code Helper, which (even in it's current, barely finished state) makes selecting tags easier and removes the need to remember which tags (and with what params) were available. You should also take a look at some other textformatter modules available, they already provide simple ways to embed things like YouTube videos within text content.

First of all, there's one issue page limit won't solve: you'd also have to limit page name (or whatever you're using in your top level navigation) to make this even remotely useful. Otherwise users could simply create pages with names long enough to break your navigation anyway Template approach would be feasible only if you want to limit pages on your top navigation but not after that. Otherwise you'd run into huge problems, such as having to create new template for children of each top level page (and another for each of their children etc.) It would make more sense to enforce a child limit for each (direct) parent page. The way I'd probably start digging into this would be by creating a module that hooks into ProcessPageAdd execute() method and adds additional check, either based on some hard-coded limit or a value of a field in some custom-created setup page (or a custom setting in site config, whichever you prefer) to see if a page can be added below given parent based on the number of existing children. Problem with that approach is that you'd also have to prevent user from moving pages in some situations, or they could simply avoid this limit by creating page elsewhere and then moving it where they want it. This could probably be solved by hooking into Pages save() method, but that would be somewhat ugly; giving user some kind of clue about this limit within UI (i.e. before they attempt to move a page) would be optimal, but I'm not quite sure how to achieve that without a lot of custom code. Hope this helps a bit. If you want to do this properly, it'll require some work, and personally I don't think it would still be optimal solution.. but that's just my opinion

@adrian: finally had a chance to take a closer look and now I'm no longer sure how this could've worked at any point.. there was an issue where moving the mouse cursor over an absolutely positioned element within revision list triggered mouseleave on the parent element, effectively making it disappear. Should be fixed now in latest version at GitHub. It'd still be nice to hear back from you whether this actually helped Edit: and, again, thanks a lot for helping debug this issue!

@rachel: I'm sorry you've had a rough experience so far. First of all, ProcessWire is in many ways "lighter" than WordPress, but it's purpose and philosophy are entirely different. Having said that, based on your description your current needs may not even justify using a CMS.. or perhaps you might be better off with something designed to be, first and foremost, super simple. Don't get me wrong; ProcessWire is definitely simple and easy to use for developers, designers and end users, but it's primary goal is still being extendable and customizable, giving developers a lot of control over how things are presented and managed without making things complicated for end users. To summarize this: ProcessWire isn't necessarily what you're looking for. Regarding the issue here, it sounds like you've got wrong credentials for your database. This doesn't sound like a ProcessWire issue. I'd suggest that you submit a support request to your hosting company, providing them the same db information you've supplied to ProcessWire during installation and asking what could've gone wrong. I'm sure they'll be able to help you with this. Again, I'm sorry to hear how badly things have worked for you and hope you'll get proper answers from your hosting company.

@ryan, pulling those updates brought up something slightly weird with new modules page: "Found new module - JqueryMagnific" is a link to "#JqueryMagnific".. which won't work unless I first activate Core tab

@adrian no worries and thanks for your effort, the information you've provided so far is already very helpful. I don't have any OSX devices myself, but I'll try to find one somewhere (unless I can actually reproduce this with Win Chrome, that is.)

@adrian: interesting.. could you tell me a bit about your environment, i.e. browser and OS? Is this behavior specific to certain field or does it happen everywhere? I can't seem to reproduce this issue here, but I'll try to run some more tests soon. (Just for the record, I had similar issues with long revision lists, i.e. ones with scrollbar, when using IE9.. I'm pretty sure I already fixed that issue, but this sounds like it could be somehow related to that.)

Update: Pushed new version to GitHub just moments ago. This fixes some minor glitches and adds new "quick diff" feature. See attached screenshot for more details. It's very primitive at the moment, but I'm hoping to improve it (and some other parts of this module) soon. This is first actual "feature update" for this module, so I'm a bit nervous and would very much like to hear how it works for you. Tested it here with multiple browsers and fields etc. but I've probably again overlooked some issues. Regarding the diff feature, Google did most of the heavy lifting there; all I did was integrate their Diff Match and Patch library (JavaScript version) to my code. For the record I was going to use jQuery PrettyTextDiff, but that really didn't feel necessary considering that it's just an attempt to simplify the (already simple) DMP API.

Looks like I got confused by their UI, sorry for that Taking another look at it, the Matrix field seems more like having multiple types of repeaters within repeaters. Not sure if that's the way I'd prefer it, considering that this could easily be (ab)used to create some pretty wild combinations, but I'll agree that it seems very flexible. To compete with that, our repeaters would need to support a) multiple templates and b) nesting. Doesn't sound entirely unreasonable request, though I wouldn't be surprised if that raised some new issues. I wonder what Ryan thinks of this?

@ceberlin: just a guess, but have you tried get instead of find? Find returns PageArray, which could be the issue here. Get, on the other hand, always returns Page. Edit: that didn't help at all. This isn't possible at the moment.