ryan

Welcome to the forums Rishi. When you say "SQL Server", I'm thinking you are talking about Microsoft SQL Server, but let me know if I've misunderstood. I've never used SQL Server, so don't know what tools may be available for it, but I have to imagine there would be something like PhpMyAdmin. I think that a tool like that would do exactly what you are asking for.

If you want each of the sites to be completely isolated from each other from a search perspective, and from an admin perspective (where /site1/ is represented by the homepage (id=1) in ProcessWire) then you could install a separate copy of PW in each /site1/, /site2/, /site3/. Of course, you could use a symlink to make them all share the same /wire/ directory. Though unless you need them completely isolated from their database, you may just want to install 1 copy and use access control (in templates) to limit your editors access to the branch you want them to edit.

That will be easy to do. Lets say you've got a field called 'related_pages' that is a multi-page reference field. Here's what you might do on your 'article' template to display them: // get pages that this one is identifying as related $related = $page->related_pages; // get other pages that are identifying this one as related, and merge them $related->import($pages->find("related_pages=$page")); // output the related pages echo $related->render();

If PW is paginating any other $pages->find() / $page->children() calls that you don't want it to, add a "start=0" to your selector, for the calls you don't want it to paginate.

When you say multisite, do you intend to use a different domain to each site? Or are all of these just different sites on the same domain? And just to confirm, you are saying that you don't want the individual sites to have any cross-visibility?

Where as the tags stored? As part of the 'description' field for each image, or are you using a custom Fieldtype/Inputfield for your images? I'm going to assume they are in your description field, so you could do something like this: $tags = array(); $tagCloud = array(); foreach($page->images as $image) { $t = explode(' ', $image->description); $tags = array_merge($tags, $t); } foreach($tags as $tag) { if(isset($tagCloud[$tag])) $tagCloud[$tag]++; else $tagCloud[$tag] = 1; } ksort($tagCloud); The end result would be an alphabetically sorted $tagCloud array with each key being the tag and each value being the number of times the tag appeared. So you could output it in some manner like this: foreach($tagCloud as $tag => $quantity) { $fontSize = 10 + $quantity; echo "<span style='font-size: {$fontSize}px;'>$tag</span> "; }

Good to hear. Glad it's working well there--great site!

Okay I will plan to make this update.

