ryan

Found it--it was a bug. Sorry for the inconvenience guys. This is one of those obscure bugs that takes the right set of circumstances to turn up, so these can be difficult to track down. Thanks for finding it. I've just committed the fix to the dev branch, and it should be merged into the stable branch likely tomorrow. Here's the commit message:

Pete, try adding an extra line to your install function: wire('modules')->get('MarkupCache'); That will just ensure that it's installed ahead of time and should resolve the problem in this particular case. However, I don't think there is a problem with your code, I think it's actually a bug with the MarkupCache module (or maybe Module installer) because the MarkupCache module is responsible for making sure it's files go into the right place, and clearly it's not doing that. I will locate and fix the issue. I was able to reproduce it here by uninstalling the MarkupCache module and then letting it be installed at the time it's used. That seems to be the only time the issue occurs.

Your display_options in the selector needs one of the following: The literal $page object for page 'not-shown-on-front-page' The full path to the page you are trying to match The ID of the page you are trying to match As a result, I'm thinking you'd want to do this (use the path rather than the name): $stores = $pages->get('/news/co-op-news')->children('limit=4, display_options!=/tools/display-options/not-shown-on-front-page'); If you aren't going to have a ton of display_options, you might also want to consider just using single checkbox fields for these, in which case you could just do this: not_shown_on_front_page=0

Welcome Raydale and thanks for using ProcessWire and joining the forums. I'm late to this conversation--just arrived back in town after being gone for a couple of days. I think Pete and Apeisa replied better than I could have, and just wanted to say we're glad to have you here and look forward to talking more.

Nico, this is something that is technically possible with the way the hook system is designed, but I've not implemented it yet. The idea behind it was that there would be a 'replace' hook, where you can have your own function completely replace the functionality of a core function, so that the core one is never called. I haven't implemented this because it's not so friendly in an environment where there may be multiple modules hooked to a given function. If one module completely takes over a core function, it alters program flow and the behavior that other modules may be expecting. So I've left it out because I think it's a bit too unpredictable, though may still add it in if there's interest. However, you can achieve the same effect by using an 'after' hook and completely replacing the $event->return value with your own. Not as efficient as replacing the execution too, but much more predictable.

Rob, I think that's a difficult question to answer without knowing what you are going to be using the images for? Because I think the approach would depend on the eventual intention and use for those images. I don't see any scalability problems with #1. But you are right that it won't be as simple to upload images as it is with a multi-image field. Though it would be fairly simple to build a module (or even a template) that takes all the images from one page and turns them each into their own page. For #3, here's an example of taking the image field and making a new one that has custom fields attached to it: You are right though that once you've got hundreds of images in there, that might be a little difficult to administer as these things are not paginated in the admin (though not an an issue from API usage).

This sounds awesome Pete, I can't wait to try it out along with the other stuff you sent me today. It seems like every time I have to take a few days away from the computer, all the coolest stuff gets released

Thanks slkwrm, glad you like the new setup. Pete did a nice job getting it going. Congratulations on the new job!

Make that early next week instead. I was going to merge the branches today, but then realized I'm not likely to get much time on the computer this weekend and want to make sure I'm close by to assist with any upgrade issues. Though, I don't think there will be any issues, but just like to be available. So will probably merge Monday or Tuesday.

ProcessWire will let you do this too. You can pull any file/image from any page, whether in the editor or in the API. When I need a lot of shared images, I usually setup a /tools/library/ page or something like it to serve as an image/file store for shared assets. Pages have a lot of uses.

This is the error you will get if you try to call size() on an array of images (i.e. a multi image field as opposed to a single image field). You mentioned that you changed it to a single image field, but you might need to double check that. Of course, if you need a mult image field, then keep it. But just grab the first image off it before calling size(), i.e. $image = $page->images->first(); $thumb = $image->size(100,100);

Edit the /.htaccess file that appears in the root of the PW install. There is a line in there that refers to "RewriteBase". Try uncommenting this line and typing your dir into it. This is needed on some installs (though rarely).

Here is the code that's generating it: $mysqli = new mysqli($values['dbHost'], $values['dbUser'], $values['dbPass'], $values['dbName'], $values['dbPort']); if(!$mysqli || mysqli_connect_error()) { $this->err(mysqli_connect_error()); $this->err("Database connection information did not work."); } The 'No such file or directory' error is coming from MySQL (or PHP's MySQL driver). It looks like there is some configuration issue between PHP and MySQL, perhaps something like this? http://stackoverflow.com/questions/1676688/php-mysql-connection-not-working-2002-no-such-file-or-directory Let us know what you find.

This update has been pushed to the dev branch. It now includes the hostname. Also made the email output a little easier to read. Because it's possible for hostname to include colons (for port number) I've changed the log format delimeter to be tabs rather than colons.

ProcessWire's selector operators *= and ~= rely on fulltext indexes, and I consider these crucial, which why ProcessWire is build around MySQL (MyISAM). Otherwise we'd be using MySQL INNODB and supporting other databases. The only other databases that one comes across regularly in commercial hosting environments are PostgreSQL and SQLite, neither of which support fulltext indexing, last I checked. So it's not a matter of wanting to support other databases, so much as it is a matter of what we need to do isn't easily done on other databases we're likely to encounter. Don't forget ProcessWire is a public open-source CMS, so it's what we're already doing and will continue doing. I stay in business by building sites for my clients with the CMS and they mostly don't know or care about the CMF aspect. But as a web designer/developer, the CMF aspect is the one that impacts my building and maintenance work the most. And it impacts my clients bottom line because it costs a whole lot less to build something complex in PW than it does another CMS (at least those I've used). I'm too impatient and don't think I could be a functioning web developer if I had to build sites around tools like Drupal, WordPress or even EE (and Joomla not even a consideration). There's a lot to like about some of those tools, but just glad I don't have to use them for building new sites. On the other hand, I've always been intrigued by Textpattern, its tag language and of course Textile which came from it. While I've not developed a full site in it yet, I can tell that it's got some real intelligence behind it and it feels a lot more cohesive to me than the other big platforms. That's why I'm enthusiastic even about the idea of it with a ProcessWire framework behind it and would see it as a mutual benefit to both projects. While I think them adopting ProcessWire for their backend is unlikely (given what they've already invested), I think there's still much we can learn from Textpattern. The fact that we've had so many Textpattern users take a strong interest in ProcessWire has likewise made me interested in the Textpattern project.

