ryan

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?).

Subfields like "category.id" aren't currently supported by the PageArray in-memory find/filtering functions. Though I think I can add this easily enough. However, "category" should resolve to the id property anyway, so you probably don't need it.

The problem is that page $f doesn't know the repeater item changed. Those repeater items are individual pages themselves. You can solve this by saving the repeater item ($g) rather than the owning page ($f): 1. Replace your $f->save(); with $g->save(); 2. Also replace your $f->of(false); with $g->of(false); 3. Lastly, I also suggest replacing your first line with this: $found = $pages->find("parent=/invitations/$user->name, guests.guest_name=" . $sanitizer->selectorValue($form['oldname'])); Adding that selectorValue() sanitizer in there will prevent problems from occurring if the guest_name happens to contain characters like commas or quotes.

Thanks Martijn, this has just now been fixed in the latest commit.

We still have the Wiki ready to go (http://wiki.processwire.com/). It's just looking for someone to show it some love. I've closed off public post access because of all the spammers, but happy to add any new accounts for anyone that wants to work on this -- let me know?

Do you have template caching turned on? That would negate the use of any cookies set from PHP. When I need cookies and caching, I use Javascript-based cookies instead, since they are client-side and still happen regardless of server side caching.

I'm not sure I understand the 1 week vs 2 week thing. It really shouldn't matter whether the range is days, weeks, months, years, etc. There are no 1-week dependencies that I can see in any of the code in this thread so far. You should be able to provide any date range in your selector. $fromvalue ="2013-07-13"; $tovalue = "2013-07-27"; or $fromvalue = strtotime("2013-07-13"); $tovalue = strtotime("+2 weeks", $fromvalue); Also wanted to add, I have a better solution for this now (on the latest commit to the dev branch). You can now do this, where $item is a repeater item: $property = $item->getForPage();

They didn't used to entity encode those feeds, but looks like now they are. I think I've got this fixed. Please give it a try and let me know how it works for you: https://github.com/ryancramerdesign/MarkupTwitterFeed

As of the latest commit to the dev branch, you no longer have to do this. You can now replace the above bit of code with this: $forPage = $product->getForPage(); That returns the page that the repeater item is for. I also added this, should anyone ever need it: $forField = $product->getForField();