ryan

Juan, we definitely need help with a real Spanish language pack. I don't speak Spanish and have no idea if the one I was working on is even remotely close to how it should be (I'm guessing it's not). I mainly started with a Spanish language pack because my wife speaks a little Spanish and I thought I could impress her. But I don't think she knows Spanish well enough to critique my language pack anyway. If you would be interested in making one, your help would be greatly appreciated! I'll be happy to send my latest Spanish language pack files over to you if it's helpful to use that as a starting point. Thanks, Ryan

Soma this sounds like a different issue than userAuthSalt, because you could expect to see an error message if the authentication was failing. If you aren't seeing any errors, then it sounds to me like there's a flow control issue with the Process module. Can you paste in the exact URL that appears in your address bar when you are on the login page? Is the URL that appears after you submit the form exactly the same? Also note that the URL should always end with a slash here. The only other thing I can think of: have you possibly turned on template caching with the admin template? (I doubt it, but just checking).

Michael, have you tried changing your dates in the CSV to the d-m-Y format? I believe it should import then. The FieldtypeDatetime module sanitizes any string input with PHP's strtotime() function. That function accepts d-m-Y format if you use dashes in the input (rather than slashes).

I shouldn't be angry with WordPress, as this TimThumb plugin is something completely separate from it and like you've mentioned, common in several other CMSs too. But there just seems to be a never ending supply things that can happen in WordPress like this. I suppose that's due to the popularity of the platform more than anything else. But even if it's not the fault of WordPress, I always worry about the clients that I have using it.

Nice work Achabany, this looks great. I will aim to get a similar look with the module.

