ryan

I'm still not totally sure why this would be interfering with the Page List since it doesn't use those fields... But I'm thinking that one of them must have 'autojoin' on, and it's getting stuck during the load process. Are you able to view the page with the Russian titles on the site? (outside of the page list) Also, how did you convert those tables to UTF-8? It may not work to just modify the table's character set. You may actually have to mysqldump them forcing latin1, then open the dump file in a UTF-8 compatible text editor (ensuring it loads it as UTF-8, no BOM), modify the 'create table' statements to replace 'latin1' with 'utf8' in the charset definition, and then re-import the tables and data. While this is easy to do, it's also kind of a pain to have to go through all those steps, so I'm sorry about that. But this has worked for me in the past, where just modifying the table's charset didn't.

There aren't supposed to be any latin1 tables, but you are right -- there were those 3 custom fields lingering from the default site profile (headline, sidebar, summary). I just updated the default install profile to make them utf8, so hopefully that will fix it on any future installations. If you need help converting existing tables to UTF8, just let me know and I can tell you how. The Fieldtype table creation function already enforces UTF8 for any newly created field tables, so hopefully no more latin1 charsets will pop up anywhere. The only thing is that I'm not sure why it prevented the pages from loading in the page list, since none of those fields are used in generating the page list (unless you added one to the Modules > Page List config). I wasn't able to load dirty.ru (timed out), but just copied some text from a random Russian site and pasted it into the title and all seems to work. Let me know if you continue to experience the issue after changing the table's charset (or from a new install). Thanks, Ryan

