Leaderboard

Let me give you a bit of insight on my latest project: http://dreitagewoche.de It is a weekly updated, hand crafted event calendar for Hamburg in Germany. Its team looks for the most appealing events every week and collects them for the three days of the week that really matter: thursday, friday and saturday. It features parties, exhibitions, concerts, festivals, theatre and everything else a bit of the mainstream. On the technical part (it uses PW 2.3): Single events can occur on multiple dates and support a link to a location (page) with Google Map coordinates. Beside events we support blog-like entries and regular pages and other stuff. Events are displayed based on their date, showing up in an archive when they aren't up to date anymore. This method also allows for a custom preview of all upcoming entries for the editors. I make use of template caching which speeds up the page remarkably. Beside that I am using some modules, including twitter feed, soundcloud embed, vimeo & youtube embeds. The backend is modified using admin custom pages module which allows me to tailor pages showing only upcoming events or locations. With around 30 pages added every week this was crucial. Overall I am very pleased with PW: It performs well, is easy to develop even with nested data and is fast and intuitive enough on the backend. And a full deployment means basically just a few clicks and a coffee while it is uploading. One thing that did trip me was customizing the backend and actually the obvious need to do it. With hundreds of pages the normal view is not as helpful as I thought. The module I mentioned did help a lot, without that I would have been in trouble. I am looking forward to using PW 2.4 on a project like this and how it accomplishes those challenges. Let me know what you think, especially about tailoring the backend and dealing with lots of pages. I attached a screenshot of our backend (it is 2.3 and a modified backend theme, based on ergo theme) Cheers!

Blogs are just a collection of features around the "date-ordered content" idea. For example, the Tesla blog: http://www.teslamotors.com/blog-and-press-releases Features: Articles listed in reverse date order Articles show a thumbnail & linked title, byline, date, and tags listing. The sidebar shows features to show articles by tag, by date, and then there are some links. Individual articles show a date, title, byline, tags list, then the article body (text, images, videos), followed by comments. Sidebars for individual articles show social media sharing links. This is all (relatively easily) doable in ProcessWire with any kind of layout, so it's up to you and your client to decide what their blog will be. That's true, but remember that your client may be hoping that you will give feedback about what they are asking for. In my opinion, and according to many of my clients, a valuable part of my job is pointing out to my clients the common things that people always want later but don't think they'll ever want when they're first thinking about their site. The blog (or whatever they want to call it) is one of those things people always want at some point. In the space of three weeks one of my clients went from "we have a blog that we never update" to "please remove our blog" (with that why-did-we-ever-do-that finality) to "please put the blog back, but hide it from the front page of our site if we don't have any recent articles." Businesses almost always reach a point where they get frustrated if they don't have a place to display timely information about changes to their business. My short list of things people usually leave out, that they should really not neglect: Blog / news area Website search function Site map Privacy policy I will often let the discussion slide if the client is feeling overwhelmed with a cool new site with hundreds of features. If that's the case, we can talk about this stuff later when I have their fresh analytics data in hand. When even the most stubborn client sees a comparison of "actively blogging and sharing content" visitor stats vs. "just a brochure website" visitor stats, they tend to take a more nuanced view of the value of a website. I try to blog actively on my own websites so I know what kind of results they can expect from the additional marketing communication.

I'm not sure I understand your structure, but I think the query could be optimized. Couldn't you get all the listings with one query, something like this: $listings = wire('pages')->find("template=listing,parent=/listings/"); // Then pass the page directly in your function, no need to call find() again in the function foreach ($listings as $listing) { echo generateListing($listing); }

$event = new Event(); $event->date = "1979-10-12 00:42:00"; $event->location = "Vogsphere"; $event->notes = "The homeworld of the Vogons"; $page->events->add($event); That's one way to do it, at least. Since $page->events here is events field it returns an instance of EventArray, which in turn can contain multiple Event objects. For the most part EventArray acts just like a PageArray or Pagefiles or any other object extending WireArray. This is just the most basic example of what you can do with it.

Best to start with guidelines to stay out of trouble. GOOGLE : http://www.webmasterworld.com

