ryan

Abu, Thanks for your post... this is really good info, and I'm impressed by your understanding of the language differences. I don't have a good understanding of these issues, so this is very helpful. You'll be glad to know we're not planning to handle translations on a word-by-word basis, but rather as entire blocks/phrases. So there would be a block for "a new page has been created", and the translator will be free to re-word that in any way they see fit. Want to help with the Italian translation sometime in the future? Thanks, Ryan

Hope you don't mind, but I added some stuff to your GMap module for fun. I modified it so that it has a field configuration option for "add markup automatically". So if you check that option on the field, then you don't have to add any code in your template other than this: <?=$page->map?> In the above, snippet, you would replace 'map' with your map field name. The updated file is attached. I think this is what you were trying to do before when we were writing in the other thread, so I figured it would be worthwhile for me to add it, in case it helps to demonstrate how. Another thing that I think would be cool is if there was a configuration option for it to pull an address from some other text field on the page. Then it would geocode and save it, so that it doesn't have to geocode again. Though I'm not yet sure how to do that, so just thinking... Thanks again for your work in putting this module together. This is something I will definitely use. Edit: Accidentally left a debug "echo" statement in the previous module, so have replaced it with a new version. GMap2a.zip

Looks like some good ideas that Facebook is on to there. I like what they are doing with it. But it looks like it's still JS based, and any solution that is JS based has little value for building your site's content for search engines. Unless they provide an API to it where you can render the comments yourself. But I kind of doubt that Facebook is providing that here. I'm also curious who owns the comments. Something tells me Facebook has a 50-page disclaimer about this. But these JS widgets are handy and easy to implement... I would think that sooner or later Google is going to have to start indexing pages with JS rendered content. Otherwise this is all a big black hole to search engines.

That is interesting that the apache charset was affecting this. I did just add a $config->dbCharset option that should be set to 'utf8' on new installations (and now is by default). This ensures that PHP is talking to MySQL with utf8 even when it's not the system default. However, this is probably something you wouldn't want to enable on an existing site if it wasn't already utf8. But if you perform a new installation of ProcessWire (from the latest commit) I'd be curious to know if this helps to resolve any of the issues you experienced. Btw, your PHP version is fine. 5.2.12 is newer than 5.2.4 (ProcessWire's minimum requirement) so you are all good with the PHP version.

We would just skip any field names that were already present and provide a warning indicating that. The nice thing about JSON or XML exports is that they are readable and easy to change, regardless of whether you understand the details of the format... it's ultimately just text. I like this style of export/import because it's easy to modify that text in between export and import. Most people wouldn't ever take advantage of that aspect, but it's nice to know that you can. So if you needed to change some aspect of the field (like the name) before importing, it's a straightforward thing to do.

The template will be cached, but it might never have an opportunity to see the GET vars (except when regenerating the cache). Since the output is cached, it would deliver cached output and your code that looks at the value of a GET or POST var would only run when the cache is rebuilt. This is why I usually leave off template caching for any pages that need to examine GET, POST, COOKIE or SESSION vars. Examples would be search engines, forms, etc. Btw, the template cache is always off when you are logged in. Template caching is applicable only to anonymous users visiting the site. The reason why ProcessWire doesn't cache GET vars is because there is an infinite number of them possible. We don't want to make it possible for someone to fill up your hard drive with a million different cached variations of the same page with different GET vars. On the other hand, ProcessWire will cache up to 999 URL segments or page numbers, for each page that is using them (when enabled for it's template). However, unless your page is slow to render, it's simpler just to leave off template caching when pages using it need to generate different output according to the request.

Is this online somewhere that I could login to it and see what it's doing? I want to try out the page list with FireBug active to see what the ajax calls are reporting. If you want me to do that, please send me a PM with the login info. If not, then maybe I can reproduce locally with a copy of the dump file. Also, double check that you are running a recent commit, just in case you are running into a bug from an older commit. Lastly, what browser and PHP version are you using? I have seen the behavior you describe on PHP versions prior to 5.2.4.. though I'm guessing that's not the case here.

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