ryan

Edit your tinymce field in Setup > Fields. Near the bottom you'll see "TinyMCE advanced configuration options". Click that, and locate the "valid_elements" input. This contains a list of all tags it will allow and the attributes it will allow with them. You should see the one for the "a" tag that currently looks like this: a[href|target|name] Update that to add the 'title' attribute to it, like this: a[href|target|name|title] But before you do this... This came up with a client recently, so we still have the research. Title attributes are likely not used for search engine ranking purposes. My thought is you shouldn't worry about putting SEO time/budget towards crafting link title attributes… focus on the anchor text and alt tags instead. There are times when title attributes can be handy for providing additional context or tooltips, but use them for that reason and not for SEO or accessibility. I say 'not for accessibility' because last I heard, those using screen readers are generally annoyed by the title attributes and much prefer the anchor text (or the alt tag, if it's a linked image). I realize it's hard to go on anything that one person says unless they work at Google. But here are a couple of recent sources for title attributes lack of SEO value: This page summarizes it best, and is consistent with other trusted seo's in the industry: http://www.highrankings.com/useless-seo-tactics-303 The results of a recent test in google involving the link title attribute (also consistent with other's results and tests): http://www.webmasterworld.com/google/4265397.htm And a couple from seomoz: http://www.seomoz.org/learn-seo/external-link http://www.seomoz.org/qa/view/48761/does-the-title-attribute-in-a-link-add-any-a-value-for-the-ranking-of-the-mentioned-keywords