@muzzer: most fields (almost all of them) are only loaded as required. You can check "Autoload" within field settings (Advanced tab) to always include it with the page, though. This makes sense especially if that field is always used when the page is loaded. You should also take a look at built-in Fieldtype Cache too; sounds like it could be exactly what you're looking for here. It's a core module but not installed by default. I wrote a quick post about caching in ProcessWire a while ago, you can find it here. It's not too in-depth (and doesn't mention aforementioned Fieldtype Cache at all), so I'm not sure if it provides you any new information at all

Hi Russel, welcome to PW Yes you need the .rb file if you are using Compass and you're right implying that there is nothing 'special' to do to make Compass & SASS play with PW. One easy way to start is to build the HTML (CSS, SASS, Compass) for a static page ignoring PW to check you are happy with your implementation of those technologies (that they work) then set about slicing up the one HTML file and replacing it with PW. For example at it's simplest getting PW to render the content of the TITLE tag to check the page outputs the static HTML parts and the new PW part (the TITLE tag) all the while keeping the structure all good for Compass and SASS. Once you have this sussed then it's just a case of how you build your pages (templates). There is a FAB site to deconstruct and learn from, I can't recall which it is :/ sorry, but I think it's the skyscraper site. You may want to buy CodeKit if you've not done so already. This is a huge topic and mine is a little reply post so sorry not told you more or specifics, but bottom line PW is completely agnostic of your mark-up, CSS etc and it will work BEAUTIFULLY with Compass, SASS, Susy (Susy is superb). Good luck and enjoy

Create this structure: [ later on used for the Inputfield type Page (Multiple) ] Home | +-- Types (template: types) | +-- Stallions (template name: type) | +-- Broodmare (template name: type) | +-- Colt (template name: type) | +-- Foals & youngs (template name: type) | +-- etc. // both templates need no template files To the template 'type' you add a textarea with a WYSIWYG editor if wished. On the Horse Template 1 ) a checkbox, named: horse_owned, 2 ) a checkbox, named: for_sale, 3 ) an Inputfield type Page, see structure above name the field 'types' Group template ( Our Horses & Horses for sale ) Assign the same fields as above to this page. 1 ) a checkbox, named: horse_owned, 2 ) a checkbox, named: for_sale, 3 ) an Inputfield type Page, with the structure drawn above ( Name it types ) The real purpose of these fields in the 'group' template are for building the search query to the horses you want to list. (Tell you later more about this) Enable urlSegments to this template. Create a Page with the group template named 'Our Horses' Check the checkbox 'horse_owned', so it has the value of 1 Leave the checkbox 'for_sale' unchecked. For the 'types' field select: [x] Stallions [x] Broodmare [x] Colt [ ] Riding Horses [ ] Foals and young horses Those checked pages are used for the urlSegments. Basic structure of the PHP file could look like this: $segment = $input->urlSegment1; $types = $page->types; if ($input->urlSegment1) { $name = $sanitizer->name($input->urlSegment1); $type = $pages->get("template=type, name=$name"); if ($types->has($type)) { echo "<h1>{$type->title}</h1>"; // echo $type->body; // assumed the textarea added is called body // scaffold the search query $query = array( 'template' => 'horse', 'types' => $type, 'horse_owned' => $page->horse_owned, 'for_sale' => $page->for_sale, 'limit' => 10 ); $query = array_filter($query); // remove all boolean false elements from array $string = ''; foreach ($query as $key => $value) $string .= "{$key}={$value}, "; $string = rtrim($string, ", "); $horses = $pages->find($string); if(count($horses)) { echo "jay we have the horses"; } else { echo "Sorry, at the moment we don't have the horse that you're lookin for." } } else { throw new Wire404Exception(); } } else { echo "<ul>"; foreach ($types as $type) { echo "<li><a href='{$page->url}{$type->name}/'>$type->title</a></li>"; } echo "<ul>"; } (not fully tested, so could have a bug or 2 )

My client of the day had a little problem with handling Processwire. He just wanted to delete a picture on a page but he ended up on deleting the whole page and it's sub pages. All glory to the trash and the ability to restore pages. Not so long and I will have to install teppo's version control module solely as precaution for "accidentally" deleted content.