Thanks, glad you like it so far. The examples you mentioned should work well. Though I would probably recommend using URL segments rather than GET vars, so that the template output can be cachable. (GET vars aren't cachable at the template level). For example, lets say that domain.com/news/ is a page that lists an index of the latest news items. In your template, you could have it detect a URL segment "rss", so that domain.com/news/rss/ displays an RSS version of it instead: <?php if($input->urlSegment1 == 'rss') { // display the RSS feed $rss = $modules->get("MarkupRSS"); // ... $rss-render($page->children("limit=10")); } else { // display the regular news list template output include("./news-list.php"); } I agree that this should probably be a core module (/wire/modules/) so I will add it to the source and include an RSS feed example in the default site profile.

If using parent sorting, it should honor the order that is set on that parent. But if using template sorting, I'm not sure that there is an order... I will have to check, but it sounds like there isn't from what you are saying. You are right that there should be, so I will add it. If you want to use the alternate code, that is another way to do it. In that case, you would just type this in there: return $pages->find("template=something, sort=title");

Can you post the cyrillic title that it got hung up on? (or PM or email to me if you prefer). I want to duplicate the issue locally so that I can fix it. Also, which table are you referring to install.sql? Thanks, Ryan

This topic has been moved to Modules/Plugins. [iurl]http://processwire.com/talk/index.php?topic=90.0[/iurl]

Thanks for your feedback. I've added an option to limit the length of the item description field. You can now set this in the module config screen. It will attempt to truncate to the closest punctuation within your max length, or at the closest space if no punctuation is close by. If you download the current ZIP file attached to the original message, that will have it (MarkupRSS-module3.zip).

Good find. The FieldtypePage module was using a retrieval method without selectors, which bypassed the status check. I just added a status check to FieldtypePage, so that it will exclude pages with any status level above Unpublished (which includes Trash). Can you give it a try and let me know if it resolves it? Here is the change in the latest commit: https://github.com/ryancramerdesign/ProcessWire/commit/6cb6bc19a6e2841264368e8239cbc054bdbebc9d#diff-0

If you need to support multiple login pages, it would have to be adjusted before the template code (autoload module, include from your config file, etc.). But if I were setting this up, I think the best way to go would be to change $config->loginPageID in your config file to be your own login page, and just have one of them. Then let the login page template decide what to show and what to do. ProcessWire doesn't actually redirect to a login page, instead it just replaces the page they don't have access to with the login page... at the same URL. As a result, your template can still inspect what page was requested by looking at $_SERVER['REQUEST_URI'], or you could even load it: <?php $requestedPage = $pages->get($_SERVER['REQUEST_URI']); if($requestedPage->path == '/private-page/') { // our private page echo $pages->get('/private-page/login/')->render(); } else if(strpos($requestedPage->path, '/processwire/') === 0) { // for any admin page echo $pages->get('/processwire/login/')->render(); } else { // load some other login page or render it here } (In the above snippet, of your site is running off a subdirectory, like /mysite/, then you'll want to remove /mysite/ from the REQUEST_URI since ProcessWire won't recognize that as a path it manages.) With the example you mentioned, I'm not sure that the above info even matters, but I wanted to post it here as a solution for supporting multiple login pages. In your case, it just sounds like your /it/ page template needs to check if the user is logged in and send them to one page or another depending on the state. So here's what might work in your /it/ page template: <?php if(!$user->hasRole("required_role_name")) { $session->redirect("./login/"); } else { $session->redirect("./dashboard/"); } Replace "required_role_name" with the role you created needed to access the /dashboard/ page. If you only need to know that they are logged in, then you could replace that first line with this: if(!$user->isLoggedin() { ...

Before you start the install, the /site/ dir will be called /site-default/ and it will contain a few directories below it. The only one that matters in this case is the /site/assets/ dir, which needs to be writable. And apparently it is writable since the installer checks this in step 1, so that's why this is a mystery. But it then creates a couple of dirs in /site/assets/ and copies /site/install/files/ to /site/assets/files/. The directory creation and copy are failing. They shouldn't fail since /site/assets/ is writable, but for some reason the server is not giving permission, even though it says it will when we ask it. One possibility is that the /site/assets/, or some other parent dir is lacking "x" permission (permission to chdir into it). But you indicated that it was set to 777, so that includes "x" permission. I'm just wondering if some parent directory is lacking it (assuming that matters).

I took a look at your PHP info, and nothing jumps out to me as a problem. It looks like the server isn't allowing us to create directories, so Adam is right about the permissions issue. What's strange is that the installer isn't giving you an error on the first screen, saying that the /assets/ dir isn't writable. So apparently the directory is writable, but it won't let you create new dirs within it. I'm not really sure what permission would cause that (Adam?). You could install locally and then just copy all the files to your host. Export the database, import to your host, then update /site/config.php with your host's database settings (at the bottom of the file). But if you can't create directories on the server, this is going to prevent you from being able to add assets to new pages, as it creates a new dir off of /site/assets/files/[page id]/ for each page. So I think it's an issue that needs to be solved either way. Do you have shell access on this hosting account? I'm thinking you could try to install again, but do this after unzipping and before installing: chmod -R og+rw ./site/assets chmod -R og+rw ./site/install That shouldn't be necessary, but it's what I would try next, as it sounds like we're losing the writable permission somewhere.

Well if it was a cache issue, it affected mine too because I duplicated the issue here as well. I resorted to running all image insertions through the resize and letting PHP decide whether to perform the resize (Javascript is not my first language). I pushed another commit to account for this.

I'm starting to see why many CMSs take the icon approach too. Personally, I am not a fan of icons... 80% of the time, I have no idea what an icon is for in an application, even if it is pretty. And once I figure it out, I can't ever seem to remember what a given icon is for either... But I think part of that is just growing up with MS DOS rather than a Mac. I don't know what I'd do without tool tips.

I have just committed an update to fix this issue with the image editor, and you should see it on GitHub. Thanks for finding this and reporting it. It appears that I broke this a week or two ago when making some other upgrades to the image editor. I'm very glad to hear you'd like to be part of the project and welcome your contributions. Btw, since you've tried this in IE, you may have noticed there is an issue with the image editor in IE8 (modal overlay problem, that I've yet to figure out how to fix). I've not yet tried it in IE9.

You are right. I just tried and was able to duplicate it in Firefox too. I must have broken it during a recent update to this module. I will work on a fix now and hope to post shortly. Thanks, Ryan

Hi Jose, What browser are you using? Wanted to check, just in case. Then I'll go in and try to duplicate. Thanks, Ryan

Yeah but it shouldn't prevent the installer from running... The installer will just say "this dir isn't writable, and it should be". Since it appears the installer threw a fatal error before even running, I'm thinking all the files got unzipped into one dir (root) rather than in the proper structure. But so far it's a mystery.

I'm interested too. I didn't realize some of the language variations you mentioned. How do other CMSs do it in Slovak? Especially the issue you mentioned about different words depending on number of pages (1, 2-4, 5+)?

This is consistent with what's being planned. A "channel" would be defined as a selector or combination of selectors that can lead to a group of pages outside of the page tree. For instance: template=news, sort=-modified That would be a selector that lists all news items regardless of where they live in the tree structure, and places them in reverse chronological order according to when they were last edited. So I think of that as a "news" channel". If you wanted to do it from one of your templates, you would do this: $items = $pages->find("template=news, sort=-modified"); echo $items->render(); // or iterate and display your own fields I'm thinking of this channel view as being kind of an advanced search engine, where you can build a selector to look at a particular view of pages (channel). Then you can perform operations on the pages together as groups. You could predefine your own channels for later use in the admin or the API. Some parts of the admin would also predefine their own channels as well. For instance, there would be a link for each template in "Setup > Templates > Template" to display all the pages that use that template. The nice thing about this channel view is that it will be relatively easy to implement since all the page retrieval, field matching and pagination is already done... it's just a matter of building a nice interface around it. The only reason I haven't done it yet is because in my own sites I usually build the channel views on the front end of the site (with templates). Many of them make it in the public site, as views that are useful on the admin are very often useful to the site's users too. Also, I wanted to add that the existing Pages tree is customizable in terms of sorting and what fields it displays. http://processwire.com/talk/index.php/topic,120.msg749.html#msg749

In your /site/config.php there is a setting in there called: $config->loginPageID = 23; Change 23 to the ID of the page you want to be the login page. If you want to use a given login page only in some instances, I believe you can also change that $config item at runtime. For example, you might put this in some main template for your site: $config->loginPageID = $pages->get("/tools/login/")->id; I haven't tried this, so let me know if it doesn't work and I can find another way to do it or make it part of the template config as you suggested.

Looks good! I didn't do a lot of testing with the function I posted previously, so if you find any bugs that aren't easy to resolve, just let me know and I'll fix them.

I think it's possible that your archive didn't unzip properly. Can you double check that these files were created in your web root when you unzipped the ProcessWire ZIP file: /index.php /site/ (directory) /wire/ (directory) ...and some readme text files... If you see both /site/ and /wire/ there, that will help us to rule out a couple of things. Let me know what you see either way. If you'd like, create a file on your server called test.php with nothing but this in it: <?php phpinfo(); Then load that in your browser. Post the URL here if you are comfortable doing so, or email me the result. Remember to delete the test.php file once it's no longer needed.

I think we can automate the field creation part relatively easily. My plan was to add an Export/Import option to Admin > Setup > Fields, and it would basically export a JSON profile of all the fields you selected. Then you could paste that profile into another site into the "import" textarea, and it would create all the fields. The same thing could probably be done at the template level too. The idea you mentioned of a module is also a good one, though I'd probably be inclined to do the export/import described above instead. But here's how you'd go about doing the module if you wanted to. The module would exists to add the fields and templates needed for news. When you click "install" on that module, it would create the fields and templates automatically just with API calls. For example, here's how your module code might do it in it's ___install() method: <?php public function ___install() { $summary = new Field(); $summary->type = $this->modules->get("FieldtypeTextarea"); $summary->rows = 3; $summary->name = "summary"; $summary->label = "Summarize this news item in 1 paragraph"; $summary->save(); $datetime = new Field(); $datetime->type = $this->modules->get("FieldtypeDatetime"); $datetime->name = "datetime"; $datetime->label = "Enter a date"; $datetime->dateOutputFormat = "m/d/y"; $datetime->dateInputFormat = "m/d/y"; $datetime->defaultToday = 1; $datetime->save(); $fieldgroup = new Fieldgroup(); $fieldgroup->name = "news"; $fieldgroup->add($this->fields->get("title")); $fieldgroup->add($summary); $fieldgroup->add($datetime); $fieldgroup->save(); // copy your default news.php template to /site/templates/, assuming your server will let you... copy($this->config->paths->YourModuleName . "news.php", $this->config->paths->templates . "news.php"); $template = new Template(); $template->name = "news"; $template->fieldgroup = $fieldgroup; $template->save(); } Because we don't have the documentation complete to the level of detail of individual fieldtypes, you'd currently have to look at what was configurable with each field. The simplest way to do this is probably to view the source when editing that field in the Fields editor, and looking at what configuration options are available under the "Fieldtype Settings" and "Inputfield Settings". Or just ask me. You might have your module add a hook or two, like PageArray::renderNewsItems() or something like that, if it was helpful to do so. <?php public function init() { $this->addHook("PageArray::renderNewsItems", $this, "renderNewsItems"); } public function rnederNewsItems(HookEvent $event) { $pageArray = $event->object; $out = "\n<ul class='nav'>"; foreach($pageArray as $page) { $out .= "\n\t<li><a href='{$page->url}'>{$page->title}</a> {$page->datetime} {$page->summary}</li>"; } $out .= "\n</ul>"; $event->return = $out; }

I think you are both right. Having the two buttons would be great for people that routinely need to do both. But it's also true that it's one more thing to think about. On the page editor, it might be nice to have a collapsed field at the bottom that says "After Save...", and then radio buttons that let you choose: 1. Continue editing 2. View page 3. Return to List 4. Create new sibling page So you wouldn't see those options unless you clicked on the "After Save..." label to open it up. A checkbox would let it optionally keep your setting. This is kind of a power-user thing, so this functionality would be in an optional add-on module rather than something built into the core. Personally I would only use #1 and #4, but it sounds like #2 and #3 would be popular with other people too. For other types of editors (not page editor) it would be similar, but without option #2 of course.

I also need to make a new HelloWorld module to put in there too. The one that comes with it now is kind of specific to the Skyscrapers profile, which isn't used by many people.