MatthewSchenker

Hi Ryan, Terrific! It's excellent the way you continue extending the powers of ProcessWire while still leaving the clean stucture in place and not making any assumptions about how the API must be used. Looking forward to 2.3! Thanks again, Matthew

Hi Soma, Thank you for the update. I'll go in and try this again. Having a "blank" starting point is definitely a great option. Thanks again, Matthew

Greetings, I use this logic extensively in my sites to display only those articles that have a certain checkbox checked. I think of this as a way to create "instant categories"! Here is an example of the code I've been using. In this case, the organization has several "events" (each with its own checkbox). In the example below, the template displays a series of "intro images" only for "annual festivals" (in other words, the user checked "annual_festival."): <?php $eventlist = $pages->find("template=event, annual_festival=1, sort=-date, limit=50"); foreach($eventlist as $event) { ?> <div id="listings_box"> <img src="<?php echo $event->intro_image->size(300, 225)->url ?>" /> </div> <?php } ?> It works great! In your case, once you find the pages that are checked according to your requirements, you can then call the relevant text field. Thanks, Matthew

Hey Ryan, Great! I was actually going to raise the question of the "latest" posts. I can't tell what the forum software does with this exactly. Is there a way to set it so you can just posts in date order? Thanks, Matthew

Hey Ryan, Thanks for the excellent explanation! I see what you mean about the differences between ProcessWire and Laravel. But what's interesting to me is that practically all the goals I've been able to name can be achieved with either a framework or with ProcessWire. Regarding the JQuery approach: after delving deeper into ProcessWire I am seeing the logic of this more and more. The reason I compare ProcessWire to Laravel is because there seems to be a common philosophy about clarity of code. I have heard others talk about combining Laravel and ProcessWire. I have come to appreciate both systems, so using them together would be an amazing idea. Can you give an example of a goal that could be achieved in this manner? Thanks, Matthew

I always get the same error. Everything installs fine and looks fine, until I try to log in. Thanks, Matthew

Hello, Very nice! I have not really explored admin themes yet, but this one definitely looks like a candidate. Yes, I think Github is the place where everything needs to go now. Thanks for doing this. Matthew

