ryan

I'll check with Pete on that one, as I'm not sure we have permission to send mass mailings to forum members. But we do have a good size email list of people that have requested email updates from us, so I could send to that. We still need to promote the contest on our Facebook group as well. I think it might be a matter of timing. As some others have mentioned, these contests tend to get most of their votes at the end, and that might be when we need to make these requests from the community. On one hand I'm a little afraid about us investing too many resources or asking much of people for this, as I recognize this type of voting system can be controlled by motivated individuals with a farm of proxy servers or by using existing web traffic for blind submissions (opensourcecms.com is a good example of what happens). But I also don't yet see any evidence of that going on here, and with the community already rallying behind this one, I am going to do everything I can to support it too. I am hopeful that we can win this one and get PW (hopefully 2.4!) into Bitnami.

MODX is the only big CMS project that has taken the time out to participate in our community here (Mark, Shaun, now Jay, and maybe others), and all have been positive forces here. A year or two ago, Shaun, one of the MODX core developers (at least at the time), took out the time to chat with me on the phone, do some code review and provide some valuable open source tips and suggestions. No other big CMS projects have been as supportive or taken an interest in ProcessWire like MODX has. They have always been friendly to ProcessWire and I've always viewed the MODX project as like a big brother to our project. These connections are why I see any mention on Twitter in a friendly manner. Though I genuinely appreciate those who responded to the tweet and were looking out for us either way. Had it been from some other CMS project where we didn't already have these connections, it might be different. But this all reinforces to me what a great community we have here.

Jay–I wrote my message before I saw you were here (I need to refresh my browser more often). Thanks for dropping by here. No offense was taken here at all.

I didn't take any offense from the MODX tweet. I saw it as a bit of a compliment to be recognized and mentioned by them, even if that wasn't the purpose of the tweet. It's nice to be on the radar at least. I've always seen MODX as one of the big guys. When you are a relatively small project, this kind of thing is good press. They've got a lot of followers and some people that didn't know about ProcessWire may now know about it. They know that. So long as they aren't saying bad things about us, then I'd see it as a friendly mention. But then the context and scale settled in. As nice as it is to have any mention, a single tweet from them could essentially kill us in any kind of competition like this (they've got 4k+ followers). That realization got me a little down yesterday as I realized all the hard work of saml and others to get out the vote could be wiped away with a single tweet from them. Hundreds or thousands of people voting for one thing to vote against another, many perhaps not even knowing what either is. That was my fear, luckily that hasn't played out. But I'd like to thank Jeroen, Mary and others that were looking out for the project here. I honestly don't think MODX had any bad intensions (and ElasticSearch deserves recognition), but it is really awesome just to know that people are looking out for the project like this.

Antti, were you able to find a way around the circular page reference limitation in PW? I've still got on my list to find a solution for this, so was curious if you'd found another route to make it work?

Thanks for the feedback guys! I agree on the serif typeface (replacing the Georgia with another serif face), but it's not my call. I'll suggest it though. I already communicated concern about using a geometric face for body copy (Avenir) but it doesn't seem to be a major issue in the end. I'll check with the client to see what I can share on the workflow side. But essentially, this site involves 1 PW installation for managing the inventory, and another PW installation for presenting it, and they use web services to chat back and forth all day.

Whether cached at view or save, t's exactly the same amount of work either way. Though caching at save potentially creates more work. Whether we're talking about template cache or ProCache, there are a few reasons why it's better to do it upon first view, rather than upon save. Pages are only cached for guest users. If we performed an automatic cache after a page save, it would be within the context of the user editing the page. This is not a context we want to cache. You want the page to be cached within the context of a real page view, not from something automatic or behind the scenes. This ensures that any other modules that are part of the render process also get to participate. You may save a page multiple times in a short period of time (don't we all?). If it gets cached on every save, you are potentially using a lot more resources than if it was just cached the first time it was viewed from a guest user. If we regenerated on save rather than view, that would be a whole lot of extra saves that have to be performed in the system (a save uses a lot more resources than a view). Keep in mind cache files automatically expire after some period of time (defined by you). You can't rely purely on a save() for knowing when data is stale or not, as your site may be pulling data from multiple pages or other resources.