Where does the error message appear? it should be in the /site/assets/logs/errors.txt file for the site where the error occurred (unless the sites are sharing a common /site/assets/logs/ dir?). Let me know, I can add a hostname to the error log.

You can specify 0 for the width or height to have it be proportional to the other dimension. Or you can just use the width(x) or height(y) functions rather than size(x, y) function. So in your case, I think what you are asking for is this: $image = $page->image->width(400);

This isn't something that's on the roadmap. URLs of file-based assets are usually something that's behind the scenes and not something that the user or the administrator typically interacts with directly. We use this to our advantage and ensure that files are stored in a manner that is organized, can scale, limits potential name conflicts, and relate to their source. This ensures the CMS can effectively manage them with a page, avoid file system limitations, and recover from errors. I would see a common directory like /pdfs/ as being more the forte of something like a media manager that exists independently of pages. And that may be something that we'll see as a 3rd party module at some point.

This isn't possible using the default file and image fieldtypes, though anything is possible when making your own fieldtypes. A workaround that may be possible is to create a page called 'files' and set it's template ('files-gateway') to have URL segments ON. The page/template could then execute a search for the file (in field 'files') and redirect to it, or perform a passthrough. So it'd work something like this: Page: /pdfs/ run by template 'files-gateway' with this code in the template file: <?php if(!$input->urlSegment1) throw new WireException("No file specified"); $filename = $sanitizer->pageName($input->urlSegment1); $p = $pages->get("files=$filename"); if(!$p->id || !$p->viewable()) throw new Wire404Exception("File not found"); $session->redirect($p->files->get($filename)->url); // redirect to it So an access to /pdfs/my-file.pdf would redirect to the right file. You could also perform a passthrough, where you literally feed the file to them right here, but that's a little less efficient.

Since you are wanting to do next/prev with single products, I don't think you'll want to use PW's pagination at all. I think this also makes sense given that you want the URL to reflect the product name rather than a page number. So if I'm understand your example correctly, I think you'll want to do something like this: <?php $cat = the current category page; $product = the current product page; $products = $pages->find("parent=/ad-products/, categories=$cat"); $prev = $product->prev($products); $next = $product->next($products); if($prev->id) echo "<a href='./{$prev->name}'>Previous: {$prev->title}</a> "; if($next->id) echo "<a href='./{$next->name}'>Next: {$next->title}</a>";

Okay, hopefully someone else will reply that understands. This happens to me regularly where I don't understand something, but someone else comes in and understands perfectly. I will also come back and read this again when my mind is not tied up on so many work projects.

I added core support (in the dev branch) for directing to different /site/ directories based on domain or subdomain. I don't like telling people to make changes to the /index.php file since that's something that should be overwritten on updates. So figured I needed to provide an alternate approach here. If you have the /dev/ branch, take a look at the file /wire/index.config.php. Copy or move that file to your web root (or dir where PW is installed). Edit it and there are instructions on how to configure it. Each alternate /site-domain/ directory should be configured to use a different database. So the best bet is to do one of the following: 1. Copy the entire /site/ directory to a new /site-domain/ directory. Edit /site/config.php and supply new database information (seen at the bottom). Export your main PW site database, and import it to the new DB used by your alternate domain. 2. OR: install more copies of PW on your server (like in directories). After running through the installer, move their site/ directory to the /site-domain/ directory in the main PW install, and then delete any other installed copies as you don't need them anymore.

Thanks Marc, I will plan to put in this update soon.

I've always held Textpattern in high regard, so it makes my day just to hear that the developer thinks the idea has merit. I wouldn't expect them to pursue the idea, especially given the time they've already invested. There are probably larger considerations than it appears on the surface, especially for someone that authors a CMS. I also don't think it solves everything they are trying to do. For instance, PW already has a strong hook system in place, whereas their need is to support an existing one and maintain compatibility with it. Their list also indicated one of the goals as database independence, and PW is dependent on MySQL and certain aspects like indexes (fulltext indexes for example, which are far from universal). On the other hand, I do think PW as a framework would solve MOST of the things they are wanting to do, just not all of them. But that's only a surface evaluation and there may be much more to it when considered in the context of the TXP system, history, requirements, code as a whole. That's not something that I think any of us can evaluate. And especially not me, since I don't have much experience with TXP. But I think the best thing I can do is just express support and enthusiasm for the idea should it ever become a consideration. Lots of respect to Textpattern as a long running quality platform and group of folks that knows how to build a great CMS.

I'm guessing that you are getting that error because $item->image has no file attached. Also, we're assuming your field is named 'image'. But since it's possible items may not have images, you'd want to put this as the first thing in your foreach($items as $item): if(!$item->image) continue; // skip because there is no image In that case, replace $page->rootParent->children()->render() with $pages->get("/portfolio/")->children()->render();