ryan

You might try moving it out of the tab, just to see, though I doubt that's it. If you are using an admin theme other than the default, you might also try switching back to the default, just in case. Lastly, double check that there aren't any errors in your JS console. Since you are no longer stuck, as it all starts working after you save, and I've not been able to reproduce it here, lets wait and see if someone else can. That might give more clues how to reproduce it.

This isn't specific to ProcessWire, but HTML checkbox fields in general. When it comes to seeing if a checkbox is checked, the presence of the field in $_POST means that it was checked. If a checkbox is unchecked, it doesn't show up in the $_POST. Whatever value you assign to a checkbox field doesn't really matter, as that isn't the indicator of whether it was checked or not. Using some non-zero value in your checkbox does make sense though because a statement like this would indicate whether the checkbox was checked or not: if($input->post->my_checkbox) { // checkbox was checked } else { // checkbox was not checked }

That's great Joss! Let me know if I can set you up with a Wiki account. We need all the help we can get, even if some things are just stubs, etc. I like where you are going with your cms notes pages.

I let Google translate the article for me, and German is one of the languages that it does not do so well with in translating to English. However, I could understand enough to see that this is one of the best articles on ProcessWire I've seen. Michael Van Laar really has a gift with communication like this. He managed to cover a lot of territory there in a very accessible way, and it really draws in the reader. Thanks for writing this Michael!

Correct me if I'm wrong, but what Google doesn't like are 302s. 301s aren't themselves bad, but can be less helpful to pagerank when stacked. I don't agree with the broad statements of the linked article. A properly used 301 is in fact a great thing for SEO. But also something to be careful with if you want to maximize the value of it. My experience has been that proper use of 301s is one thing that separates the good SEOs from the unknowing ones. They enable you to relocate URLs in a manner Google will transfer pagerank through. They also enable you to ensure people are always arriving at a consistent URL, thereby making it extremely likely that people will link to you in a consistent manner. Lack of properly used 301s increases the odds of diluted pagerank and duplicate content penalties. When someone loads domain.com in their browser and it 301s to just www.domain.com (or the opposite), thats a good thing. When someone types www.domain.com/about-us in their browser and it 301s to www.domain.com/about-us/, that's a good thing. When you have an old About Us link at domain.com/page.php?id=123 that 301s to www.domain.com/about-us/, that's a good thing. This is all good for SEO and good for the users. If this is consistent and stays that way, the external links that you build up over time will also be consistent. The pagerank that you accumulate over time will be maximized, not diluted. And what rare external links that point to content at an inconsistent URL will be identified as such by Google while still transferring pagerank. Where benefit starts getting lost is when you use 301s in a manner that sends it through several paths. My understanding is that Google does dilute pagerank somewhat the more 301s it has to go through in order to meet a request. Example: link points to domain.com/page.php?id=123, which redirects to www.domain.com/page.php?id=123 which redirects to www.domain.com/about-us which then redirects to www.domain.com/about-us/. The user still gets to the right place (good) but the pagerank value of the link that was pointing to domain.com/page.php?id=123 has been diluted to some extent (though don't know how much). Meaning, lost potential, but certainly better than a 404. A smart SEO keeps tabs on this stuff and corrects the first 301 to redirect to the proper URL rather than having to go through further unnecessary 301s. Pagerank potential gets maximized rather than diluted. The use of a slash vs. non-slash shouldn't be a factor for SEO, so long as it's consistent and 301s to the proper version (excluding root level of course). When someone is advising you to always use trailing slashes, I think this is what they are really saying: 1. Always be consistent in how you link to your own pages (regardless of slash standard). Preventing an unnecessary 301 here reduces the chances of some other 301 getting stacked on top of it. It maximizes the value of the link. 2. Standardizing on a trailing slash reduces the chances of having to implement more 301s later (further reducing the chances of a 301 stack). From an SEO standpoint a trailing slash will scale better because there is no functional reason to ever have to change. Whereas, without a trailing slash there is potential for having to change to one in order to accommodate future growth. I keep up with SEO stuff, but it's not my full time job either, so someone correct me if any of this has changed.

Try changing $this->setFuel to Wire::setFuel('mailchimp', $this);

Andrew I think you did the right thing by leaning about and implementing this the way you did. It's the sort of thing that really belongs with the site, server and developer rather than the CMS. ProcessWire doesn't make assumptions about where and how you are using it (or if you are even using it for http), so logically we probably shouldn't make assumptions about expires headers apache should send for static files. Though I can see potentially adding some options for setting this stuff with PW-managed output.

Two possibilities I can think of: 1. Your PHP installation doesn't have allow_url_fopen enabled. You can check this by viewing your phpinfo. My guess is this might be the case? 2. The calendar URL isn't public and requires authentication. Meaning you've got to be logged into your gmail or something in order to view it. This one would be easy to test, as you could log-out of any google services and try it (or just post the URL here or by PM to me).

At present I don't think there's a better way since those images are hard-coded in TinyMCE's output and the filename essentially changes when you upload a new one. But one way we might accommodate it is to provide a new setting with the images field that lets you enforce a specific filename… perhaps [field-name]-n[index].[ext]. That way if you replaced an image, the new filename would be the same as the old (so long as you didn't go from JPG to PNG or something). No doubt might cause some unexpected browser cache issues, but most solutions have compromises of some sort or another. This could be a worthwhile option to provide.

I recently switched a client from Markdown to Textile and they are a lot happier with Textile. There were a few problems with Markdown that nobody could ever get used to: 1. Two-spaces-at-end-of-line thing that you have to do with Markdown when you want to go to the next line. Forget the two spaces and your two lines become 1 line in the rendered output. This makes sense in the context of HTML, but makes little sense to non developers. The client of course knew how to do it, but because spaces are invisible it was a recurring problem in this case due to the nature of the content. This is often one that's difficult to explain and difficult to remember, especially due to the lack of visual cues. 2. Numbered lists (like this) where Markdown comes up with its own numbers regardless of what number you specify. It meant them having to make numbered lists like 1), 2), etc. in order to be in control, which was not their preference. 3. Bulleted lists not working unless preceded and followed by a blank line. This is a hard one for some people to remember for some reason. Though I've never found it to be an issue myself. I also think it's a little disappointing that there doesn't seem to be an equivalent of TextileRestricted for Markdown. Clearly they are out there (as GitHub uses one for their comments, maybe homebrewed), but I've not come across them. Antti you might also consider BBCode which has broad recognition as a result of being a standard in forums for a long time. This is an alternative to TextileRestricted which is safe to use with user input (and we have a PW module for it). I used it with the modules directory because I thought our users might be more familiar with it since we used it a lot in SMF. Though now thinking TextileRestricted (or providing a choice) may be a better solution going forward.

That stripping everything back and creating a specific test case is always a good way to solve problems. Usually kind of fun too. I'm not yet clear on why it wasn't working the first time around though?

What is the API code used? Just trying to get a test case I can reproduce. For the extra pages you have in the DB, I would locate them in your Repeaters structure (in the admin) and drag those not needed into the trash. This should provide an easy way to prune out stuff in large quantities without spending much time.

The image manipulation stuff gets into a math territory that my mind has always had trouble with. So much of what you see in the ImageSizer class is adapted from things learned in comments at php.net. I have no doubt that others here may be more adept at expanding the utility of the ImageSizer class, so if anyone is interested in working on it and adding a crop direction option to it, I'd welcome the help. Otherwise, I hope to have this figured out by PW 2.4. My thought is that the crop direction option would be specified with one of: NorthWest, North, NorthEast, West, Center, East, SouthWest, South, SouthEast, as a grid: NorthWest North NorthEast West Center East SouthWest South SouthEast This is similar to the -gravity option from ImageMagick, if anyone is familiar with that.

I just tried to reproduce this, but am not experiencing that particular issue here. Are there any other factors, like the page being unpublished or something?

This might be a more efficient way to go, by converting multiple $pages->get() calls into 1 $pages->find() call. $ids = array(); while($row = $result->fetch_array()) $ids[] = $row['video']; $bw = $pages->find("id=" . implode('|', $ids) . ", category=17|23|9");

It's possible to clone pages with repeater fields, but not [yet] repeater fields themselves. Meaning, if you need to create a new repeater field definition, then you've got to start from scratch rather than cloning another. But luckily, the need to clone a repeater field is fairly rare. I don't have a good answer here yet, short of deleting the original and changing the references to the new. I think what we need is some core API method of copying data from one page to another, something like $page->import($page2). I'll put more thinking into this. The best way to understand the way repeaters work under-the-hood is to look at the Repeaters structure under your admin page. Take a look at the page tree there. Repeaters don't consider the DB level, as they are completely built on top relation by page structure. They are using the PW API rather than database queries. Granted, you will see a field_* table for each of your repeater fields, but that is only used for lookups on certain find operations, and not part of the repeater in the way that field_* tables are for other fields. Essentially, you can ignore the field_* table used by your repeater field when it comes to understanding how they work. It all has to do with structure and little else. Repeater items are just pages under a parent. That parent that carries a reference to the page the repeater lives on in its 'name' field. It's a lot less complex than I think most would assume. At the core, repeaters are quite simple. What complexity there is comes more from accommodating specific situations, like ajax file uploads for instance.

Thanks everyone, we're really happy to get this award. Congratulations to everyone here, as it sounds like a key factor was all of you, and this is really something to be proud of: (quoted from http://www.cmscritic.com/critics-choice-for-best-free-cms-goes-to/) I've placed the banner on all the pages in the site, but this was just a quick solution. We'll figure out a more prominent "above the fold" placement for longer term.

Great site Diogo! Great design all around. For the videos page, does it grow infinitely (on scroll) or is pagination introduced at a certain limit? I saw it mentioned UT Austin in the footer--that's where my wife went to graduate school.

I think this makes sense. I'll look into adding this. I don't know all the technical details surrounding this, and only recently started caring about Retina screens, but maintaining multiple images to target different displays sounds like a short term strategy, not a long term one. At least, I'd have a hard time believing we'd be doing this 5 years from now. I would expect pixel density might keep going up over time. Even if it uses more bandwidth, it seems like the safest strategy for individual images would be to just double the resolution and scale it to 50%. Meaning, if you want to display an image at 300px wide, then make it 600px wide and specify 300px in the width attribute or style. But I'm writing in the context of TinyMCE embedded images and other one-off images. For something like a photo gallery where there are going to be huge differences in bandwidth, or other bandwidth-dependent situations, maybe these browser sniffers and multiple copies of photos make sense… make the people with Retina screens pay for the bandwidth rather than everyone else. Still, doubling the pixel density on images seems to offer some better future proofing and we'll probably all be using this level of density in our displays a few years from now. For the new processwire.com site, I noticed the ProcessWire logo looked crappy on my iPad and iPhone, so saved out a double-size copy, but kept the width/height dimensions the same on the <img> tag. Now it looks great on retina screens, without making any difference on other screens. I think this is the strategy Martijn was referring to for possible inclusion to PW's image placement.

I don't think that face, size or color are valid attributes with a <span> tag. It probably doesn't hurt anything to have them in your TinyMCE definition, but I think the only valid one you would need is "style". Is it really working with span[face|size|color], or do you have a span[style] in there too?

I do the same thing that apeisa mentioned. However, I also prefer to keep other things in the site structure where possible, even if I don't intend to use them for front-end views. I often setup template files for these things for my own use (or the client/admin's use), and it can be quite useful. I've found that the approach scales very nicely and enables things to grow over time without becoming more complex. When not practical within the site structure, that's when you use your /tools/ structure. It only becomes messy if you treat pages as buckets, and buckets are messy. If you treat it as structure and put thought into where something should go and why it should go there, what you end up is something extremely organized and purposeful. If something is a non-visual page, does that matter? You see it in an administrative interface, where administration is the purpose. Where I would not want to see the non-visual page is on the front-end. Another thing to consider is whether something should really be "non-visual". I prefer to implement template-files/views for nearly everything on my sites, even things I might consider non-visual in other platforms. The benefits become obvious once you start doing it. However, ProcessWire will happily maintain pages that have no output too. But experiment with implementing output for things you previously thought as non-visual and see where it takes you. It often opens up great new paths to information and is an excellent SEO tool for increasing cross references in your site. For example, consider these pages from the modules directory that started out as non-visual. I went back and implemented an "author" template that does nothing other than show the modules by that author. Yet it's quite useful. This may be an obvious example, but the same concept applies to all kinds of situations. This is only true if you code with a dependency on structure. The suggested route is to select by IDs, templates, relative references or some other field to depend on when you are dealing with potential structure changes. Selecting by path is just one way to pull from other pages, but far from the only way. We use it a lot in examples because it is the easiest to communicate with in the context of examples. But that doesn't mean it's always the right way. Ultimately what is right or what is best just depends on the situation. Using the "hidden" checkbox is a good way to immediately differentiate such pages. However, for something better and more automated, check out mindplay.dk's excellent Template Decorator module. I'm hoping he will add this to the modules directory soon! It is possible, but it's not something I would suggest. I think it's fine to create one-off structures for menus where you might want to vary from the page structure for specific situations like footer links, or even primary navigation in some cases (*see note). But if you build your entire strategy on that, you are adding a load of unnecessary complexity to a site, disconnecting navigation from structure, and ultimately creating a mess that could have been avoided with a little planning. *I think page reference fields, combined with PageListSelectMultiple input are often times a lot better for this stuff.

