ryan

By default, tinymce is configured kind of conservatively. So it removes attributes that aren't specifically allowed in it's configuration. You can change this behavior when configuring the field, under the "tinymce configuration" portion. Let me know if you need help. It's a little cryptic in that section, as it's in tinymce's format.

You can also just call it /site/ if you prefer. We only use /site-default/ initially so that people can continue to keep it cloned easily via Github without worry of it overwriting anything in their /site/ dir. As a result, there is no /site/ dir on the GitHub source (instead it's /site-default/ solely for GitHub). This is correct. Also note that the installer moves /site/install/files/ to /site/assets/files/. So if you were creating a new profile, you would copy your /site/assets/files/ to /site/install/files/ before zipping up your /site/ dir into a new profile. Also correct. This is so that you can create a site, and then easily export it as a profile just by exporting the database. The installer requires a fairly simple SQL file since ProcessWire uses PHP's MySQL commands to create the DB and insert rows. so things like extended inserts and such probably won't work. So here is the command I use to create a dump for a new profile: mysqldump --complete-insert=TRUE --add-locks=FALSE --disable-keys=FALSE --extended-insert=FALSE --default-character-set=utf8 -u[user] -p[password] [db_name] > install.sql After that, I edit the dump file with a good utf8 compliant editor (I use BBEdit/Textwrangler), and remove any extra junk that MySQLdump adds at the top and bottom of the file. This means remove anything that is not a "CREATE TABLE" or "INSERT" statement, unless you specifically want it there. Then I find the part where the insert statements are for table "users" and I remove all users except guest (ID 1). Likewise, remove all the insert statements for table "users_roles" except for the first one, which assigns role "guest" to user "guest" (1,1,0). Then your install.sql is ready. You are correct on all of this. You basically just create the site you want the profile to be. However, you shouldn't need to manually delete any images from assets, as deleting them on the page (or deleting the pages you don't want) will handle deletion of them automatically. This is right, but you can exclude everything from assets other than the dir itself. Your /site/assets/files/ should be copied or moved to /site/install/files/ (as mentioned above) before creating your profile. Why do we do this? Well if you deliver the profile with /assets/files/ already in place, and the file permissions weren't retained for one reason or another (like when they FTPd them or something), then you'd have to tell the user how to make all of the files in /assets/files/ writable. If they don't have shell access, this could be a time consuming process... a lot harder then just making /site/assets/ writable. By making ProcessWire move them from /site/install/files/ to /site/assets/files/, it ensures that there can be no issue with messed up file permissions, since ProcessWire will have created the files. If for some reason, ProcessWire can't move them from /site/install/files/ (like if permissions were lost when the user uploaded the files), then ProcessWire will copy them instead. Either way, it'll be able to complete the install with minimum hassle to the user. For the time being, the install profile will include the entire database. But not having made a lot of different install profiles yet, I've not given a lot of thought to doing it differently. It is possible that the core tables will be created/installed separately in the future. If you want to make something future proof, perhaps I should go ahead and make that change now... moving the core table creation outside of the site profile. This won't be too difficult from this end, and I imagine I could have that chance in place within a week. If it helps, here is my profile creation shell script. It creates a profile from a site that is running, so it goes and moves things around temporarily, creates the zipped profile, then moves them back. You'll see several things that get renamed to a ".old" version. My zip command (and .gitignore file) excludes files ending with ".old", so they are basically removed from the picture temporarily. I run this script after I've already exported the database, and placed it in /site/install/install.sql, using the method mentioned above. #!/bin/bash cd /Users/ryan/htdocs/sky/ <-- sky is the root dir of my PW installation chmod -R og+rw ./site/assets/* rmdir ./site/assets/files/* <-- this removes blank directories mv ./site/assets/files/ ./site/install/files/ mv ./site/config.php ./site/config.php.old <-- take the live config.php file out of the picture temporarily mv ./site/config-original.php ./site/config.php <-- and use a config.php without DB settings in it mv ./site/assets/cache/ ./site/assets/cache.old/ mv ./site/assets/logs/ ./site/assets/logs.old/ mv ./site/assets/sessions/ ./site/assets/sessions.old/ mv ./site/assets/installed.php ./site/assets/installed.php.old zip -r -v ./site.zip ./site/* -x@zip_exclude.lst <-- create the zip file, excluding stuff mentioned in zip_exclude.lst mv ./site/install/files/ ./site/assets/files/ <-- now move everything back so our site will still work... mv ./site/config.php ./site/config-original.php mv ./site/config.php.old ./site/config.php mv ./site/assets/cache.old/ ./site/assets/cache/ mv ./site/assets/logs.old/ ./site/assets/logs/ mv ./site/assets/sessions.old/ ./site/assets/sessions/ mv ./site/assets/installed.php.old ./site/assets/installed.php And here is my zip_exclude.lst file, referenced in the "zip" command above. You may not need anything other than the "*.old" and *.old/*" in yours. But I'm running on a Mac and use VIM, so most of these clear up potential files related to those. .DS_Store *.DS_Store *.old *.old/* sess_* *.cache *.swp *.sh Thanks for using it! Ryan

I was just testing out this screencast service that I saw Apeisa's been using, and made a little screencast demonstrating installation and use of your GMap module. http://screencast.com/t/IaCFikQwn

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