It's true that ProcessPageSearch may change down the road, though no specific plans on that at present. But if you are worried about that, rather than extending it (in the PHP class sense) you could just copy ProcessPageSearch to another module, and modify it to make your own. The PW API behavior doesn't change, so when you make something where that is the dependency (as opposed to the implementation of class that's already an endpoint) then it's a safer bet.

This might be too complex of a scenario for me to reproduce very easily here. I wonder if I could get a copy of the database, or at least an export of the field_acara_code table? Also wanted to check if you've tried to run a DB table repair on the field_acara_code table? If this issue isn't due to some stray character or encoding issue in the table data, then it sounds like potentially a broken index, or some MySQL index behavior I'm not aware of. It's interesting to me that '%=' worked while '=' didn't, because '%=' bypasses the index, doing a full table scan, whereas '=' uses the index. It might also be good to know what version of MySQL?

While I can't duplicate the small square, I do see that the dropdowns aren't showing for a user with the permissions you mentioned. I've fixed it and it'll appear in the next update. Thanks! I honestly don't agree, and really don't like sites/apps opening new windows/tabs for me (that's what option+click is for). But you aren't the first person to mention it, so I'll try to accommodate both preferences somehow or another.

You could replace PW's link dialog with TinyMCE's native link dialog, as I believe it provides the option of more attributes. I think this can be done by replacing references to "pwlink" with "link" in the TinyMCE settings, though have not tried it recently.

Uncheck the box to the left of latitude, then delete the latitude and longitude (make them blank). Save. Following that it should return to the default/unset location specified in the field settings.

Adrian's code shows you the date of the last updated page in the site (which may or may not be the current page being viewed). If you instead want to show the date that the current page being viewed by the user was last updated, you'd do this instead: echo date("j. F Y", $page->modified);

It wouldn't be safe to exclude pages without template files from most find()s as that would be making the assumption that all find()s are for presenting navigation or search results to a user. PW makes no assumptions about what you are using the data for, so couldn't safely exclude pages based on that factor. If we were to implement something for this in the core in the future, we'd probably do it with a new selector option like "template_file_exists=1" or something along those lines. But if you've got pages without template files showing up in your search results, it might also be good to look at whether your search might need to be made more specific, or if your pages with no template file should be excluded with an access controlled parent. But I'll keep marinating on this template_file_exists option for selectors, as it may be a worthwhile addition.

Great tutorial Soma! Thanks for making it. One thing I wanted to mention is that this syntax: wire("fuel")->set("helper", $this); has been replaced by this syntax: wire('helper', $this); // or this: $this->wire('helper', $this); But of course your tutorial is correct in using 'fuel' since it would be compatible with past versions of ProcessWire too. Just wanted to mention it since I think the API is simpler if all getting or setting of API variables is just done through the wire() or $this->wire() functions. But the old syntax will always continue to work as 'fuel' is itself an API variable, but one that I figured makes more sense as an internal-only API variable.

Sounds good, I'll add it.

Since this module doesn't have a toggle for that particular need, you might take one of these routes: copy the module files into /site/modules/MarkupPagerNavCustom/, modify it directly and install. str_replace or preg_replace in the output it gives you, to modify it according to what you need (i.e. adding next/prev links) you could always prepend/append the next/prev links with jQuery pretty easily.

Soma is right, this was already added a few months ago. Double clicking the trash icon on any file/image now marks all for deletion. Double click again and it unmarks them.

Do you have a green message that literally says "Saved page"? What is the URL in your address bar after saving? What version of ProcessWire?

For that I'd suggest using a multiple selection field rather than a single selection field. The simplest examples would be a <select multiple> or checkboxes. You can tell PHP to submit the result as an array by appending "[]" to the field name, i.e. <select multiple name='something[]'> <option value='1'>One</option> <option value='2'>Two</option> <option value='3'>Three</option> </select> From the PHP side, you can retrieve it like this: if(!empty($input->get->something)) { foreach($input->get->something as $value) { $value = (int) $value; // $value contains either: 1, 2, or 3 } }

I will upgrade to the latest MAMP here soon and see if I can reproduce it. You've got me wondering if there is some incompatibility with that version of MySQL (5.6.14). Though if it were widespread, you'd think we would have heard about it more than once.. and maybe we will. I'll keep an eye out and do some testing here too.

I don't know a lot about memcached either, but I know of others using it successfully with PW (after that change you made) and have not heard of any other issues. If you find it to be an issue, you could always switch to PW's native database-driven sessions module (included in the core).

I've been working on this one for a few months and just launched it this morning: http://villasofdistinction.com I also did the previous iteration of this site, 5 or so years ago (which was running ProcessWire 1.0). The new site is powered by ProcessWire 2.4 (2.3 dev). The site is responsive and designed for a good experience on both desktop and mobile. While I did all the development, the site's design/look and feel was created by the client (they have their own internal design agency). Most of the work in this project was actually not anything you can see on the front end. Instead, most of the work went towards back-end management, workflow and web services. The client has a large number of editors and agents that needed various capabilities, workflows, feeds and such. So there's a lot more going on here in terms of a management platform than in the previous iteration... and that's mostly what kept me busy for so those few months. Modules used here: Foundation 4 Profile All In One Minify (AIOM) FieldtypeMapMarker (with MarkupGoogleMap) Pro Cache Form Builder Hanna Code Redirects Selector test Changelog Version Control for Text Fields Batcher Admin Template Columns CKEditor Select Multiple Transfer CollagePlus And a few custom modules

I don't see the recommendation there anymore either. It used to be there anyways. I think the primary concern is that "domain.com" is usually associated with the homepage of a site. When people link to you as an entity (as opposed to a specific page) they generally link to "domain.com". But if your root URL (represented by "domain.com") performs a redirect, you sacrifice the pagerank potential / link juice. While pagerank may be allowed to flow through redirects, it's far from a certainty. I would suggest there could be some real SEO risk in having your homepage be a redirect. Maybe not a penalty risk, but a long term reduction of pagerank potential gained by external links.

I thought that "/" was the one URL you could count on every site having. At least, having a root URL that performs a redirect is not considered a good practice from an SEO standpoint (google webmaster guidelines say not to do this). That's why PW makes sure that your default language covers that one URL rather than "/default-language/". This would be filed under "it's a feature not a bug". But I'm not opposed to making it configurable if it's useful to you or anyone else. See the latest commit to dev, which now lets you configure that behavior in the Language Support Page Names module configuration screen.