ryan

When you've got your first release version ready (if it isn't already), please post to the modules directory too.

The timepicker is not actually part of jQuery UI. It was an add-on created by Trent Richardson, as jQuery UI's datepicker does not have a timepicker. There is a tab on localization for this timepicker available here. Does this help?

Yes, I merged it to master yesterday. I just don't think there's any reason for new users (especially) to be starting with 2.2.9 at this point. The dev branch is more stable than 2.2.9. Now we can go back to letting the dev branch be a dev branch. I'll send out a 2.3 announcement later this week. While there are always more issues to resolve, there haven't been any major problems since people started testing. Nearly all issues that have come up have been related to needing a modules cache clear, or needing to start with a fresh /wire/ dir–things that people should do for any ProcessWire upgrade. I have now added these items to the upgrade instructions in the new README file included with ProcessWire. People upgrading from 2.2 to 2.3 should still follow all upgrade instructions exactly, backup, use caution and test thoroughly. Here are the upgrade instructions as they appear in that readme file: Best Practices Before Upgrading Backup your database and backup all the files in your site. When possible, test the upgrade on a development/staging site before performing the upgrade on a live/production site. If you have 3rd party modules installed, confirm that they are compatible with the ProcessWire version you are upgrading to. If you cannot confirm compatibility, uninstall the 3rd party modules before upgrading, when possible. You can attempt to re-install them after upgrading. General Upgrade Process If you are upgrading from a version of ProcessWire earlier than 2.3, see the sections below for version-specific details before completing the general upgrade process. Upgrading from one version of ProcessWire to another is a matter of replacing these files from your old version with those from the new: /wire/ /index.php /.htaccess Replacing the above directory/files is typically the only thing you need to do in order to upgrade. But please see below for more specific details about each of these: Replacing the /wire/ directory When you replace the /wire/ directory, make sure that you remove or rename the old one first. If you just copy or FTP changed files into the existing /wire/ directory, you will end up with both old and new files, which will cause an error. Note that the /wire/ directory does not contain any files specific to your site, only to ProcessWire. All the files specific to your site are stored in /site/ and you would leave that directory alone during an upgrade. Replacing the /index.php file This file doesn't change often between minor versions. As a result, you don't need to replace this file unless it has changed. Replacing the .htaccess file Like the index.php file, this doesn't always change between minor upgrades, so the same applies. This file is initially named htaccess.txt in the ProcessWire source. You will want to remove your existing .htaccess file and rename the new htaccess.txt to .htaccess. Sometimes people have made changes to the .htaccess file. If this is the case for your site, remember to migrate those changes to the new .htaccess file. Upgrading from ProcessWire 2.2 Follow the general upgrade process above. You will want to replace your /index.php and .htaccess file as well. Clear your modules cache. To do this, remove all of these files: /site/assets/cache/Modules.* Login to ProcessWire admin. You may get an error on the first web request you try, but that should only happen once, so just reload the page. Upgrading from ProcessWire 2.1 First upgrade to ProcessWire 2.2. (side note: I'm not positive this is necessary, you may be able to go straight to 2.3, but I didn't have any 2.1 sites to test). Follow the instructions above to upgrade from ProcessWire 2.2. Upgrading from ProcessWire 2.0 Download ProcessWire 2.2 and follow the upgrade instructions in that version's README file to upgrade from 2.0 to 2.2. After successfully upgrading to 2.2, follow the general upgrade process above. Troubleshooting an Upgrade If your site is not working after performing an upgrade, clear your modules cache. You can do this by removing all of these files: /site/assets/cache/Modules.* If your site still doesn't work, remove the /wire/ directory completely. Then upload a fresh copy of the /wire/ directory. If your site still doesn't work, view the latest entries in your error log file to see if it clarifies anything. The error log can be found in: /site/assets/logs/errors.txt If your site still doesn't work, please post in the ProcessWire support forums.

What admin theme is that? Since that looks like incomplete output, if I saw that screenshot you are seeing, the first thing I would do is CTRL+A (select all) to see if any error messages were present. If there weren't any, then I'd either look at the error log (/site/assets/logs/errors.txt) or enable $config->debug=true; in /site/config.php. Then I'd try again. When you say you moved it from /blog/ to /, what specifically did you move (files/directories) and how did you move it? If I were to do that here, this is what I would move: cd htdocs mv ./blog/wire ./ mv ./blog/site ./ mv ./blog/index.php ./ mv ./blog/.htaccess ./

If you are running into the same issues every time you migrate (regardless of server), look into what tool is being used to transfer files. Make sure you are using something that retains file permissions and that does some QA to make sure the files actually made it. Personally, I've always used rsync and it's always worked quite well. If the server doesn't give me shell access, then I'll use SFTP/FTPS with YummyFTP (OS X). I'm not aware of anything like this. While you could use ProcessWire from the API without functional sessions, you couldn't login to it if sessions weren't working. And you couldn't do anything if the DB wasn't functional. If sessions aren't working, just double check that your /site/assets/sessions/ directory is writable.

Not as far as I know. But this is a better question for Soma. From what I understand, LanguageLocalizedURL works very differently. LanguageSupportPageNames and LanguageLocalizedURL modules are not equivalents in functionality. But I think there is still some crossover, so individuals would probably want to evaluate both to see which meets their particular needs better.