Hey Ryan, Excellent points about security! I've been shouting about this in the Joomla world for a long time. Every time a client tells me that Joomla can do things "faster," I remind them that whatever time is saved up front, you lose most of it in subsequent updates and issues that arise down the line. And this isn't even getting into the fact that most Joomla modules are a "black box" where you can hardly isolate what code is responsible for which actions, which makes it difficult for you to just fix it yourself if needed (actually, it's difficult to pinpoint even where the code resides in your Joomla installation). OK, calming down... Thanks, Matthew

Greetings, Thanks Ryan for giving us one more tool to make our sites better. This brings up the constant need to emphasize to clients the need to follow some basic principles with photos! It seems that with every project, I have a tutorial session with the client explaining that photos need to be of the same proportion, NOT cropped in all sorts of ways, and more. I've started putting this together in some standard documentation I share with them. Having options in the API like this can help overcome some issues with photos that are not right for the job. Client education needs to fill the rest of the void! Matthew

Hello Everyone, Thanks Soma! My reason for asking is because, except for a handful of actions, I have been able to replicate everything I was doing with CodeIgniter/Laravel here in ProcessWire. Actually, on the Laravel forums there are two related discussions about this. If you haven't seen them already, go here: http://forums.larave...id=21881#p21881 http://forums.larave...?pid=4627#p4627 There is also this: https://twitter.com/...018610362232832 I find this significant for a couple of reasons. First, because there have always been three branches of Web development for me: 1. Pure and Naked PHP 2. Fully-Baked CMS 3. PHP Framework I'm being a bit colorful, but I think you all know what I mean by "pure and naked" and "fully-baked." Of course, there are CMSs built with frameworks, but I had never found one that maintained the total freedom of the framework while also providing the crucial "engine" of a CMS without making too many assumptions. I know a few that come close. ProcessWire is the only one I have found (and I have tested a very long list of CMSs and framework-based CMSs). The "fully-baked" CMSs are not worth comparing really. If people in the Laravel community are recognizing that ProcessWire does the framework-based stuff really well, and also gives you those CMS functions every project needs, it's a big story. Thanks, Matthew

Hey Ryan, Thanks for the input. As you mentioned, through experimentation I naturally came to see the benefits of re-using fields. I'm glad to know that even if fields are re-used it does not affect performance. But as you said, there are other benefits to re-using fields. For my first couple of tests with ProcessWire, I re-created fields for each template. I did that because I needed, for example, different descriptions for text fields in each template. But then I realized that I could get template-specific descriptions using a different (more efficient) technique, and I "collapsed" all similar fields into one that gets re-used across templates. Then, when I turned my attention back to my template PHP files, I naturally discovered that templates for various content types could be easily copied and re-used because they referenced similarly-named fields. This is great. We know that re-using is not necessary, but we know the benefits of doing it. Thanks, Matthew

Greetings, I've been using the counter developed in this thread, and it's terrific. I'm just digging into the code in recent days. It does seem, as boundaryfunctions explains, that any solution has its limits. But for the sake of being straightforward so the client has no confusion, I think the current solution works well. Here's my thinking, based on the current project I am working on for an arts organization... As the developer, I am always the one determining which fields are placed into the template: I have yet to have a client ask me if they can add a core field to their templates on their own! Therefore, I can figure out ahead of time whether or not I'm including a field that needs character/word limits, and I make sure that the type of field I include is correct for that purpose. In those cases where the client is more sophisticated and wants to add fields themselves, they would be sophisticated enough to know which fields are capable of character limits. One of the things I love about ProcessWire is that it keeps everything as clean as possible. Following this philosophy, I think the current use of the character limits element works best. It simply requires reasonable understanding from the developer or the client. (Extrapolating, I think the character limits element is a good example for other elements.) Thanks, Matthew

Greetings Everyone, I've been meaning to get into this here, so... I'm getting into this here. Before coming to ProcessWire, I spent quite a bit of time getting familiar with PHP frameworks. First, it was CodeIgniter, more recently Laravel and Symfony, and Yii. I really like these frameworks (especially Yii, even though Laravel is getting all the attention lately). However, I can't help but feel that ProcessWire takes care of all the same things that these frameworks do, and it has the core user, database, and other capabilities taken care of. There are still a few actions here and there that I can pinpoint better in Yii or Laravel, but it feels like ProcessWire could definitely close those last few gaps. Of course, we refer to ProcessWire as a CMF, which clerly indicates "framework." But are my instincts correct in saying that ProcessWire is built on a framework that is equivalent to something like Yii with core CMS capabilities built on top? Thanks, Matthew

Greetings, Just to warn everyone... I am in touch with a couple of other Joomla power users, urging them to check out PW. Speaking for myself, I believe the main barrier to switching CMSs is the legacy stuff you already developed. It's amazing how you can go for a long while knowing that the system you're using is not right, but you keep using it because... Well, because you have been using it. At some point, though, you just close your eyes and make a leap. For me, I was poised for a switch for about a year, but I had to wait until I had just the right bit of downtime between projects. In this way, ProcessWire has another big advantage: we can honestly say that switching from your current CMS is not painful, because PW is so clean and intuitive. There are other CMSs that are also good -- and you know they are good -- but it takes a bigger up-front time investment to become familiar with their quirks. Of course, all systems have their quirks. There are just fewer of them in ProcessWire. And the payoff is so much greater! Thanks, Matthew

Hello, To diogo: I fixed it and edited my post above. Somehow I ended up trying to add a new app rather than add a "like" to an existing one. Still, alternativeto.com is funny. Tumblr gets ranked highly as an alternative to EE? Thanks. Matthew

Hello, Why did I feel a buzzing in my ear this morning? Oh, I see! Let me get this straight: I have to take responaibility for Joss being here? Quick story... I learned about ProcessWire over a year ago, through a ModX forum discussion. I was very impressed that in that arena a lot of people expressed respect for Ryan's achievement. But I did not start using ProcessWire then because I had invested heavily in a Joomla CCK system (long story). But then, just a few weeks ago, I saw a discussion on the Laravel forum where -- again -- a community of people not directly interested in ProcessWire expressed respect for what Ryan was doing. It was the right time for me to take the plunge. It took only a couple of days for me to replicate everything I was doing with the CCK -- and to be able to do a lot that the CCK could not do. So here I am -- fully into ProcessWire. OK, that was not such a quick story. But remember, I am responaible for two people here! Thanks. Matthew

Hello everyone, As others have said, it's too bad about EE. At one time, I thought EE was the best CMS, and I still think it is pretty amazing. But I like to experiment and develop ideas freely. Even with the old pricing structure, this was not really possible with EE. Under the new stucture, it's even less feasible. But what's most relevant is that I can replace everything I did in EE with ProcessWire, and in ProcessWire it feels more "natural" and closer to pure PHP. I also really liked CodeIgniter. It was the framework that introduced me to frameworks. But even here, Laravel has taken the framework role. I think that with Ellis Labs making such pricing decisions, a lot of excellent and generous CI contributors will feel that their contributions make more sense in the Laravel community. And by the way, there were hints about the licensing issues over a year ago, when Ellis Labs changed the license type for CodeIgniter. Regarding posting in the EE forum: I would personally be against that unless a discussion had already developed over there about alternatives. I think that posting blog entries and commenting on other blogs is the better way to go. Thanks, Matthew EDIT: I added my "like" to alternativeto.com!

Greetings, I think re-using fields makes most sense, as long as the fields are really equivalent from one template to the next (as apeisa says). With contexts, you can re-use fields and still have them be unique for each template! Thank you for this, ProcessWire! One advantage I am seeing with re-using fields is that I can regularly create "inc" snippets that can be inserted into different templates that have identical sections (same set of fields). For example, in my current project for an arts organization, they have "events" that fall into several categories. I have separate templates that reference the same core "event" submissions, and using a $pages reference, each of the templates filters the results according to what someone checked off on a check-box (event category), but many other parts are identical across the templates. Just an example. Thanks, Matthew

Greetings, I'm glad someone is talking about this here. If it was April 1, I would think that Ellis Labs' decision was a bad joke. But, apparently, it is serious. I have used EE for a couple of projcts. I stopped using it a few months before I discovered ProcessWire. It's a great system, maybe the best out there after ProcessWire. But the new pricing scheme will drive away all but the most lucrative design studios. Just to lanch an EE site costs about $2,000. With middle-of-the-road support, the first year for that project starts off at about $4,400, with recurring minimum service fees at $2,400/year. To have same-day support, the first-year cost of a site is -- not kidding -- about $26,000, with recurring minimum service costs of $24,000/year. Some of my customers could bear that, but I would clearly have to reject all arts organizations, non-profits, community concepts, not to mention any of my own "pet projects." But the real damage will come from the fact that in the famed Ellis Labs forum there is an understandable reaction from many valuable and active members who are obviously not willing to continue offering free advice to support Ellis Labs. I'm puzzled by this move. It's too bad -- seriously. I think it will not only drag down EE, but may also take CodeIgniter with it (and CodeIgniter has been having enough trouble lately as it is). But yes, to the main point of this discussion, it might bring new people over to ProcessWire. Thanks, Matthew

Hey Ryan, It's always very reassuring to see your name and face in a discussion! I'm very glad to know that these validation elements are in the development branch. I'm going to start testing/using that one some more! I guess this is one more reason to be excited about the next version. Thanks, Matthew

Hello, Apeisa: thanks for your valuable input and contributions. I've looked at the module you created and it seems like a terrific solution -- all ProcessWire! Now that I have compared using your module side-by-side with the PW/FoxyCart arrangement, I think that with a bit more your module gets the vote. Going the FoxyCart route, we are using native PW and hooking out for payments. With your module, we can do more inside PW, but still go out for payment gateways. This is the only remaining hurdle. How are you handling gateways now in your live shop? Thanks. Matthew

Hey Ryan, Welcome back! I apologize for adding so many posts to the forum in your absence. In my defense, I will say that Joss's output over the past week was at least double that of mine. Thanks, Matthew

Hey Soma, We are all very fortunate to have you here! I always look forward to your posts. You and I have discussed front-end editing smoothness before, in other posts. The method I have been using is to create access to the admin areas, with user rights limiting who can see what. But your approach is nice -- more friendly for a lot of users. Thanks for your terrific help, Matthew

Hey Pete, Yes, what you said is exactly right. For the sites I'm developing now, I don't have product variations. I've played with FoxyCart more today, and I have written to the developers with some questions. Based on my reading, and the way the developers communicate, I must say there is something about FoxyCart that seems very much aligned with the philosophy we all like about ProcessWire. The developers have an attitude that the system should provide core capabilities, but not intrude on styling or structure. Also, the way objects are accessed in FoxyCart is very much in line with the JQuery/ProcessWire fundamantals. I'm also continuing to look at Stripe, and testing ways to take ProcessWire forms and go directly to that system. But right now, FoxyCart is still in the lead for my upcoming projects. Shopify continues to be a contender for other projects. One correction from my earlier write-up: FoxyCart does allow more use of statistics than I had thought. You can get XML feeds back to your site/database from FoxyCarts transactions. That's very exciting, and the flow seems to look like this: START INSIDE PROCESSWIRE [site design/database/product pages/form development] EXIT PROCESSWIRE BRIEFLY [sensitive monetary parts] BACK INSIDE PROCESSWIRE [customer and transaction data/build datatables] In other words, I only have to leave ProcessWire while handling the parts that we are better off not dealing with, but can stay in ProcessWire for the parts that it does better than anything else. I'm also thinking that it's possible to create a FoxyCart module where you could automatically feed certain fields to FoxyCart? I'm putting together a full shop test site with ProcessWire and FoxyCart. I'll report back more on my tests. Thanks, Matthew

Hello, Thanks Pete! You have helped me find a tie-breaker between Shopify and BigCommerce! I much prefer a system like FoxyCart, where I can use ProcessWire as the engine of my site and just hook into the e-commerce app for the actual processing of cart actions. Diogo: It would be great to see apeisa's module develop all the way! That would be the best solution, since it would be a native ProcessWire system. In that case, I would think that just hooking into something like Stripe would be great. It seemed as though development had stopped on apeisa's module (last update was 8 months ago). Or am I wrong? What's the status on it? I've got three fairly large e-commerce sites that I am about to develop, and I really want them to showcase the powers of ProcessWire, so now is the time for me to get into this. Thanks, Matthew