Sure! If you switch a lot between different projects you'll have to either start several instances or you'll "up" and "halt" them all the time: The first way is very "costly" in terms of performance, the second one in terms of time The generated isos tend to be quite big (around 2.5 GB): If you're working on 20+ Projects you'll either have to constantly delete (and therefore re-init) them or waste a lot of disk-space We've experienced some rather standard setups to be very slow even if we gave them a crazy amount of Memory (4GB+). This was especially the case with larger ModX sites (which has a slow backend anyway) On Windows (which we use for development) sometimes vagrant just keeped crashing on startup for unknown reasons Crazy caching behaviour: We mounted our local work folders into the VM but sometimes they just won't get updated for minutes Plus some very "Workflow related" issues that are not that important

I'm now on page 70-odd of stories on the Clients from Hell website... it's a bit addictive, and quite amusing

I use Prepros and then just get it to watch the right directory. So, with Foundation 5, for instance, I have all the scss files in a directory called scss within templates. And then that outputs to a foundation.css in a css directory. And that is about it. Really, it has nothing to do with ProcessWire at all, other than with PW all your template work needs to be inside /site/templates/ so that is where you need to do it all. If you go look at my foundation profile: https://processwire.com/talk/topic/5293-zurb-foundation-5-profiles/ You dont need to install the entire profile, but if you look at the templates folder, all the foundation bits are all ready to go, with all the scss files.

@Valery, Thanks for the explanation. I would use pages too for each product in this case but probably not repeaters since they are not infinitely scalable. At some point, they do require a lot of resources since repeaters are just pages "hidden" in the admin and when you edit a page with repeaters, you are editing all items at once. Instead of repeaters, I would create a simple Process Module that would list the products (your pages with products) and their status in a Table. You could even have two tabs - one with new orders only and one with older orders (older versus new could be differentiated using a checkbox, for instance). I don't know how comfortable you are with coding but this is not too complicated....

Sounds like a decent idea - perhaps you could try to parse the results of the delegates value first is exec is available on the server, and if not, then get them to run the test?

But now we know why icc conversion is not working on your server. We can ask the user to run a simple test during module installation that he should answer with yes or no. Trying to convert a cmyk to sRGB or something. If it looks better after conversion, lcms seems to be available.

I don't understand the assigning of $id to the id of a page named "page_role". Are you trying to get the id of an access role? That is what you would need to then assign to the template's edit/add/create/Roles. EDIT: You can get the id of school1 with: $id = $roles->get("school1")->id;

And rebuild the EventsFieldtype a little?

Since I'm not keen to do the work for everyone here, as I already had done a lot and multiple times in this very thread. It's all here and more even in the readme of this module. With a little study you'd be able to do what you wan't.

@einsteinboi This setup is somehow strange and very unusual. I try to avoid having too much classes. For example no need for classes on <a> items. It's more flexible if using class only on <li>'s since you can style containing links. You now have twice the class for a dropdown: <li class="dropdownSubmenu last"><a href="#" class="hasSubMenu">Sub menu</a> ... Makes no sense and don't see why that's needed. A lot what you have in the markup example doesn't make sense to me to do it this way. I usually build my navigations with little to no classes and work with what MSN has by default, instead of trying to adapt MSN. With right CSS and JS every type of navigation is possible without doing much. You can however modify a lot with MSN options and simple hooks. Almost everything is possible, and even if it takes some time, writing own nested lists with all those features wouldn't be less difficult.

Hi, I have experimented with naming of images. For people who want try out different settings with images, the current naming scheme isn't of good usage. I have added some code to the Pageimage::size method, Pageimage::isVariation, and to the Imagesizer to make it work like here: http://images.pw.nogajski.de/new-naming-convention/ It is open for discussion --- Additional to that I like to implement a new temporary option on a per image base to force recreation of the requested image also if a cached version is available. I don't like to use all the time $image->removeVariations(). What is a useful option name for that? forcenew recreate forcecreate forcerecreate ...? $options = array( 'cropping' => true, 'quality' => 80, 'forcenew' => true ); $img = $image->size(120, 160, $options); --- And for the naming convention I am unsure if a short custom appendix should be enabled too, or if this would be to much? $customappendix: a-z0-9 strlen max 10 ?

There you go Renobird, Teppo has stolen my thunder @Teppo - Thanks for sharing your code

