ryan

No problem. Glad you got it sorted out.

That was the hope with the JSON API we put into it. Two modules that use it are the InputfieldPageListAutocomplete and ServicePages modules. Though of those two, only InputfieldPageAutocomplete uses it in the way originally intended, as ServicePages essentially translates ProcessPageSearch for front-end use.

I've pushed some updates to the CKEditor Inputfield fixing some bugs and updating to the latest version of CKEditor (4.3.2). I recommend upgrading if you are already using a past version. I've also added a couple of detailed tutorials to the README file including: How to make your own custom styles menu How to customize the appearance of the editor While you are upgrading, be sure to grab the latest version of the HTML Purifier module as well.

Mike– Looks like this module needs the dev branch (2.4). But I think we can get by with just updating your WireHttp.php class file. I went ahead and did that. Does it work now?

Regarding circular references with pages, ProcessWire was never intended to allow them. The code was already written to prevent them from occurring, per a GitHub issue that came up a few months ago. When I found out Antti's module needed them, I held off on committing those updates to make sure we could find a solution that worked with his module. So what I'm trying to determine is just if I can now go ahead and commit those updates that disallow circular page references, or if someone has a real need for them that can't be solved any other way. I have never understood the need for a circular page reference, and am not sure if they are even a good idea in any case. But if you guys have a need for circular page references, please let me know before I put the code back in place to keep them from occurring.

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it.

Give this module (attached) a try. To install, upload into /site/modules/ServicePinger/ServicePinger.module. Go to your Modules menu and click "check for new modules". Click install for ServicePinger. The module configuration screen has a textarea input where you can put in all the service URLs you want to ping. I recommend pinging one of the services that pings others, like pingomatic or weblogs.com, rather than trying to make this module do all of them. Actually, those are the only two services I've tested this with yet. When you install, it creates a new field called "pinger". Go and edit any templates you want to use it on and add the field "pinger". In your case, I'm thinking you'll just add it to the "post" template. Now edit a page with that template and see the "pinger" field you added. If you want it to ping those services, check the pinger box and save. You might want to test this out on one of your smaller sites first before migrating to your main site, as I put this together quickly and haven't yet tested it a lot. But I'm planning to add a README file and maybe a couple other details and then add it to the modules directory soon. ServicePinger.module

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.