teppo

Hi!

On a bit of a rush here, just some short answers:

1. Yes.
2. PageArray, when treated as a string, should look like that. See PageArray->toString() for more details. You can access specific items with $pagearray->eq(0), $pagearray->eq(1), $pagearray->first(), $pagearray->last() etc. or iterate it with foreach.
3. Through API or via admin UI? Both should be doable, admin UI has "copy" link and http://cheatsheet.processwire.com/ provides details for API side (tip: look for "clone" method from Pages or PageArrays.)
4. No, created date tells when page was created, i.e. added

@Ryan: not sure if you've included that in your version, but you might also want to avoid minifying content within pre tags.

Personally I'd also leave script tags alone. The minifying solution I used as basis for example code in my hooks blog post didn't originally account for that, which is why it blew my site apart under certain specific conditions. Could've avoided this by altering embedded scripts, but it felt safer to simply skip them.

If I really wanted to minify JS, I'd rather use a service built for that -- better results, fewer issues

@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.

Feasibly we could switch to a different icon set in the future, and the icon-iconname format strikes me as more portable? The fa-iconname format seems to be branded specific to Font Awesome.

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"?

@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.

Sorry to disagree, but this time the Craft CMS' Matrix field is far superior to what Processwire has now. Compared to the Craft solution, PW repeaters feel a bit clunky IMHO and they don't offer the same functionality. Time for us to catch up... 

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.

@Martijn: agreed.

I'm finding this interesting for perhaps a bit odd reason:

In the past I've had quite a few times when I had to dig data directly from MySQL. Since a page there doesn't "know" it's full URL, just it's name and the id of it's parent, a) locating a page is a bit of a hassle -- which is why I've often let page edit do that for me -- and b) getting useful page-related data (with full URLs, that is) directly with SQL queries is even more troublesome.

Sounds like this module, as a side effect, actually adds this "feature" I've been missing

Looks quite nice!

Agreed. Almost as nice as Repeaters in ProcessWire

Hi

Processiwre has attracted my interest and looks good so I'm am trying it out.

Hi there, nice to have you here!

What is the future of Processwire?

I don't want to tempt fate but what if something happens to Ryan and he can no longer serve processwire. Would there be a future for processwire?

I've got very little to add to Diogo's answer, apart from that there are quite a few of us who rely on ProcessWire for a lot of client work already. It's more than likely that someone would step up and catch the ball if anything like that was to happen.

Will processwire be further improved or will new improvements be payed for modules?

I asked this as I see that there are payed modules for pro cache and form builder.

Also are there any free form builder modules?

Have you seen the roadmap already? That should answer this question for most parts.

Another thing to note is that, at least from my point of view, both Form Builder and Pro Cache are larger, more complex modules targeted for audiences with specific needs -- developers building sites for more than just fun and most likely getting properly paid for it and clients with some serious traffic (Pro Cache) or complex form-related needs (Form Builder).

ProcessWire is very fast without Pro Cache.. and "regular" caching methods, i.e. without mod_rewrite method, are built-in features. There's also a built-in way to create forms, though only at code level, but if you really needed it there's nothing stopping you from building another UI level tool for creating forms, really.

Personally I'm also happy to support the great work Ryan has put into ProcessWire by paying when I've got those specific needs, especially when both modules are of superb quality.

Also if i purchase the processwire form builder for developer use, Can i still install it on sites after one year or am i locked in to yearly payment?

Please refer to resources Diogo posted.

Is there any difference between say the free WP Super Cache in wordpress and pro cache in processwire?

Taking a quick look at WP Super Cache, it seems to provide very similar capabilities, including serving cached HTML via mod_rewrite. Main difference would be that it's built for WP, Pro Cache is built for ProcessWire where both the environment and needs are slightly very different.

Do modules developed for processwire come under gpl licence as well since processwire is gpl like how it is with wordpress?

At the moment most PW modules are under GPL, but there's no constraint regarding this (not sure which you were after.) PW doesn't force developers to use GPL -- which is a very good thing considering that one license is rarely answer to all questions.

Just a few questions that are bugging me before I invest a lot of time trying out processwire.

It's better to ask now than regret not knowing later

@diogo: good call, though I'd argue that's an example of mixing design and style. I couldn't agree more with Zeldman in that those are two very different things 

Sacrificing big screens isn't really what mobile first is about. It's about design that works on as many different platforms as possible, prioritizing content and usability above everything else.. and only adding extra bells and whistles if you really think they are what desktop users (or any other specific user group for that matter) want and need. This definitely doesn't mean that you can't create unique or aesthetic designs, just take a look at some of these gorgeous examples of mobile first at mediaqueri.es.

You're right that mobile first isn't a perfect fit for all cases, but I've found that for most cases that interest me personally (i.e. where design, usability and content are more important than looks) it's awesome.. but then again, I'm not aiming for any art galleries, web design showcases etc. with my designs -- my ambitions lie in whole another field

Emulators (mobilexweb.com has links to quite a few, by the way) can help, but they can never properly replicate actual mobile device UX, which is why an emulator should never be your only option. That's also why projects such as Helsinki Open Device Lab are being set up by folks all around. If you're serious about mobile testing, older devices are usually cheap and as a general rule of thumb if it works on an older device, it will most likely work on a newer one too.. or someone has failed big time

When we're working on sites that need to look and feel great on multiple platforms, testing is done first with desktop browsers (scaling it up and down like you mentioned above) and then with default browsers of at least one Android phone, an iPhone, an iPad.. and often one Lumia. This gives us a good chance to "get it right", at least from UX point of view. To make sure that nothing "big" get's past our radar, we use services like BrowserStack to test with additional devices (and not just devices, browsers too.)

I wouldn't consider myself a mobile expert either, but I've found that KISS principle often goes a long way. Media queries and JavaScript are well supported across mobile devices, but I still prefer mobile first approach: start with the simplest, most usable form and build whatever eye candy you need on top of that. Not only does this make it more likely that your site works on a wide range of platforms, it also tends to increase overall quality as it forces you to focus on the most important things -- content and how it's organized.

Then again, personally I really dislike complex UI's, huge graphics and all kinds of bells and whistles even for large screens. If it doesn't add any real value, why should I even include it in the first place?

Antti, that should be fixed now, just pushed another version to GitHub.

Looks like you can't set the value of inline CKEditor the way you'd set it for regular CKEditor, ie. find correct instance and use setData().. not even if you first "force" loading that particular inline editor. On the other hand, inserting value directly to inline CKEditor's container div with .html() seems to work but feels a bit hacky