Check that $config->debug = true; in your /site/config.php file. However, I'm not sure that'll help us here as it looks like Apache isn't even getting the opportunity to load PW's index file. I'm guessing that the file permissions are such that Apache doesn't have read access. Try doing this from your shell account: chmod og+r /srv/httpd/chrishenn.net/public_html_dev/index.php Or if you only have FTP, check the file permissions in your FTP client to ensure that you have an "r" (read access) for owner, group, and other. I'm guessing there is no read access for 'other'. Update the permission then try to load again. See if the error message changes at all. If it does, then very likely that's it (and you'll need to make the rest of the site readable to apache). Please let us know what you find.

When you do something like this: $p = $pages->get('/some/other/page/'); echo $p->render(); …the $page API var is set to $p for the duration of the render() method. Meaning the original context ($page) is not visible to the system, only /some/other/page/. Once render() finishes, PW sets $page back to the original, if there was one before it. Perhaps we need to maintain an accessible stack of them for the API. But the way you could do it now would be to create an autoload hook, and save the value of $page from a ready() function, i.e. class Test extends WireData implements Module { public static function getModuleInfo(return array('title' => 'test', 'version' => 100, 'autoload' => true)); public function init() { /* needs to be here, but not used */ } public function ready() { $this->setFuel('originalPage', $this->page); } } In the above, you'd be setting a new API variable called $originalPage that would always have the originally loaded page so that you could refer to it when needed.

After successful installation and first login, PW isn't going to report errors on a production site in order to ensure security. When it comes to sessions, PW is delegating session control to PHP's session functions. I believe these will report errors (when PW & PHP will let them), but won't throw fatal errors/exceptions when a session can't be written. If you ever think an error might be occurring, edit your /site/config.php and change $config->debug = true; That will ensure that error messages are displayed. But having all error messages suppressed by default ($config->debug = false) is always recommended for security on any production site. Once your assets dir is writable, you'll also be able to find error messages in /site/assets/errors.txt, regardless of the debug state. Also add your email address to the $config->adminEmail in /site/config.php so that errors are emailed to you as well.

Thomas, thanks for the explanation, I think that I understand now. Diogo beat me to the reply, as I was going to suggest exactly what he said because that's the way I usually handle this need in PW sites. I suggest using asmSelect for your block selection inputfield, as that will enable you to both select the blocks and drag-sort them in the order you want them to appear. Lets say that your page reference field is called 'blocks'. Each item in there refers to a page, and each of those 'block' pages has a template file that renders the block the way you want it output. The template file for your page that shows the blocks can output them like this: foreach($page->blocks as $block) echo $block->render(); So the above would display all of your blocks selected on the page, and in the order the admin dragged them.

Create a new textarea field and don't apply any textformatters to it. Output the contents of that textarea wherever you want to in your template file. Just be aware that you only want trusted users to be able to populate this field, as someone could just as easily populate it with a malicious <script> as with a useful one.

Beautiful site Leroj! Amazing properties here too. I see you are using a multi-tree approach for languages. Are the trees independently maintained, or using Oliver's module, or another method?

Looking good theSeekerr! I could have sworn this must be running in WordPress, as you've managed to do a great job of getting the full blog feel here. Beautiful photos you are featuring there too. Thanks for posting it, keep up the good work.

Thomas, welcome to the forums and thanks for your feedback. I'm having some trouble with context here as 'widgets' is a generic term that can mean a lot of things. But if I understand correctly, you probably want to locate your widgets pages elsewhere, perhaps under a /widgets/ section in the site. Page references allow you to easily break outside of the parent/child relationship of the tree for the times when you don't want items in the tree. You mentioned a fieldtype too, and I think that's always a good way to go. If you want a good working example to start from, grab the FieldtypeMapMarker, which comes with all the components you'd need and is commented and ready to modify towards your needs. Though I should mention this is a regular Fieldtype rather than a FieldtypeMulti (repeatable elements). I'm also thinking that the FieldtypeRepeater that I'm working on may be helpful in your case. With this fieldtype, you specify a template and then it creates a repeater using the fields in that template. You can then add/delete/sort the items (groups of fields) within the page as much as you want. But this new fieldtype is only a work in progress, so may be another week or two till I've got a release-able beta version to play with. If you can give me some more background on what widgets are in this context, I may have some more ideas too. I'm sure we can find a good solution.

I can see using a browser resize where a max width or height is specified, but am not so sure if it's good to have ProcessWire going and creating multiple new thumbnail files just so they can be selected in the admin. Perhaps a good balance would be to display the ones with thumbnails where the 'admin thumbnails' option is selected with the image field, and just use the same thumbnail.

This is what it currently does. It's all handled by the installer (/install.php on a new installation). The profileImport() function creates these directories: /site/assets/logs/ /site/assets/cache/ /site/assets/sessions/ /site/assets/files/ When the mkdir() function fails, it reports this message in red: "Error creating directory: $dir". The error message(s) would appear on the screen after you've entered your database information and clicked submit. I had an experience with one web host where they had some automated process that came through regularly and changed the permissions of directories, without my knowledge. Of course, such an automated process isn't exactly CMS friendly. Another situation where permissions on those directories could be lost is if you have a site running in one location, and then copy it to another. If you haven't transferred it in a way that retains permissions, you'd have to fix the permissions on those /assets/ directories (and files in them). If you have shell access, you could do something like this: chmod -R og+rw /site/assets Is it possible you've run into something similar, or can you think of any other factors?

Thanks for the update!

Thanks for the tip Robert. I'd read about these tags, but never really understood exactly how they worked. Good to get some insight on this and perhaps I should start using them here.

Import/Export with JSON strings (or web services or both) would be nice to have. It won't be very hard to do. I will try to work this into some future update for 2.3 or before.

Thanks Robert, that's definitely good to hear. I will plan to do that. I'm wondering if this will mess up people that are tracking the repository, making them have to set a new remote, or if Git does some kind of redirect automatically? That's probably not an easy question to answer... I may have to do a test to find out. I just want to avoid inconveniencing people as much as possible. I'd rather just keep the repository name 'P21' than cause any problems for people. But hopefully can find a way to rename it without any side effects.

B ?

Thanks for reporting back on this. Glad to hear you found the source of it. And of course, glad to hear it's their problem rather than ours.

I do still plan to implement that, just haven't gotten to it (wanted to get content_css going first). But I'm thrilled to hear the bramus_cssextras solves the issue with removing classes!