I don't know what the threshold would be. But for me, if I was having to manage more than 10 pages separately in two languages, then I'd probably want to start using multi language fields and page names. Of course we've had multi language fields for quite awhile now. But the new LanguageSupportPageNames module really makes them worthwhile. I have to launch a site in April that uses this system, so I expect this to be production-ready in the core by then. Though it's all working in the core now (in the dev branch) and has been stable for me during development of this site.

Looks very cool Luis! I look forward to trying this one out after the weekend.

Most of the time a non-superuser wouldn't have access to template settings, so they shouldn't be able to re-enable that option.

Since your site is simple like you say, I would just make one branch in the tree per language. i.e. /en/ /about-us/ /contact/ /es/ /quienes-somos/ /contacto/ If you want to be able to translate static text in your template files, you'll want to also use code internationalization. Solutions like LanguageLocalizedURL and the new LanguageSupportPageNames become more valuable when the scope of maintaining two trees (like above) becomes too much work. But if it really is a simple/small site, then keep it simple.

ProcessWire doesn't output any 501s, so those are most likely getting sent from the web server before PW even gets a chance to boot. If you were running Apache, I'd say the first thing to look at would be mod_security meddling in requests. But since you aren't using Apache, maybe there's something like mod_security that is blocking certain patterns/combinations of requests that it thinks look suspicious? That would be my best guess anyway.

Thanks Soma, I see that too. Not sure why it's doubled up. I'll take a look and find a fix.

If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file: ini_set("session.gc_probability", 1); ini_set("session.gc_divisor", 100);

You might want to also look at using the YouTube/Vimeo Textformatter module on your body field. It includes a responsive option as well in the module settings.

That should work. You could also do it this way: $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $pages->get((int) $idioma_id); if($p->id && $p->viewable()) $page->htl_idiomas->add($p); } However, something that is missing that you definitely want to add is more validation. Meaning, check to make sure that the pages you are adding to itl_idiomas are in fact the pages you intend. This prevents the possibility of someone manipulating the POST values to include page IDs outside of those you allow. So I would do this instead: $idiomas = $pages->get('/tabla/idioma/')->children(); $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $idiomas->find("id=" (int) $idioma_id)->first(); if($p && $p->viewable()) $page->htl_idiomas->add($p); }

I don't think we are changing any defaults in this area, unless Antti can think of anything? But we are using the 4.1 (dev) rather than the 4.0 (stable) version of CKEditor, so maybe that's where the difference comes from. As far as I know, CKEditor doesn't have that capability. It's possible there may be a CKEditor plugin that provides it though, but I've not seen one yet.

One thing I want to mention is that you don't want to actually have a field of your own called "status", just because that is already a built-in field for every page. That is on our reserved words list, so I don't think PW will let you create a field with that name, but just wanted to mention it.

User information is not stored with files/images at present. However, you may want to install Teppo's Changelog module and Netcarver's Field change notifier module, which may accomplish some of what you are looking for.

Marc, you may want to change your hook from "save" to "saveReady" or "saved". If you use "saveReady", then you won't have to perform your own $page->save(); since you'd be hooking in right before $pages does it's own save. This is the same as a before "save" hook, except that it's been confirmed that a save will definitely occur, so a little safer. However, you'll probably want to add something at the top of your hookSave() function like: if(!$page->id) return; so that it doesn't get involved with pages that are about to be saved for the first time. If you use the "saved" hook (available in the dev branch of PW), this is essentially the same as what you are already doing, just a little safer, since it wouldn't get called if an error occurred in save(). Though for most practical purposes it's equivalent. I would probably look into using "saveReady" just because that could reduce what's currently happening in 2 saves to just 1.

Previously this worked in Firefox and IE, but not in Chrome/Webkit. However, if you are using the latest Chrome and the latest PW (dev), it now works there too (thanks to a recent update from Soma).

Thanks Diogo, I've corrected that. Those quick start tutorials were written by somebody that never finished them... and they were written back for the original PW 2.0, so I'm not surprised there might be errors in there. I need to take some time to go through these for QA, because I don't think the author is going to finish them. But people seem to like them... every time I remove them, somebody gets upset.

While they can't be included in an actual language pack (which is meant for translating the static text in PHP files), they can be exported as SQL dumps. The profile export module was written before multi-lang features existed in ProcessWire, and I need to update it to support it. But it should be fine to create your own SQL dump with translated field names, etc., and import that (via mysqli client, phpmyadmin, etc.) when needed.

It's worth mentioning that wire('input') or wire('any API variable') would in fact work everywhere. So if you only needed to remember one way of accessing API variables, that one would be the most portable.

Selectors have to have a defined value after the operator. There is no defined value in "modified>created", as those are two fields. You can go straight to SQL to accomplish this one: $pageIDs = array(); $result = $db->query("SELECT id FROM pages WHERE modified>created"); while($row = $result->fetch_row()) $pageIDs[] = $row[0]; $pageArray = $pages->getById($pageIDs); // $pageArray contains what you want

At the top, I'm thinking you want to add something to avoid acting on pages that aren't of your defined type. Something like this: if(!$page->template != 'project') return; Because this is a single-page reference field (from what I can tell above), I don't think this line would work: $page->project_status->remove(1157); That's calling the remove() method of $page, which just unset a value. Since the page likely doesn't have a variable named "1157", the line above essentially does nothing. What you would want to do instead is set project_status to be a blank value, or another page. $page->project_status = null; // this $page->project_status = $pages->get('some other page'); // or this