Leaderboard

renobird, I think what you would want to do is just simply delete the image first (if there's one) and add new one. you should be able to do something like this, though you would have to try out. if(count($user->image)) $user->image->delete(); ... Edit: ...ok maybe not exactly, but looking at api i'll try a moment... Edit: Ok this works: if(count($user->image)) { // if already 1 image $img = $user->image->first(); // get img $user->image->delete($img); // delete it $user->save(); // save user page $user->image = $config->paths->root . "P1000774.jpg"; // add new image $user->save(); // save again } else { // if no image yet just add one $user->image = $config->paths->root . "P1000774.jpg"; $user->save(); }

Not sure if this has already been suggested, but for the less php literate among us it would be great to have some sort of repository of php scripts on the PW website for formatting template data, i.e. the php snippets for outputting different kinds of menus, breadcrumbs, bloglists, etc. Similar to a database or list of modules, but specifically for the templating side of things, where you don't require a full-on module. Right now you have to scour the forums (or write your own code) if you're looking to do something beyond the basics that are included in the default templates.

Hi all! I'm just trying out the new columns feature for fields, and it looks awesome!!! This really streamlines the editing process, congrats! But I found a problem, don't know if it's a bug I've attached an image, so it's pretty self-explanatory: On the template side I am using two a 50+50% fields and below it a FieldSetTabOpen with other fields in it. Removing the FieldsetTabOpen from the template solves the problem, so I guess there's something funny when ending a fieldset with a float and following it with a Tab. I hope it helps you recreate the issue!!

Hi landitus, Are you using the latest version available? I remeber this issue was fixed already.

This issue has been fixed in the latest commit (fix issue #94)

I wanted to add a note about exceptions on the front end. If you want to abort a request, throw a WireException: throw new WireException('your error message'); That message will automatically go into the errors.txt log and email the site administrator. If the site is in debug mode or you are a superuser, it will report the error message to you as well. If not debug mode and not superuser, the user will get a generic "an error occurred, administrator has been notified" message. Another exception you can throw is the 404. This will make PW display the 404 page (from your site tree) and send the proper 404 headers to the browser. PW doesn't interpret this as an error that needs to be logged or emailed. throw new Wire404Exception('page not found'); This is the exception you might want to throw if you get an unrecognized URL segment, for instance.

Marc, when you are developing a site it's good to turn debug mode on. This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true; Obviously you don't want this enabled for production sites, so remember to change it back to false for live/production sites. I don't see any problem with using var_dump, var_export, print_r, etc. so long as you are directing that output to where you can see it. Also avoid running these functions on PW objects as you may get into an infinite loop. Sometimes it can be difficult to track the output of these functions because PW performs a redirect after most POSTs. But if you use PW's built-in reporting functions, they will get queued between requests until they are output. Here are the relevant functions bellow. They will produce the messages that you see at the top of your screen in PW admin: $this->message("status message"); $this->message("status message that only appears in debug mode", Notice::debug); $this->error("error message"); $this->error("error message that only appears in debug mode", Notice::debug); If you are outside of a Wire derived object, you can call upon any API var to handle the notice for you. For example: wire('session')->message('status message'); wire('pages')->error('error message'); Note that these reporting functions above are for the admin (and related modules), and they don't do anything on the front-end of your site. How you choose to debug or report errors on the front-end is at your discretion. Personally, I keep debug mode on in development, and this puts PHP into E_ALL | E_STRICT error reporting mode... it reports everything possible. If I need to examine the value of something on the front-end, I'll do it the old fashioned way with just PHP. Though others may prefer to go further with their debugging tools. If you want to keep your own error log, here's how (anywhere in PW): $log = new FileLog($config->paths->logs . 'my-log.txt'); $log->save('whatever message you want'); You can direct it to store logs wherever you want, but I suggest using the PW logs dir as shown in the example above. This will make the log appear in /site/assets/logs/, and this directory is not web accessible for security.

I think I slowly gettin the problem you're running into with this approach. How you're assuming the page field on the "Categories" is named? It works only if you name them always the same as the page that holds the field selected in "instances". So you chose the strtolower($fo->title) to be the field name for the inner foreach, the last one. Instead you would require to do another page select on the "Categories" page to define what the field is called on itself. But I wouldn't want to go as far. Also you added the $fo to the $fielddata before the last foreach, that's why it got prepended. So you add it and at the same time you say you don't want it to be added. Or I'm missing something? Also you could (assuming they're always pages to return) make $fielddata a PageArray and store (import) the pages in there to return. That also kinda shows you're not really returning fielddata but page objects. I'm still not sure about this approach, if there's an easier way or should be done differently.

I think i know the issue... kinda wild tho - not sure if it's a buffering limit or what... as i'm on my localhost.. (shrug). Its when I do var_dump of the 'children' objects, etc.. any time i seem/tend to dump that to the screen, then i'm seizing up the system, and it gives me the 'white-wall-of-doom!' When i remove it, ir do the var_dump on anything else (obviously smaller than the children object array, etc...) it's all fine. Bill p.s. er so it seems

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)

I think this is more likely to be a component of the 2.3 version with form builder. However, I don't think you need to wait for that. I would say to build something custom for your need, because this isn't particularly hard to do. When you are dealing with image uploads, you'll want the original uploaded image to be placed in a non-web accessible quarantine location. Then after confirming that it is indeed an image (by checking the extension and using php's get_image_size() to confirm it's valid) then you'll want to use ProcessWire to create a resized copy of it (using the ImageSizer class in /wire/core/). To the best of my knowledge, the resized copy is safe to be web accessible (i.e. okay to add to a page). Once you've done that, delete the original one that they uploaded. At this point, the main concerns would be copyrights (who owns the imagery) and content (inappropriate imagery, if applicable to your case).