I think there is no general answer possible It very much depends on your configuration of MySQL, assuming you're not using another database. If the query is simple and you have indexes or query for the primary key, it will probably be very fast Maybe you can do some performance testing for both possibilities? Cheers

you may have reached a point where MSN can't exactly output the precise markup you need, though maybe its possible; MSN is really amazing and can do some really complex menu structures; but if you want to build a megamenu, then you might want to consider doing your own menu system: https://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/?hl=%2Bcustom+%2Bmenu i just setup a menu for a site which uses both regular menu drops and also mega menu; i was able to get that to work by putting an option in my menu-item template for it to activate the mega menu, then there is a way to group the child items of that into columns etc..

This might be a dead topic, but I'm looking at doing an implementation using Google Analytics (GA) API to do that on a website that has caching (and don't want to create too much custom cache code that I'll have to maintain afterwards), using a cron job. I looked at the documentation, and tried a few things with GA's Query Explorer : http://ga-dev-tools.appspot.com/explorer/ https://www.googleapis.com/analytics/v3/data/ga?ids=ga:YOUR_GA_ID // Set your request metrics here &metrics=ga:visits,ga:pageviews // Set a filter for your page, you can combine multiple paths into one request using commas (OR operator) and multiple pagePath values &filters=ga:pagePath=~/event/x/,ga:pagePath=~/en/events/x/ // start-date cannot go before 2005-01-01 (GA launch date) and end-date should be set to today &start-date=2005-01-01&end-date=2014-04-15 This will return json data that you can then insert into a field. All in all, it seems easy: Setup a script that will parse all pages, get multiple values, create a GA Api query, get values, update database fields. Note that there are limits and quotas to the API. For what I need it, it's not a problem, but you might need to reach support to get more info. Hope this helps some of you.

Sorry about that - I just pushed a new version that supports grabbing the thumbnails when saving a page through the API as well. Let me know how it goes.

@Pete: we are on the same side (in german: "Du rennst bei mir offene Türen ein") +1 for implementing cc, bcc and attachment into the WireMail base class! Regarding attachments: https://processwire.com/talk/topic/5704-module-wiremailsmtp/#entry56631

I'm going to highlight this again horst as it's the important bit So whether yours or Teppo's module is installed or neither, emails can still be sent using the default Wiremail class. Therefore if I'm writing a module that requires email sending functionality, it needs to be able to use the same functions whether it's ryan's base module, the SwiftMailer class or your own module or module authors won't know what to expect. I think these WireMail modules need to be coordinated somewhat so that whatever the base class supports, the other classes also support so there are no surprises.

I think Ryans initial intention was to support the common basic usage and give us an easy to use possibilty to cretae submodules that can _extend_ the base class. But I am definitly not against extending the base class with cc, bcc and attachment

You can create a blog component within an existing site using PW templates and page fields for categories and tags. I know that kongondo is working on an installable blog, which will be awesome, but if you want to use Ryan's blog profile in an existing site, you can try this out: https://processwire.com/talk/topic/4420-page-list-migrator/?p=56484 This will let you install the blog into any subpage of your site and includes all the files required to make it work out of the box, although the styling will match Ryan's so you will need to tweak the css to match your site. Make sure you test on a copy of your site first as Page Tree Migrator is still not quite considered production ready and this blog install is a proof of concept at the moment, but still fun to play with

Thank you Ryan! I'm importing hundreds of user profiles and the biography information is a nightmare. This should clean it up nicely.

A blog can be a standalone site, or it can be one part of a website. They can easily live together in one ProcessWire install. That isn't really how the blog profile is currently set up. It's meant to be a standalone blog and not a "section" of a site.

Loading content from 50 other pages should never take over 3 secs. Can you share the code you cached to see the original performance issue.

Hi madhu1 and welcome to PW. I noticed you just posted this in another board. You'll find we're a pretty responsive bunch here, so no need to post the same thing multiple times. I am having trouble understanding exactly what your code is trying to accomplish, especially the $editRoles[] = $id section - What is $id being defined as? I also have no idea what $template_ is. Are you defining this somewhere else too? Here is an idea of how to add a new role: $newrole = new Role(); $newrole->name= "school1"; $newrole->save(); I think you have managed to do this already, but it's not in your code. This post from Soma explains how to add a new role to the list of editRoles on a template: https://processwire.com/talk/topic/2374-batch-allow-template-edit-access-to-new-role/?p=22366 Maybe you are already attempting to do this though with the $editRoles[] = $id Please post all your code - it will make it easier to figure out where things are going wrong.

