ryan

I tried it out here (with the German language pack) and found a notice being thrown with the parser (when in debug mode). I went ahead and fixed that, but kind of doubt this would prevent it from working since the parser is only involved in the interactive translation process. German seems to be working on the dev branch here. Just in case, do you want to try and grab the latest version of the dev branch and try again?

You might also find this post helpful, which shows how to build a profile editor on your front end.

Someone recently made a module that integrates with another image editing service. It looks like they never submitted it to the modules directory, and now I can't find it… I need to track it down, as I recall it worked quite well when I tested it.

Pete, I think I may have this fixed. Though couldn't exactly seem to duplicate it here, but found something that looks like it could be responsible (some missing parenthesis). Would you mind trying again with the latest dev version?

The problem here is that resizeThumb()'s implementation assumes that one can construct the server path to the file from the URL (see the first line in that function). But the URL and disk path can be very different things. You may be able to fix it by replacing the first line in that function with this: $thumb_path = $field->path() . basename($thumb_url);

While I still can't duplicate the issue, I did find discussion of there being an issue (on PHP.net) along with ways to resolve. I think I've got it fixed, but was wondering if you could test the latest dev, whenever you get the chance? I also have added some things to the SessionHandlerDB module, so you'll want to un-install and re-install the module before testing (couple fields were added to the DB table). Thanks for tracking down the issue.

I have a feeling this is something to do with a behavior change between 5.2 and 5.3, I will do some testing in 5.2. It sounds like PHP is trying to revert back to file-based sessions with that session_start() call, based on the error you mentioned.

If you are doing this in a template file, better to use some name other than $page, just so that you don't overwrite the $page provided to the template. $p = $pages->get('/about/'); if(!$p->id) { // create new page, if not already there $p = new Page(); $p->template = 'basic-page'; $p->parent = '/'; $p->name = 'about'; // URL name } $p->of(false); // turns off output formatting $p->title = 'About SwimToWin'; $p->save();

This is incredibly useful! It is a great security option to have for sure. Thanks for making this. Very nicely done.

I think that the problem did exist in 2.2.3. The current version is 2.2.9. I bet if you upgrade to it the issue will go away. Let me know how it works for you.

I think we all like to answer questions here, but especially like ones that are easy to answer.

Thanks for the nice feedback. Good suggestion. It's pretty readable here, but tried it on my wife's computer and it was a different case. I'll try changing this to Arial or something. Sort of. I evaluated the information architecture and researched other school sites and came to the conclusion that what they had on their previous site was quite nice in terms of organization. The problem was that it was navigationally bad, which made it hard to wade through. The old site had a design problem, not an architecture one. On the new site the information architecture (and even the exact URLs) are consistent with the previous site for the most part. But the new site makes the information a lot more accessible.

Pete, these updates are now in the FieldtypeComments for the dev branch. Please try it out and let me know how it works for you. I've also added a 'website' field option to the field settings. After you've updated, you'll want to edit your comments field(s) settings to enable the 'redirect after post' option.

That's kind of you to say. But the truth is ProcessWire makes me more productive. If I have to code something outside of ProcessWire, it takes a long time and I'm not that productive.

The user needs some kind of administrative access in order to access the PW admin. Just having page-view permission is not adequate permission to access anything in the admin. Otherwise, any random visitor to your site could go browse through the page tree in PW admin. Maybe that's not a problem per se, but I don't like the idea of it.

Sorry Marc, I'm guessing I wrote the wrong thing in some other thread. If you know what post that was, let me know and I'll correct it. Teppo's code is correct.

Form Builder is one way to do it. But it's actually very simple to create pages anywhere in ProcessWire from the API. Here's a simple example: $page = new Page(); $page->parent = '/about/'; // or whatever parent you want $page->template = 'basic-page'; // or whatever template you want $page->title = "Test Page"; $page->body = "<p>This is a test, only a test.</p>"; $page->save();

Also, don't forget to enable page numbers for your template (Setup > Templates > your-template > URLs > Page Numbers).

Since these are API functions, you don't "see" the images, so center cropping is really the only safe way to crop without visual context. If you want to prevent any cropping from the API side, then you would just use the width(x) or height(y) functions rather than size(x,y). I also suggest looking at apeisa's Thumbnails module, which provides interactive cropping capabilities.

You'll also want to give your Editor role page editing permissions. You'll see these when you create the role. After you've done that, you still need to apply those page editing permissions somewhere. Go and edit the 'home' template (Setup > Templates > home). Click the 'Access' tab, and check the boxes for your new 'editor' role.

You can also edit your /site/config.php and locate the $config->debug line and change it to: $config->debug = true; That should put any generated error messages in front of you. Let us know what you find?

I'm really happy with photoswipe (originally recommended to me by Soma). It really duplicates the native mobile gallery experience beautifully. At the same time, it's quite a nice way to browse photos on non-mobile too (you can even drag the photos with your mouse). Example

Shouldn't be a problem if its generating a thumbnail. The update is really meant to be as transparent as possible. Here's what's happening with the protected files: Originally you have a URL like this, which is a direct link to the file: /site/assets/files/123/file.jpg When it becomes protected, ProcessWire renames the "123" part to ".123", which according to PW's htaccess file makes the directory blocked from http. (I will probably change this to some other strategy, because directories with periods at the front might be skipped by FTP clients and such). The new link for the file becomes: /path/to/page/-/file.jpg, a URL that will be handled by ProcessWire rather than pointing directly to the file. (the "/-/" part is configurable... it could be "/files/" for instance, if you preferred it). When PW sees that unique URL segment "-" or "files" (or whatever), it first checks that the user has access to the page (/path/to/page). If they have access to it, then it checks if the requested file exists in /site/assets/files/.123/file.jpg. If it exists, it sends it to a passthrough function which outputs the file. From the perspective of the API, you should not have to make any adjustments in how you work with it. Your code doesn't even need to know that the file is protected. It should all just work without side effects. However, if you are generating your own URL to the file (rather than using the one PW provides) then that won't work, because not only does the "123" directory no longer exist, but the new ".123" directory is not even http accessible.

Great module! Post please post to modules.processwire.com at your convenience.

Thanks again for this feedback, really makes me smile! One issue I'm running into with TypeKit on the site is that I'm getting an FOUC (flash of unstyled content) when viewing the site with Firefox (latest version). Not seeing it in any other browsers. I'm assuming its got something to do with TypeKit since the the unstyled content is specific to the typogrpahy. Is anyone else seeing this, or does anyone know how to correct it?