To add a new menu item in the admin, you just go in there and add a page like you would anywhere else (and use the 'admin' template for that page, or one of your own if you prefer). If you want it to live between 'Pages' and 'Modules' then just drag it between those two. If this is something that you want to do automatically (like as part of a module installer) let me know and I'll post a code example. My understanding is that you want to display a custom HTML table of pages on your new admin page. You can go about this in two ways: Option 1 You can do it the same way as you would for any other template in your site. Only you would select your new template for that page rather than the 'admin' template. You would set access with the page (2.0) or with the template (2.1). The advantage of this approach is that it's really easy. The disadvantage is that your page may not look like the rest of the admin or use it's systems (which may or may not be useful to your need). Option 2 Use the 'admin' template for your page, create a new 'Process' module and install it. When you edit your new page, it will ask you what Process it should run, and you'll select the new Process module you created. This is the approach you want to take if you want to maintain a consistent admin experience or you want to package your functionality into a reusable module. Here's an example of how to create a Process module: /site/modules/ProcessHello.module <?php class ProcessHello extends Process { public static function getModuleInfo() { return array( 'title' => 'Hello', 'summary' => 'Simple Process module demo', 'version' => 001, ); } public function execute() { return "<p><a href='./hi'>hi</a> or <a href='./bye'>bye</a></p>"; } public function executeHi() { $this->message("Well hello"); return "<p>You clicked hi!</p>"; } public function executeBye() { $this->setFuel('processHeadline', 'Goodbye?'); $this->error('Not so fast!'); return "<p>You clicked bye!</p>"; } } Regarding your question about permissions: The user must have access to the page your Process is on before they can execute it. And they will already by default (unless you change around the page/template permissions). But in PW 2.0, they must also have access to a permission with the same name as the module. PW 2.0 installs that automatically with your module. This is only applicable to non-superuser roles (superuser can already access everything regardless of permission). In 2.1, PW doesn't install a permission and access to the Process is assumed if user has access to the page it's on. If you want PW 2.1 to behave like PW 2.0 and require a specific permission before it'll run the module, you want to specify it in your getModuleInfo function: <?php public static function getModuleInfo() { return array( 'title' => 'Hello', 'summary' => 'Simple Process module demo', 'version' => 001, 'permission' => 'name-of-permission', // NOTE THIS ); } Replace 'name-of-permission' with the permission name you want it to require. It can be any existing permission, or one that you've created. Your module can also check other permissions on-the-fly, but I won't get into that here unless someone wants me to.

Jose, Thanks so much for your efforts here. We would definitely appreciate your help in getting official nginx support for PW. I don't have experience with nginx, but your post makes me want to try it out. For starters, I will update our site next week to cross reference your info here so it'll be easy for others to find, and let me know what else I can do to provide better support for nginx. You'd mentioned the installer, but I'm not exactly sure what to detect--I think I need to get nginx installed on my dev server. I look forward to the next steps here. Thanks!! Ryan

You can modify the titles of the items before sending them to $rss->render: <?php // retrieve the RSS module $rss = $modules->get("MarkupRSS"); // configure the feed. see the actual module file for more optional config options. $rss->title = "Latest updates"; $rss->description = "The most recent pages updated on my site"; // find the pages you want to appear in the feed. // this can be any group of pages returned by $pages->find() or $page->children(), etc. $items = $pages->find("limit=10, sort=-modified"); // add something to the item titles foreach($items as $item) { $item->title = $item->title . " my text"; } // send the output of the RSS feed, and you are done $rss->render($items);

Thanks for the followup. Just to confirm, it was a server outage not a ProcessWire one? The error message you posted sounds like it was running into trouble trying to access the MySQL db.

Adam, good find. I've updated the code to this and am committing it now: <?php // convert 1-100 (worst-best) scale to 0-9 (best-worst) scale for PNG $quality = round(abs(($this->quality - 100) / 11.111111)); imagepng($thumb2, $dest, $quality); I also tested the quality settings manually by inserting the quality number in there. The problem is that [at least on my dev server] there is no visible difference in quality or filesize between specifying 0 and 9 to the imagepng() function. Do you find this to be the case there too?

Nikoka, Can you edit /site/config.php -- locate the line that says "$config->debug = false;" and change it to true. Then try to load a page in your site. You should get a more specific error message. I am guessing that there was some change at the server that affects PW or the database index needs a repair or something simple like that, but let me know what you find. OR, you can check /site/assets/logs/errors.txt and see what it says at the bottom of it. For security, you can't access this file from your web browser, so you'd have to do it from the file system (FTP, shell, etc.) Please reply to let me know what you find, Ryan

Thanks for the followup. Glad that worked.

Alex, TinyMCE seems to be inconsistent about when it applies the <p> tag inside tables. I think its behavior may vary from browser to browser, though have not confirmed that. I'm using Firefox 4 and Chrome 12. On the sites that I use it on, it's only on rare occasions that a <p> tag shows up inside table cells. Because it's so rare, I just remove them manually when it happens in the HTML code view of TinyMCE. If you are finding it's doing it all the time, first check that you don't have any TextFormatters turned on in your field. When using TinyMCE, you generally don't want any other text formatting to take place since TinyMCE is writing out HTML. If you can't solve this with TinyMCE settings, you may want to do something more brute force. Edit this file: /wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module Then locate this function: <?php public function setAttribute($key, $value) { if($key != 'value') return parent::setAttribute($key, $value); /* // remove empty tags $value = preg_replace('{<([a-z0-9]+)>\s*( |<br />)*\s*</\\1>}i', '', $value); // replace fake bulleted lists $value = preg_replace('{<br />\s*[-*]\s*}m', '<br />', $value); // fix breaks to be paragraphs $value = str_replace(array('<br /> <br />', '<br /><br />'), '</p><p>', $value); // fix paragraphs that start with a break $value = str_replace('<p><br />', '<p>', $value) ; // remove arbitrary and incorrect bulleted lists $value = preg_replace('{\s*•\s*}', ' ', $value); // fix those darn tags $value = str_replace(' ', ' ', $value); */ return parent::setAttribute($key, $value); } That function is what sets the value in ProcessWire, so you can modify the output from TinyMCE before it gets saved if you want to. Note all the commented stuff in orange. Those are all various solutions I've had to use to solve a specific problem on a specific site at one time or another. They are commented out because they really only apply in specific cases. But it sounds like you have a specific case like this. So what I would do is add something like this before or after that commented stuff already in the function: $value = str_replace("<td><p>", "<td>", $value); $value = str_replace("</p></td>", "</td>", $value); That would make it remove <p> tags that open and close with the <td> tags. This may not be an ideal solution, but it would get the job done. If you want to account for possible whitespace between the opening or closing table cell and paragraph tags, here is another solution to try (though writing in browser, not tested): if(preg_match('/<td>\s*<p>/', $value)) { $value = preg_replace('{(<td>\s*<p>|</p>\s*<(/)td>)}', '<$2td>', $value); }

This is one I've not heard of before, but I'm guessing some error is occurring that's getting thrown by PageEdit and then misinterpreted by PageRender. Which version of ProcessWire? 2.0 or 2.1? The following applies regardless of version, but this might help me to determine the source of the problem. Can you edit /site/config.php and find the line with $config->debug = false, and set it to true. Try to perform the page save again and see if you get any other error messages. If there's anything revealing post here. Otherwise, edit one of your site's existing template files and add this temporarily at the top: <?php echo "<pre>"; $p = $pages->get(5772); if($p->id) { echo "\n{$p->path}\n{$p->status}\n{$p->template}"; $p->setOutputFormatting(false); $p->status = Page::statusOn; $p->title = $p->title . " (test)"; $p->save(); echo "\nSaved page\n"; } else { echo "\nUnable to load page\n"; } return; Now view the page using the template where you pasted that. What does it say? If it appears to have saved the page successfully, try and edit again in the admin and see if you still run into the 404 error? Thanks, Ryan

There are positives with every CMS project and things to learn. There is no one-true way to approach things. Instead it's just a matter of different CMSs meeting different people's needs and preferences. My relatively brief experience with Symphony left me feeling that it was very much in opposition to how I work. But I have no doubt there are also good points and ideas to learn from, as there are with many products. I try to spend a good deal of time experimenting with other CMSs and will be sure to give Symphony more time based on your suggestion. In terms of organizing content for an editor with some form of limited access (as opposed to a superuser), I would suggest experimenting with ProcessWire 2.1 rather than 2.0. I think that 2.1 represents a stronger system for working with access to specific types of content. You define the access with the template rather than the page in PW 2.1. My opinion is that the tree view is the right approach whether you have access to all the branches in the tree or not. It is consistent and representative of the site's front-end structure. On large sites, confusion arises when you start pulling things out of the context of the site's structure (at least, that's my experience). You actually have quite a lot of flexibility in defining how this tree works in 2.1, including the ability to specify what fields appear in it on a template-by-template basis. But the desire to display pages in an alternate way in the admin has come up before, so you'll also be glad to know the new page search module can be used as a page listing filter (enabling nearly any kind of page listing display), and we'll be taking this utility a lot further as we move forward in PW development. But the tree structure will always be PW's native view into your site... we'll just provide more options for those that want it. The debug tool sounds interesting. I wouldn't want to take the approach of intercepting GET vars or making PW produce output directly in that manner, because PW promises not to take that control from your template. But you can achieve a similar type of result pretty easily just by adding a little code to your template's file. For example: <?php if($input->get->debug && !$user->isGuest()) { echo $page->renderFields(); // uses the MarkupPageFields core module // or iterate through the page's fields on your own to produce JSON, XML, etc. return; } // otherwise render regular page output

Okay that's good to know, thanks for the clarification. We've already got the note about the RewriteBase commented in the htaccess file so I won't worry about that one. But knowing that it's required at 1&1 (a fairly major hosting service) I might need to call more attention to this in the install directions.

Very cool, it looks like the 2 languages work beautifully in this example. This is the first time I've seen such a solution in place, nice work. I also like that the language-switching links stay on the current page, so that hopefully Google will index the whole thing in both languages (using the url segments). My only concern would be about whether this might confuse Google (or other search engines)–I suppose that would only confuse Google if GoogleBot maintained session cookies… and I don't know if it does. But if it does, you might be better off requiring a form POST before setting the session cookie to change the language, setting the cookie with Javascript, or forcing the language URL segment to always be on the URL for one of the languages. The last solution mentioned there would be the best but also be a little harder to implement. If you are interested, I can describe how to do it. But if potential confusion to the search engines is not a concern, then you don't need to worry about any of these as the site appears to function beautifully for the user.

This is an excellent idea. This is what PW uses for cleanup when you delete a page. For a site-wide cache clear of images, this may work very well. But on a really large site, it may be slow (or run out of memory) since it'll involve loading all the pages on the site. So for the image cache clear that I'm writing, it's going to most likely just stick with hunting in the file system and confirming that it's a variation based on the existence of the full size image.

Great–glad that worked with minor changes. Thanks for the follow-up. I'm thinking we should adjust the date-based selector strings to automatically run strtotime on any strings passed to it that aren't all digits. That way we wouldn't have to use strtotime to build the selector in instances like this.

Thanks for the kind feedback. I know what you mean about the terminology for templates. A template might be described as a page type (or content type) in other CMS projects. Despite the literal definition, the word 'template' can evoke a file rather than a type. I think this is because of the way the term is used in other CMSs. But in PW, the file is just a component of the template. It's an important connection, but one that I get tripped up on wording sometimes too. Maybe the best way to describe it as the "template's file", clarifying that the file is owned by the template. I would refer to it as an "output file" or a "view", except that they are not always accurate… Your template's file might just as easily be a controller that's calling upon other views. I guess it just depends how you are using PW, and there are plusses and minuses to not being too specific with the terminology. Perhaps we will come up with some better terminology at some point, so lets keep thinking.

Thanks for posting this. 1&1 is a large hosting provider, and if they require modifications to the default htaccess in order for the site to work, this is really good to know about. I'm sure this will be helpful to others. I'm just wondering if there is anything I can do to avoid having it not work in the first place at 1&1... it's not safe for me to assume a www redirect in the default .htaccess file, or to apply a rule like that based on the status of HTTPS. They must have an unusual configuration at 1&1. I will do more research into this.

Thanks for posting! I'm sure this will definitely help out many people looking to install on IIS. I need to link to this post in a couple other spots too.

Thanks for the followup and glad to hear it's working well.

Thanks for posting. I'm guessing this part is necessary because 1&1 is defaulting to PHP4? (and this forces it to use PHP5?) AddType x-mapp-php5 .php .html .htm AddHandler x-mapp-php5 .php .html .htm There are some security considerations with making HTML documents run through PHP, so unless you need that, you may want to remove the .html and .htm extensions from being parsed by PHP. Why are these lines necessary for 1&1? RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L] Is looks like this redirects a non-www hostname to a www hostname (we're doing the opposite with processwire.com). Thanks, Ryan

I don't see your template here, but it came through in the email I got. I've never used output buffering in my own templates so don't know if there is some unusual side effect resulting from that. PW is already output buffering everything in your template, and you are output buffering on top of that. Should that matter? I have no idea. But so far that's the only thing unusual I can spot about your template. Does the problem occur only on pages using that template, or on others too?

Thanks for your feedback. This is an interesting topic, and I'm not sure that I totally understand what you are saying, and may need more context. But looking at the diagram you linked to, it reminds me of why ProcessWire was built in the first place. I'm equating their 'sections' with templates in ProcessWire. But their definition of templates are also something separate beyond that, and 'entries' are a separate entity from 'pages' (if I'm understanding it correctly). While the terminology is varied, this is what I was describing as one of my fundamental problems with EE and Drupal. I'm not suggesting it should be a problem for you or anyone else, but for the sites I develop and the way I develop them, I don't like extra layers of complexity that fall outside the context of the front-end. Not specific to Symphony, but consider: channels, nodes, taxonomies, categories, sections, entries, resources, and on and on. Taken in the context of the front-end and boiled down to their core, they are all pages or behave like pages. Looking at the big picture, IMO these are all unnecessary complexity and that's why ProcessWire is designed exclusively around pages. Earlier versions of PW and Dictator have been split out into more layers (not unlike that diagram, and even using some of the terms mentioned above). Over time I've found more benefit to reduction and simplification. Far more benefit than to the occasional and potential flexibility of keeping them separate. if you get deep into the API, you'll even see one hold-out: Fieldgroups (aka sections in Symphony) are separate from Templates in the API, but not from the admin. And that will probably change eventually too as we work to simplify more and more. The goal with PW is not to solve all needs, but to solve most in the simplest way possible. I like to wander into concept and theory, so please forgive me for straying off topic a bit. It sounds like you are talking specifically about building forms... though I still haven't figured out how to connect that with the diagram. But we don't have a form builder (other than the one used by the admin). The form builder is scheduled for version 2.3 of ProcessWire. So this type of feature is on the roadmap, but multi-language functions are coming first. The form builder is not next on the priority list only because it's not something that necessarily provides more flexibility, just saves time (i.e. you can implement forms of equal flexibility and power without a form builder). The challenge will be to do all this while continuing to make the system simpler, and we'll get there.

It should be fine to remove all of those. I would suggest disallowing indexes just for security (keeps prying out of directories without index files). But if indexes are already denied, then all good. The ErrorDocument stuff is just an optimization to keep the favicon.ico and robots.txt requests from getting sent to PW. It is fine to remove those. The FilesMatch is a secondary measure and it should be okay to remove. Several of the RewriteRules are doing roughly the same thing. The php_flags are just optimization and are fine to remove. Likewise DirectoryIndex is fine to remove.

Adam, can you try clearing your cache: Admin > Modules > Page Render > Clear Cache To me it looks like a permissions issue. So if you get errors when clearing the cache, or if it doesn't work, you might want to try and remove all the dirs below cache/Page/ manually. i.e. rm -rf /site/assets/cache/Page/* I think Almonk also wrote some shell scripts that do this. Let me know if the error persists after clearing the cache.

Okay good news, this is now available in the latest commit of 2.1: https://github.com/ryancramerdesign/P21/commit/da6418cedeede89b7039341536641e5080fea144 To use it, you have to add a ".count" to the end of your field name. Using your example from above: $children = $page->children('images.count>2'); The reason you have to use ".count" is because without it the operator is comparing the image's filename. While I could redirect the ">", "<" and related comparison operators to the count, I wanted to find a consistent way to do this throughout the system, and adding ".count" to the field name seemed the most logical way to do it. You can use this with any multi-value field: files, images, page references, comments, etc. You can also use it with a page's children, i.e. $children = $page->children('images.count>2, children.count>0'); Note that all pages have a 'children' property, so it can feasibly match any page. But maybe not all pages in your system use a template with the "images" field. PW doesn't attempt to match pages that don't even have the field, so if you did this: $children = $page->children('images.count=0'); ...that will only match pages that have an images field with zero images. It won't match pages that don't have an images field. This is for consistency with other selectors. Please let me know how this works for you and/or if you run into any errors with it. Thanks, Ryan