Exact same reaction as you ankh2054 when I stumbled across PW (thanks to Marty Walker whose site I found and saw PW mentioned). I have not regretted or looked elsewhere since and I have actively re-built some sites from other CMSs to PW JUST for my own benefit. Welcome and enjoy!

Welcome to processwire. about polling: https://processwire.com/talk/topic/4042-poll-suggestions-for-voting/ modx => PW http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/ http://processwire.com/talk/topic/3111-a-modx-refugee-questions-on-features-of-processwire/ http://processwire.com/talk/topic/2850-processwire-for-designers/page-2#entry30349 General Info https://processwire.com/talk/topic/4173-grouped-forum-posts-links-articles-tutorials-code-snippets/

Hi ankh2054 and welcome to the forums! We also switched from MODX to PW little over year ago and haven't look back since. 1. Yes, dealing with users and permissions is really straight forward with PW - here's a good thread to begin with: https://processwire.com/talk/topic/107-custom-login/ 2. Simple as american pie: https://processwire.com/talk/topic/352-creating-pages-via-api/ 3. Everything's possible, here's some discussion: https://processwire.com/talk/topic/218-simple-poll/ There's lot of goof stuff in the forums and Google is your best friend!

Okay, got to go for a name drop here. I was working on the final soundtrack for the video release of Cameron MacKintosh's live show, "Hey, Mr Producer" (Brilliant show, by the way) It had been a difficult job - David, who had been mixing the music tracks, had had to get a few of the stars back in to redub their bits .... in tune! We were getting close to deadline and because of the remixes, I had only just received the last tracks and was resyncing them to the picture and rebuilding the audience sound track. Cameron's PA phoned. "Cameron says for you to do an all nighter to get it finished." I replied, "I can't do that as I have another session in the morning - I need to have had some sleep." PA: "You realise who Cameron is and how rich he is?" "I still can't - doing sound on no sleep is unfair to the client." "So, who is the other client that is so much more important than Cameron MacKintosh? Can we pay them off?" "We are recording an interview with the chairman of Microsoft." There was a long silence on the other end of the phone. So I added: "Would you like their phone number or shall we reconvene tomorrow afternoon?" Even being rich and famous is relative.

I always start out with a prototype which usually includes 4-6 example pages in plain old HTML, hopefully spanning all the layouts needed in a project. After that, I prefer to work on the actual server which the site will be hosted on, maybe on a subdomain or different folder if it's a relaunch. The reason for this is that in my humble experience, development setups almost never match the setup of the client's server/webspace. There's always some kind of small difference, and I really don't want to waste time on replicating that in a local dev environment. The prototype is usually based on a small starter project (I wouldn't call it a framework) I have built over the past couple of months. This includes a Grunt build script (which I love) including a lot of useful helpers like Sass, Bower, various tools to optmize images, Modernizr, jQuery etc. This also takes care of combining and minifying CSS and JS files, and it can even work with the PW templates I create after finishing the prototype. As for the actual deployment, I haven't included that in the build script. There are Grunt plugins for that, but I'm not entirely sure that would be very secure. So I still use plain old (S)FTP and ssh (if available on the client's server, which unfortunately still is rarely the case) to deploy the actual templates to the (development) site.

Indeed - it's a separate DB table like ryan says - if you take a look at the MapMarker module and a few others where they create their own tables you'll see that instead of just being a collection of different fields in their own tables like normal PW fields created in the admin these are like going back to a "normal" table with multiple fields. Very useful for some situations where you don't need to re-use fields elsewhere and have a pretty bespoke dataset that needs to scale to potentially millions of rows. This would also be good for things like invoicing systems, shopping carts etc where you want to store fields like item name, price, tax, total etc where you just wouldn't really need them as separate fields in the admin - they only make sense in the context of a single module. Which unfortunately means I need to change something I've done in an as-yet-unpublished module at some point to make it scale better

ProCache doesn't yet support multi-domain/multi-site, but this is definitely on the roadmap.

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.