ryan

Thanks for the introduction Casey and welcome to the forums. Glad you are enjoying ProcessWire and we look forward to seeing more of you around here.

I just submitted a pull request to Antti that makes it work with 2.3 (2.2.10). Also updated it so that it deletes the thumbnails when you delete the parent image. My updates are here: https://github.com/ryancramerdesign/Thumbnails

Looking in the ProcessCropImage code, I think I see the problem. It is constructing image URLs manually rather than asking the page for the images path. This was perfectly fine up until we introduced the secured images option (on the dev branch) which uses a different path for secured images. But this wil not work with 2.3. I'll attempt to submit a pull request for this module.

Marc, let me know what you find. I just need some way to reproduce it, but once I can do that I can fix it quickly. If I can't reproduce it here, and you don't mind giving me access to troubleshoot your install, I'll be glad to do that.

Glad you found it. Eventually I think we'll have to add a 'default sort' option for repeaters, so that they automatically sort by some field present in the repeater.

Sure! You just need to know the name of the field (usually the same as the 'name' attribute) and then you can grab it directly from the Field object. Writing in browser here, but think it should work. It assumes you are somewhere in an Inputfield. $field = wire('fields')->get($this->attr('name')); if($field->textformatters) foreach($field->textformatters as $className) { echo "Name: $className"; } Many Inputfield functions already receive a copy of the $field, in which case you can just use that ($field->textformatters) rather than figuring it out yourself. Only text fields will have a 'textformatters' array, and you'd want to double check that it's actually present before using it.

70% is a seriously large quantity of mobile traffic. I agree, if that's what your analytics tell you then mobile first all the way. Most of the sites I work with have mobile traffic at a similar level to IE6 traffic. Which is to say, not much. But the trends are always increasing (unlike IE6).

