Leaderboard

At X-com we build and maintain ticketingsoftware, named Itix. About 20 Dutch Theatres run our software and since we've dropped maintentance our own CMS, we're slightly migrating more and more of those theatres towards a ProcessWire powered website. Using various API's and synchronisation tools, all needed information and actions are provided to the ProcessWire frontend, resulting in a cool e-commerce solution which is flexible towards the client and scalable for us. Our latest and greates is Schouwburg Venray. Go check it out at http://www.schouwburgvenray.nl The design was done by http://www.dejongensvanboven.nl The technical implementation by us at http://www.x-com.nl

https://www.maletschek.at It's online now for quite a time and my biggest PW-project so far. It has loads of content (sitemap) and the editors are loving how easy it is to manage - client quote: "it's a quantum leap forward" edit: screencast added here: https://processwire.com/talk/topic/10006-maletschek-nautics-boat-center-at-neusiedlersee-in-austria/?p=95531 Highlights shortcut edit-links almost everywhere on frontend with a single line of code in the template file (planning to release a module for this one day i find the time... or if anyone is interested in doing this i can share the code i have so far) and showing what part of the site is going to be edited on mouse hover point of contact for every section - option to inherit it to the whole sub-branch of the tree for example "jakob" is point of contact for boats and he will by default also be POC for every single boat posted in this section. if there is a different POC for one single page in this branch (eg /boats/small-boats/) that's also possible by checking the checkbox - so all boats on sub-pages (/boats/small-boats/boat1) will again have jakob as POC Caching with custom Cache Reset Module (necessary due to the previous point in the list) at least for me that's a highlight because that was the first time i needed to hook something... https://processwire.com/talk/topic/8997-clear-cache-for-all-children/ widget system with complete control of where to display the widget: in this example the "point of contact" widget is shown an all pages ( site "/" - "show" - "also on subpages" ) except section "blog" ( site "blog" - "dont show" - "also on subpages" ) yumpu online catalog textformatter module like on this page: https://www.maletschek.at/shop/bootszubehor/pfeiffer/ see forum thread here: https://processwire.com/talk/topic/9888-textformatter-yumpu-embed/ i hope you like it and i'm looking forward to hearing your feedback and of course thank you all for your help! ps: sorry, there's only a german version of the website