I just lost the better part of a day fixing a client's WordPress installation that had been hacked, turning their web sever into an IRC file distribution hub, a DDOS farm and peppered with exploit scripts all over the place. Despite running the latest version of WordPress, apparently the site theme had a plugin (TimThumb) with an exploit that lets folks turn your server into a playground. Thankfully the hackers that did it weren't malicious and didn't want anything with the sites on the server, just the resources and bandwidth. So the site never had to come down, though the server load and bandwidth usage was through the roof for a couple days. This may be old news for some, but I don't use WordPress much. If any of you are running WordPress anywhere, do yourself a favor and scan for TimThumb, even if you think everything is up-to-date. I did it like this: grep -r allowedSites wp-content/* If it turns up files like timthumb.php or thumb.php (or anything else), double check that they aren't vulnerable. Here's some more info: http://www.exploit-d...b-exploitation/ http://markmaunder.c...rdpress-themes/ http://wordpress.org...bility-scanner/ While you are in your site files, do this grep as well: grep -r base64 ./* A lot of the scripts that I had to remove today were base64 encoded and eval'd, and this helped to track some of them down (among other searches). This will turn up some legitimate WordPress stuff too, but it's relatively easy to tell the difference. Assuming TimThumb was their entry point, they did a good job of hiding it. All the exploit code was elsewhere in other themes, plugins, cache files, hidden directories and more. Since I lost so much time to WordPress and this issue today, I just wanted to post it in here in case anyone else runs into the issue. I'm just hoping I found everything...

Actually LanguageSupport includes a setLocale setting, but it needs to be defined with the language pack. If you go into Setup > Languages > [your language] > add translation file > Then paste in: /wire/modules/LanguageSupport/LanguageSupport.module You'll see a field come up where you can set the locale. Maybe I should have this disabled by default? (if the translation doesn't define it)

Of course, but PW doesn't get involved in this stuff (it does no JS output on it's own for the front-end of your site). But you can add on whatever JS functionality you want to it.

We've got a queue of changes and improvements planned for the Comments module, and improvements in the area you've mentioned are part of it. The comments output/processing comes in two parts, $page->comments->render(); and $page->comments->renderForm(); Usually you call renderForm(); after render(), which means that the comment form doesn't get processed until after the list of comments has already been rendered. Of course, you could reverse that and render the form first and then get your comment in the list. But that doesn't solve the double post issue, which we really need a redirect to do. So the recommended way to handle it now is to $session->redirect('./'); after a comment is submitted. ProcessWire can't do this for you just because it doesn't know if you are calling upon it before or after you've started output (depending on the way you structure your templates). So it's playing safe by not attempting any redirects and instead lets you maintain control over how you want it to proceed. // get comments before any output sent $list = $page->comments->render(); $form = $page->comments->renderForm(); if($input->post->text && strpos($form, 'success')) { $session->redirect('./'); } // ... later on when you are sending output echo $list . $form; More here: http://processwire.com/api/fieldtypes/comments/ Also note the default behavior and markup created by the comments module was always intended as just an example. It's meant to be iterated and handled like pages are, where you make your own comment markup and form. But I usually go the easier route and just use the built-in 'example' output.

Thanks for the kind feedback Wortell. Glad you are enjoying ProcessWire and thanks for your interest in contributing too--always welcome and appreciated.

The default profile is meant as a clean starting point, though it's also not completely blank. For me, it is at least a much better starting point than nothing, but i know others may prefer something even less. In ProcessWire, you can't have a completely blank stating point because some built-in pages need templates and fields (like admin, home and 404). But here's how you can get to a more blank state: 1. Open the 'trash' page in the page list, then click 'move' to drag these 4 pages to the trash: /about/ /templates/ /sitemap/ /search/ Then empty the trash. This will leave you with just your homepage, 404 page, admin, and trash … all of which are required in any PW installation. 2. Now you want to go to Setup > Templates. Delete the 'sitemap' and 'search' templates, unless you want to keep either one of them. Edit the 'basic-page' and 'home' templates and remove all the fields except for 'title'. Save. 3. Go to Setup > Fields, and delete all the non-system fields except for 'title'. 4. Delete all the files in /site/templates/ except for admin.php and home.php. Following that, you are starting from the most blank state possible in ProcessWire. Now start creating your own templates and fields, and note that you'll very likely be re-creating the fields you just deleted --they are fields that tend to be needed on most sites. That's why I think it's a little better to start with the included profile and rename/replace things as you go--it saves time.

I just tried to reproduce it here, changing my memory limit to 16M and restarting apache. Everything seemed to run fine at 16M. Then I tried again, except this time changing it to 8M -- then I could get memory errors. While I couldn't get memory errors at 16M, I'm guessing it just depends on your PHP version and perhaps other factors on the server. But I agree that 16 or 30 is probably just too low. 32M would probably be the minimum I would use. The default PHP 5.3 setting (128M) is ideal. If you are using PW for large data imports and such on a dev server, you might even want to go higher (the higher the limit, the more pages you can hold in memory).

Apeisa is right. Change this line: .CommentForm_text { clear: both; } To this: .CommentForm_text { clear: left; } I will update that in the basic profile (thought I had, but now see I didn't).

Jan, thanks for letting me know about the error. Do you have a calendar URL I could test with to reproduce it? Feel free to PM to me if it's something you don't want to post publicly. I'll be happy to fix this and update the source code.

page-view permission is supposed to be required of all roles (i.e. an implied permission). Though in testing, I see that it's possible to create a role without giving it page-view permission -- that's a little bug that needs to be fixed. There aren't supposed to be roles without page-view permission just because they wouldn't be very useful. I'll add in some extra code to force this permission to always be present.

I agree with Pete. This sounds like you are accessing type 'Pageimages' rather than type 'Pageimage' (singular). Since you are bootstrapping ProcessWire, output formatting is going to be off. One of the side effects of that is that all image fields are treated the same (as arrays of images) rather than single images. Since you are using ProcessWire's data for output in this case, I suggest adding a single call to this before you retrieve any pages from PW: wire('pages')->setOutputFormatting(true); That will turn it on for all anything returned from the $pages API var. Or you can do it for just one page, like your banner $page: $banner->setOutputFormatting(true); Turning outputFormatting on will ensure you get the correct behavior for output. And if your image field is set to hold max 1 image, then it'll also ensure you only get that when accessing $banner->pastilla_imagen.

Okay that settles it, I will plan to rename it before we send out 2.2 press releases.

Arjen, Thanks--Let us know how it goes.

Thanks for posting about this BeavenLawrence. I didn't know about these tools, definitely good to know about.

You should also be able to do this: $p->sortfield = 'v_candidate_number';

ProcessWire doesn't allow direct execution of PHP files in its /site/templates/ directory for security. So what you'd want to do is place your ajax PHP file somewhere else, like in the site root or under some other directory that you've created. Then include ProcessWire's /index.php to bootstrap it: /somefile.php <?php include('./index.php'); // bootstrap ProcessWire if(wire('config')->ajax) echo json_encode("Hello"); When you bootstrap ProcessWire, it'll work the same as it would from your template file, except that you have to access the API variables through the wire() function, i.e. wire('pages'), wire('config'), etc. More here: http://processwire.com/api/include/

I will check out that WordPress plugin you mentioned. I think this is a good idea for a ProcessWire module, but probably not something for the core modules just because this seems like more a function of hosting, backup utilities, cron jobs, rsync, etc. The same tools we've always used for this. But one can never have too many backups ... more backups and ways to backup are always good (so long as they are secure).

Arjen, I think that ProcessWire will do exactly what you are looking for here quite easily. For your news page relations, I would echo what Antti said and suggest using either PageListSelect/PageListSelectMultiple or PageAutocomplete. Neither of those are affected by quantity, so will remain fast in the page editor regardless of how many potential page relations there are. Quantity of selected page relations is also unlikely to be a problem. When you load a page, PW doesn't load the data for that page (except for fields where the 'autojoin' option is used), so typically a page will only load with it's 'title' field. It won't load others until you specifically ask for them, like $page->body. In this manner, you can be working with hundreds of pages in memory without much worry of slowing things down. Though this is all behind-the-scenes stuff, and not something you usually need to think about. PW will make you think all the data is loaded and ready to use, but it stays selective behind the scenes to make sure it's never loading stuff you don't need at the time.

Thanks for reporting back, glad that you got it working!

Those DatabaseQuery classes are primarily so that the Fieldtypes can talk to PageFinder to construct an SQL query more abstractly. But for any situation where queries aren't being passed around to different classes, I prefer to write the query rather than abstracting it. PW isn't trying to introduce a new database layer. The database class is just PHP's mysqli with some debug logging options. For the most part I love the tools that PHP provides and don't like too many extra layers. Btw, the code sample I posted should only result in 1 query (assuming 1 page). When you say lots of queries, that makes me think you are constructing a tag cloud from lots of pages (?). You can always reduce queries by using the 'autojoin' option with a field, or by using a FieldtypeCache. But if you know how to write efficient database queries, then that will always be the fastest. Though also want to mention that it's futile to measure anything by quantity of queries in MySQL... it will execute a few hundred simple/optimized queries a lot faster than just 1 complex/unoptimized query. I used to try really hard to keep queries to an absolute minimum. But have since learned that from a performance standpoint, there are many situations where more queries will make things go faster, not slower. So measuring things by time is a lot more useful than measuring by query quantity.