The simplest way would be just to post-filter them after your search. Meaning, whatever code you have outputting the found pages would just check the status and skip over any that had unpublished parents. foreach($items as $item) { $skip = false; foreach($item->parents as $parent) if($parent->is(Page::statusUnpublished)) $skip = true; if($skip) continue; // otherwise item is good to output echo "<li>$item->title</li>"; } But if you are also working with pagination, then you kind of need to have these things filtered ahead of time. In that case, I think Soma's method would be good. The hope is that you don't have too many unpublished pages to be found, that could slow the query. One way to further optimize that would be to find only unpublished pages that have children. $up_pages = $pages->find("status=unpublished, numChildren>0");

Once you've got your form, I think it'll be fairly easy to develop this. But your date fields are the only thing that's going to need a little extra work. Since you are asking for just month and year (no day) you'll want to qualify that to the beginning of the first month and the end of the second month. Finding the beginning of the first month is easy since all months start at day 1. There are various ways to find the end of the second month, but there's one way in my example below. Here's how I might perform the query from the API side (written in the browser so may contain typos): // where we will store our $pages->find selector $selector = array(); // add the search query if present if($input->get->search) { $search = $sanitizer->selectorValue($input->get->search); $selector[] = "title|body~=$search"; } if($input->get->yearFrom && $input->get->monthFrom) { // construct date like 2012-12-02 and convert to timestamp $dateFrom = strtotime("{$input->get->yearFrom}-{$input->get->monthFrom}-01 00:00:00"); if($dateFrom) $selector[] = "date>=$dateFrom"; } if($input->get->yearTo && $input->get->monthTo) { // do the same for month-to, but find the beginning $dateTo = strtotime("{$input->get->yearTo}-{$input->get->monthTo}-01 00:00:00"); // now find the end of dateTo month by adding 1 month and subtracting 1 second if($dateTo) $dateTo = strtotime("+1 MONTH", $dateTo) - 1; if($dateTo) $selector[] = "date<=$dateTo"; } // determine and validate the max records to show $limit = (int) $input->get->limit; if($limit > 50 || $limit < 1) $limit = 10; $selector[] = "limit=$limit"; // specify the template we are limiting the search to $selector[] = "template=article"; if(count($selector)) { // perform the search $selectorString = implode(', ', $selector); $articles = $pages->find($selectorString); echo "<h2>Found " . $articles->getTotal() . " articles matching your query.</h2>"; echo $articles->render(); // or however you want to output them } else { echo "<p>No search specified.</p>"; }

Thomas, just to confirm, you are using language alternate fields, where you have literally created a field called title_english in your Setup > Fields? The syntax you mentioned would only work if you were using language alternate fields, as opposed to a multi-language text or title field. I am guessing that there might not be a literal title_english field in your fields list and that you are using the language-alternate syntax on multi-language title field? If that's the case, see here for the correct syntax. If that's not the case, let me know and we can try something else.

Did some investigating here. If I'm right, it's not a bug per se, but an undesirable behavior. Try changing your code to this: require('./index.php'); // this is the ProcessWire index file for bootstrap $wire->pages->setOutputFormatting(false); echo $wire->pages->get('/videos/')->render(); echo "\n\n\n\n\n==============================\n\n\n\n\n\n"; echo $wire->pages->get('/people/')->render(); That fixed it in my case. The reason was that calling setOutputFormatting() on a page only sets the outputFormatting for that page. If your page's template happens to be loading other pages, they will be loaded with outputFormatting off. By setting the default output formatting state before you render(), you correct that issue. This is only the case when you are rendering from a bootstrapped script, because that default outputFormatting state is pre-set to false. In any other situation, you wouldn't have to do this. I think I can make this a lot simpler. I'm just going to update $page->render(); to take care of setting the right outputFormatting state for itself and the system before it attempts to render a page. If that change didn't fix your case, then go in and check the template(s) for the pages that are being rendered. Do you have any include() statements that should be changed to include_once()? This would be the case if you had any function definitions in include files. If you have any function definitions in your main template file, then you'd want to do this instead: if(!function_exists("my_function")): function my_function() { // do something } endif; Since your two page render() calls are happening in the same PHP runtime instance, you just have to watch out for any duplicate definitions or includes. Let me know if any of this solves it there?

Sounds like a bug guys, I'll look into this.

Wasn't Foundation v2 also responsive? I've not checked out 320andup yet, but am going to take a closer look today. And this gridpak generator looks pretty awesome. great links. I think mobile-first sounds like a great slogan but not a great strategy. It's easy to identify sites that have taken that strategy because the non-mobile version of the site often seems like… an enlarged mobile site. I've not done a lot of mobile stuff yet, but with what I've done, I prefer to focus on both at the same time. Otherwise it seems like sacrifices are being made to one or the other. The full-size design is still what I ultimately have to sell to the clients. There's fewer variables on the mobile side in terms of design and that part [so far] seems a lot simpler to account for (and easier to get approved too). So I guess I think the picture should be bigger than just mobile first. Sorry, maybe I'm a bit off topic, but just remembering an overabundance of mobile first hype at an AEA event last year.

That's a pretty nice code editor there, thanks for the link. Will have to take a closer look. For the most part though, ProcessWire assumes you have your own tools for editing things like your templates and CSS files, and is trying to stay out of your way in that regard. There are also some security issues with enabling direct editing of PHP files on the server. Though I still think this is a good idea for a non-core module, to provide editing capability of template files for those that want it.

It should be that second argument to RCDMap.addMarker, where you could specify whatever URL (or anchor) you want: RCDMap.addMarker('some title', '/some/url/', lat, lng); RCDMap.addMarker('some title', '#some_anchor', lat, lng);

Now that you mention it, I think that I did have a similar experience a while back. My first exposure to coding was also in BASIC, I think back on old Apple ][e computers. Actually it seemed like we used some language called LOGO back in 2nd grade, where the whole purpose is to make a turtle move around the screen, but can't remember exactly. Even BASIC has come a long way since then (with VB). To me the "GOTO 115" type statements also seem reminiscent of Assembler or COBOL.

Making a module derived from the InputfieldTextarea is probably the best bet. Once you've got it in place, you should see any of your textarea fields let you select it as an option (in the same place where it lets you select between Textarea and TinyMCE). What might be ideal is this: http://markitup.jaysalvat.com/examples/textile/

Ironically, odds are it's due to a broken regular expression in IPB's code.

I was able to reproduce this in a repeater and tracked down a problem (and think I fixed it). Thanks for finding it. This problem would also affect any pages with images that didn't have a template file. Do you want to try the latest dev branch. Or if you are already up to date minus the latest commit, you can replace just /wire/modules/Process/ProcessPageView.module https://github.com/ryancramerdesign/ProcessWire/commit/e000252a264f35deccb081e995a40df451f82952 https://raw.github.com/ryancramerdesign/ProcessWire/e000252a264f35deccb081e995a40df451f82952/wire/modules/Process/ProcessPageView.module

I attempted to duplicate the issue here a few times, but the only way I could duplicate it was (as Arjen mentioned) by enabling the cache for the template that the comments field appeared on. Though I don't think this is the issue in your case, because you still received an email, which would not happen of cache were the problem. Slightly off-topic: For those that want to use comments fields on cached pages, you can still do so. Edit your template that the comments field appears on (Setup > Templates > [some template]). Then click the "cache" tab. For "Comment disabling GET vars" enter "comment_success". For "Comment disabling POST vars" enter "text". Save. Now your cached pages will still work with the comments field. I'll have to find a way for this to happen automatically behind the scenes... but until then, this is the best route to using comments fields on cached pages. Back on-topic: Marc--do you see any related errors in your /site/assets/logs/errors.txt? Can you try going to your comments field and just hit "save"? (maybe there's some setting that needs to be refreshed). If that doesn't do it, try enabling the "Redirect after comment post" checkbox, which is something that I recommend for everyone now. Let me know if you see any change in behavior?

Marc, when you go to your comments settings screen (Setup > Fields > comments > details), what boxes are checked? Feel free to post a screenshot if it's easier.

Atomic Grouping http://www.regular-expressions.info/atomic.html Negative Lookbehind (and family) http://www.regular-expressions.info

Sounds good guys, I'm going to go with a slight modification to Joss's suggestion: Will also append a blowfish hash of that Oxford word, combined with a random salt (to avoid the obvious URL dictionary attacks). In all seriousness, I do think it's a fine practice to have a unique URL for your admin. But the admin is password protected, so it's not really necessary to change your admin URL unless you or your clients are going to be practicing bad password habits. Still, every little bit of security is always good, especially ones that are so easy to add.

That's correct. That language is going to need to be set before the [cached] page renders, since you are selecting a language based on subdomain. Best way to accomplish this might be with a module. I think this below would do it. You'd have to update the last function there to reflect your actual domains an language names. /site/modules/LanguageSubdomain.module class LanguageSubdomain extends WireData { public static function getModuleInfo() { return array('autoload' => true); } public function init() { $this->addHookBefore('Page::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { $host = $this->config->httpHost; if($this->config->httpHost == 'es.domain.com') $lang = 'es'; else if($this->config->httpHost == 'fr.domain.com') $lang = 'fr'; else $lang = 'en'; $this->user->language = $this->languages->get($lang); } }

This is correct, the pattern is validated at server side too, so the HTML5 attribute is just a "nice to have". Though the fact that it's there provided good motivation for adding pattern support to the text field. Previously I thought regular expressions were too cryptic and code-oriented to expect from most users. But hey, if HTML5 is suggesting it and most browsers are implementing it, then we absolutely should. Personally I love regular expressions, but don't know many web developers that know how to use them. But it looks like that's changing, and sites like that html5pattern.com are great resources too.