It sounds to me like your code is iterating through the $products (pages found by some selector I'm assuming) but some of those pages don't have the images field filled with anything, resulting in your error. Try to validate $img_src like this: foreach($products as $product){ $img_src = $product->images->first(); if($img_src) { // Check $img_src echo $img_src; echo $img_src->url; echo $img_src->size(300, 300)->url; } /** Let's see what pages don't have the images field set to anything **/ else{ echo "<br/> The page " . $product->name . " doesn't have the images field set to anything. <br/>"; } }

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

Do you mean some form of 'first-child-redirect'? So when you visit Parent 1 you are automatically redirected to Child 1. Put this on your Parent 1 template file. <?php /** * Template: First Child redirect * */ if($page->numChildren) $session->redirect($page->child()->url); taken from: https://processwire-recipes.com/recipes/quick-first-child-redirect/

What does bring you to that conclusion? PW maybe has the best ML support out of the box compared to other CMS systems.

Currently the 'Name format for children' setting is limited to: alphanumeric: 'test', will turn into 'test', 'test-2', 'test-3' etc. title: name will be based on the title once filled in (at first it will make the name 'unpublished', 'unpublished-2' etc.) date: the addition of any non alphanumeric character (including space) will cause it to be interpreted as date. So entering 'test more' will lead to some date string that doesn't make sense If possible i would like this to be made more fool-proof. But ideally i would like the 'Name format for children' to have more options. Like combining the different options and maybe be able to choose from more fields, apart from title. I also think that in cases where you want to auto-populate the name you often don't really care about the page title as well. So it would be cool if one could auto-populate a page title (and maybe other possible global required fields) as well. If the format would allow for date/timestamp, fieldvalues, text and combinations of those it would be really powerful. Also probably a lot of work but it's a wish-list after all

Another way could be to use two image fields, one called imagesbefore and the other imagesafter. Set them up to be displayed side by side each 50% width in the template. You can get them like for ($i=0; $i<count($page->imagesbefore); $i++) { $urlbefore = $page->imagesbefore->eq($i)->url; $urlafter = $page->imagesafter->eq($i)->url; }

Very, very nice! And thanks for talking through your approach to some interesting points

Hi, I've just "realized" again that I keep mentionning ProcessWire to some contacts. People who have just started using WordPress - or Joomla! - for instance, or are already using them. Some of them are also already using another CMS/CMF at their job (like CakePHP...). From time to time, I find myself continuing to try (even if just with a few sentences) to convince them to (really) try/test it. I think (as far as I remember) it's the first time that I act like this for a CMS/CMF. It's also the first time that I'm so "active" on a forum , even if it's not much. I would like to be more active, but I'm just a "newbie". It seems I can't help much. Wouldn't it be interesting/good for ProcessWire to have a sub-forum dedicated to all questions..., issues/problems... and advantages/benefits... related to the "transition(s)" from another CMS/CMF? NB: it's also the first time that I install/adapt/convert (to ProcessWire) myself front-end frameworks, static "themes"/templates or websites... PS: can someone add a space between "CMSs" AND "or" in the topic title, and perhaps add "something" before "similar", please?

Thank you @processing and @gemini I have to do something with the header i think, it's too simple, I don't like it anymore. Guess I need to develop some logo designing skills

Hey Peter - these are awesome! I posted a link to this thread on Github as a comment to an issue I brought up about this confusion I have seen: https://github.com/ryancramerdesign/ProcessWire/issues/968 I especially love the Choose and Upload tabs.

Speaking of images, here's some feedback from a client training session. Again, Images being the only area that confused my client. Process of steps.Everything good until after step 4 Click Insert Image in CK editor Click Upload Image Select a file from your computer Hit Save once the image is uploaded At this point, its unclear what the required step is. "I can see my grid of uploaded images but no indication that I still have to select one. It's made a little less obvious by the two Upload Image buttons too." and... "When I do select my image, I am presented with the cropping UI and more options (Insert this image, Select another image, Cancel) and I'm not sure what to do next".

I do multi language websites all week long in PW, what exactly do you think is missing?

Very well designed site. I love the approach of keeping it fast loading and still easy to navigate, read and sort through. Excellent job friend.

Hi tsd, I really like it, especially the minimal color palette and the easily readable fonts and layout. Nice subtle effects like the image rollover but it's still straightforward enough to navigate and to read the content. Good job!

Over time we have often had discussions about the nature of Pages and the fact that the term 'Pages', in context of ProcessWire(PW), can be misleading. Pages can represent a lot of things and serve multiple goals. (fun read: https://processwire.com/talk/topic/2296-confused-by-pages/ ) You are right that Pages can be seen as (URL accessible) data objects. What data a particular Page can hold is defined via the page his Template and the Fields added to that template. So a Template can, amongst other things, be seen as a data model. ProcessWire has its own way of organizing and relating data. While the underlying database structure might be different than most MVC-ish systems, the Page tree and the Page fieldtype allow for really flexible ways of achieving most, if not all, of the traditional model associations like in Rails' Active Record. Finding and working with pages/data couldn't be easier thanks to the great API, so i don't think there is a need for an 'ORM' because in a way PW already has this.

The Google Trends analysis IMO isn't of much help, it doesn't show the inherent "value" of PW as a CMS/CMF, it just throws hard to analyze numbers at the wall. In sheer numbers, WordPress should be the "B357 3V4R" solution out there. WP also benefits from having a LOT of marketing and PR involved, which the PW community doesn't really have (yet?). Look at the ecosystem around Laravel.. Laracasts, dedicated podcasts and blogs, training sessions and communities all over. It didn't get to be known with no effort, there has been a lot of time (and money?) put into it, the creator and his team have explained this numerous times. On another note, I actually have a two-pager to introduce PW to clients, unfortunately it's in French and heavily branded and I don't have much time to translate it right now. But it might be of interest. The main selling points I see and discuss in it — and I'd be very interested to know what's your opinion on this and what has worked well or not so well for you — go like this: Ease of use (for users and devs alike) — self documentation, data validation, fast development cycle Extremely fast — w/o caching, it's fast. With caching, it's fast as hell. Still need moar speed?! Throw ProCache at it and bingo! Static websites with all the benefits of a dynamic system and none of the pain of static generators. And fast websites mean better SEO, better visibility and better conversion rates! Win-win-win! Scalability — Does small and large scale sites really well. Hierarchical structure, when necessary, make it easy to manage content (plus it's built-in search system). Stability and security — Costs less to maintain and isn't very prone to attacks due to its inherent architecture. You don't need to update it every other day. Efficient development — Up to date development paradigms, easy to maintain and develop with growth in mind, content "agnostic" (i.e. it not targeted at one kind of use/market). Most things are already in core, no need to extend the core to do things I consider basic in this day and age, and pay annual fees for them on top of that.. I prefer to invest that time and money helping PW the best I can, that's how open source is best IMO. Relational content — It's hard to explain to clients, but it's seriously what generally cuts in when I need to select a platform for a client and really, PW wins hands down on this. Everything is a page and a page can be related to any other page in the way that pleases you. This enables really powerful contextual information, advanced "member" sections and such. I think that sums it up, then I usually add one or two paragraphs at the end that describes further why PW is a good choice for this project. Most of these arguments have been working well so far.

there are always countless arguments for/against any product. i often hear from clients: "one says this, the other one says that" then i show them what google says and they get big eyes: I've also a setup of a simple former joomla site converted to PW and show them the difference in direct comparison. that's the arguments they will understand - at least in my experience. most of them don't understand what we are talking about when we go in detail, so the trust a name they know, because they are afraid of making a mistake. that's psychology use this thinking for your (and PW's) benefit! make them aware that they can make a mistake by backing the wrong horse: good luck! PS: also make them aware that they don't only have to trust the product but also YOU as a developer/agency! the product is only one part - the other part is your work and what you make of it.

I had a realization recently about the PW data-model that I would like to share. The PW model is actually very akin to that of the Entity/Component model. Pages can be seen as Entities, and Fields can be seen as Components of those Entities. Templates can be seen as Component Types. One important difference from the E/C model, in terms of implementation, is the shape of the resulting entities - Fields are mapped directly onto Pages; or in other words, Component properties are mapped directly onto Entities, which means the Components themselves are limited to a single property at the model-level, even though some Field types are backed by tables with more than one property value, e.g. more than one data-column. I can't help thinking the resulting model is really close, but one step removed from being anywhere near as powerful as a real E/C data-model. To explain why I feel this way, here's a very simple case example. Let's say you have a shop with different types of products, many of which have at least one thing in common - they have a unit price, product title, and manufacturer name. With the PW model, I will add these three fields individually to every Template that describes a product type, and I will address these as, say, $page->price, $page->title and $page->manufacturer. Fetching these three fields requires three joins to separate tables. Conceptually, these three fields are meaningless on their own - they belong to a single component that defines the necessary properties required for something to "be" a product in our system. The, let's say, shopping cart service, for example, is dependent on the presence of all of these three fields and doesn't function if one of them is missing. With the Entity/Component model, instead of adding three individual fields, you define a component type that defines these three fields. You would address them as, say, $page->product->price, $page->product->title and $page->product->manufacturer. In other words, these three fields, which belong together, are exposed in the model as a single, integral component. Fetching these three fields requires a single join to one table. The ability to group together related properties in components has performance advantages (fewer joins/queries) but more importantly, it has practical advantages in terms of programming. You wouldn't need to group together related fields by prefixing them with "name_" anymore, which seems like an unnatural way to create a kind of "pseudo component". Adding/removing properties to a component property would naturally propagate that change to every entity that uses that component, rather than having to run around and update them manually. Controllers/services could define their requirements in terms of component shape. I realize it's a pretty substantial departure from the PW data-model, but perhaps something to think about for an eventual future 3.0. Or perhaps just an idea to consider for a different CMF in the future. Or perhaps just something interesting to think about and do nothing

Any website that promotes Processwire will always be of benefit and helpful by encouraging others to try out Processwire that are looking for a cms. But for me the best way is to focus on making Processwire the best it can be and everything else will follow. There are still many other areas of Processwire that can be improved on and when that is done and focused on I think Processwire will speak for itself. In my experience though admittedly I haven't built websites for businesses larger than 10 staff is that if you do your job properly and come across as someone who knows what they are doing the buyer of your service will be more than happy to let you make the decision on what is best for them as that's one of the points of hiring an expert in the first place.

I think it would be a great idea for us to set up a showcase site directed not towards end users but to developers' clients more specifically, as so many people on here have encountered, it can be difficult trying to explain the benefits on a case-by-case basis. It would be much more efficient to simply refer people someplace, or since plenty won't even do that due diligence, have a live and ready source on the web to visit with the client and show them in real time so they can ask any questions as they come up rather than put it off... (Of course anyone who wanted to like myself could do it themselves too. It's just time-consuming to do by oneself.) I like PossibleWith.PW I registered it and would happily donate it to the cause. So PW.pw can draw more "enterprise" or large-scale sites selected in/from processwire.com, give performance and other comparisons between different CMSs, maybe have a blog... if anyone wants to contribute, the Big Things Blog. We could just post inspirational and informative quotes from the forums and stuff... that are convincing and appealing to non-developers... Because it's like Pete said (on page 1, and then more I'm sure, as this convo has been spinning around) that we can't just have a flashy website to appeal to businesses and start like a whole operation catered to them... and like someone else said, most sites we build tend to be for businesses anyway (they're the ones buying)... but, of course, the ones buying usually like to be in control, and given that, despite not really having the expertise to make a well-informed major technical decision for themselves such as the CMS/framework to be used, will want to do so anyway. ProcessWire.com is aimed towards developers, as the CMS is, as it should be, because it's their business. When a developer comes to the site, he or she should be the one the info is targeted to because not having heard about it before, they're the only ones who will be able to make sense of the benefits. But that's why clients haven't heard about it, and why maybe we should put something together, somewhat separate, that's meant for them, that developers can refer their clients to rather than trying to convince each one individually every time…

Introducing PVC PvcCore: https://github.com/oliverwehn/PvcCore/ PvcRendererTwig: https://github.com/oliverwehn/PvcRendererTwig/ (coming soon) PvcGenerator: https://github.com/oliverwehn/PvcGenerator/ (coming soon) Each time I’ve built a ProcessWire page I’ve struggled with organizing (and separating) code, markup and stuff. Playing around with frameworks (backend as well as frontend) like Rails, Ember and stuff I really liked having a given structure, knowing where to put what piece of code. Therefor I started working on a MVCish way to deal with templates in PW that considers the $page object kind of the data/model layer and adds View and Controller upon it. First by just catching everything via a small processor file added to all PW templates as altFilename. I’ve digged a bit deeper since then and hooked into the native rendering process, have been refactoring my code base more than a dozen times. Now I got a first version that seem to work and I’d love some of you guys to try it out! PVC (instead of MVC) stands for Page-View-Controller, as it considers PW’s $page var the model/data layer. I’m still working on the README.md on GitHub to document the basics. So have a look for more detailed infos there. I’ll give you a short overview here: Code separation: PVC introduces views and controllers to your PW templates as well as multiple action templates. Controllers, as most of you already know, keep all the business logic. Controllers execute actions wired to routes (urlSegment patterns). Even routes with dynamic segements (e.g. /edit/:id/) can be defined and assigned to an action, providing input through $this->input->route. Values can be set on the controller to be accessable in your templates later on. It’s also possible to set dynamic values as closures to be calculated (e.g. using field values of the current page) on render. Also controllers allow you to set layouts, styles and scripts to be available in your layout or template. Logic can be shared through inheritance between controllers. Views introduce view helpers. Helpers are functions that are made available to you (only) within your template context. There are predefined ones like embed(), snippet(), styles() or scripts(). But you can implement your own helpers easily and share them among your view classes through inheritance. Action templates contain the actual markup. Every action defined in a controller uses its own template. So the same page can display content accordingly to the action that was addressed via urlSegments/route. Within templates you can access all field values and values set on your controller like globals (e.g. <?=$title?>). Modular renderers: PVC implements rendering through separate renderer modules. PvcCore comes with PvcRendererNative that gives you template syntax the good ol’ PW/PHP way. A Twig renderer is in the making. And maybe you want to build your own renderer for the template syntax of your choice? I consider the module an early Beta version. So make sure to try it within a save environment! Would love to get some feedback (and error reports). I’m no professional developer, so code quality may suck here and there. So I’m glad for inputs on that, too. Also there is some old stuff in there yet, I still have to get rid of.

I think there is just a fundamental difference between what you are looking for in a CMS, and what ProcessWire is. That's not a bad thing. Some people think cucumbers taste better pickled. I currently work with ProcessWire in a University environment (300-500 active users, depending on the number of faculty during a semester). ProcessWire has not only been up to the task, but has far exceeded everyone's expectations. Both from a design/development standpoint, as well as UX for the site editors. One install powers a fairly complex public site (launching in the next few weeks), a faculty/staff intranet, a travel authorization and payment system, a news and events management system that handles around 500 events a semester with dozens of editors, an automated user management system that queries LDAP to determine user access and roles (runs via cron 3 times a day), Faculty syllabus manager (800+ documents a semester, maintained by hundreds of different users). Integration with MailChimp, some basic integration with BaseCamp, user generated forms (powered by FormBuilder), custom user dashboards, etc…, etc… Do you need to know how to code to use ProcessWire at this level? Absolutely. At least a little. In my opinion, that's a good thing. It means you can respond quickly to development needs. It means you can build solutions to suit, and not rely on pre-packed solutions that may not meet all project requirements. It means that you aren't constantly dealing with security patches, upgrade, etc… From a frontend development standpoint it means you aren't trying to work with markup that is bad/dated or has 17 classes on each element. I've been able to accomplish things fairly easily with ProcessWire that I bashed my head against for ages with other CMSs. Are all the typical "enterprise" checkmarks present in ProcessWire? No, but that isn't what ProcessWire is — and I hope it's not something it ever tries to become. At least not in the traditional sense. Depending on your needs and skillset; other CMSs may be better suited. ProcessWire might be a pickle—when what you really want is a cucumber.

Having worked with senior Marketing in Enterprise sized organisations and even a Fortune 500, I can tell you right now what they expect from a CMS. Some of these might be suprising but its good to know. Comprehensive users / usergroups / roles / access permissions etc etc File management and secure file hosting Draft to staging to published workflow Related to above, ability for admins to review stuff before it's live (including getting notified when pages are ready for review) and share pages with other team members for review Form wizards so they can build their own forms Media management Custom dashboards for their "own" areas Round the clock support Approval from their IT department etc who review security, upgrades, patches etc etc BTW, my involvement with these companies was not website related but I've seen their setups and spoken with them in the past about such things. I'm happy to run any specific questions from Ryan and Co past them if more detail is required.