I agree that it might be good for us to show what you can do with ProcessWire rather than just admin screens. Once we have a nice site directory setup, I was thinking these screenshots could pull from that, and perhaps lead into it. But I don't want to stick screenshots from my own sites into there unless they are also in rotation with other people's sites. But I'll experiment here and see what we can do. In the short term, we do need to get some more screenshots in the rotation, regardless of what they are.

Nik has the best posts! Another thing I wanted to add is that it's also very easy just to use API code to do these types of imports. 90% of the time I use API code to script imports with shell scripts, versus using the import pages CSV module. Though part of that is that I use the API every day and there's not a lot of figuring out to do. But if you want to post a sample of the data you are importing, I'd be happy to respond with a sample of how you might import it from the API.

What version of ProcessWire? Also, what method did you use to delete the page? Are you sure that your deleted page isn't still in the trash? I just tried to duplicate here, but so far can't. When I delete a page that has a repeater on it, the items that accompany the repeater get deleted. The method I used was to delete the page from the page editor, then go and empty the trash. You can observe if the pages are still there by browsing the page tree to Admin > Repeaters > [repeater field name] > [page name]

Caching isn't on by default (Templates > edit template > cache). So if you aren't using cache, I'm not sure what the issue could be. You might try replacing $input->cookie->InfoBar with $_COOKIE['InfoBar'], just to see if there's any difference (just in case, since you are on the dev branch). Cookies are stored at the client side, so it's always worth considering that too (something interfering with cookies?).