ryan

When a page is saved, there are various things that can happen that can modify what gets submitted. For instance, hooks can modify stuff. So it's important that a fresh copy gets loaded after a save. Maybe not as convenient, but ultimately opens up more flexibility.

I think this is the first time I've seen ProcessWire (and the LanguageSupport module) used to deliver content in Chinese. Nice to see.

I can reproduce this too. This is a bug, as it should allow a page named "0". Sn4ke I think you are right, that there is likely an empty() check somewhere there should be a !strlen() check. Unfortunately I can't seem to find where it is yet, so going to add this to the issues list until I've got more time to get deeper into it. Btw, the error message you got is actually something different, and I have fixed that. The actual error message is "Can't add because that page already exists."

Try outputting this, right before your find() and let me know what it says: echo "<p>Language: $user->language</p>"; What languages do you have installed? (how many?) If you try switching the language, do you get a different error or no error?

Definitely -- anytime you need something to be hookable just edit it, precede the function with the 3 underscores (to make sure it does what you want) and then let me know and I'll update the source to have it hookable. This is possible in most cases. Occasionally, there will be function that is used so much that making it hookable would be an overhead concern, but there's very few of those.

I would probably be worried about duplicate content with this approach. You could use the rel='canonical' meta like Soma mentioned, but it's still not ideal ... could be an unnecessary headache for redirects and future iterations of the site. Also might add some new challenges to statistics tracking. It's kind of going against the flow of how URLs work, but if you are okay with that you certainly could do it in ProcessWire. Since you are wanting to eliminate /articles/, which is a root level page, your homepage would have to be the one allowing URL segments and detecting when they are present. Your generation of the article URLs you asked about would go something like this: function articleURL(Page $article) { return '/' . $article->category->name . '/' . $article->subcategory->name . '/' . $article->name . '/'; }

i agree that you should install the comments manager module. But want to make sure I understand what's not working, as you should be able to edit comments from the page editor. Double check that you are running a newish version (2.2.7?) and maybe check your JS console to see if any JS errors are occurring? Let me know if you think there's a bug in there... I have tweaked a few things in the comments recently.

From the caching side, you can always use the MarkupCache module to cache your own stuff. But you just have to be careful so as limit the possible pages that can be rendered. Unbridled caching of pages generated as a result of values in GET vars is a bit of a security hole, as someone could take advantage and make you end up with millions of cache files, potentially filling up the disk or slowing things down. This is the reason why PW doesn't support caching of output generated as a result of URLs with GET variables.

Must be another system?

These are really awesome Soma! I also think it's priceless that the Swiss guy here is making watches… in javascript.

The intention is to keep things in a well known set for security, but also so we have consistency with ProcessWire's pageName filters. GET variables?

Have you tried putting in the name attribute as "userfile[]" rather than "userfile" ?

I would probably set the visibility of that field to "not shown in editor". Rather than have your hook try to adjust attributes of a field, just have it display a message: if($page->your_checkbox) $this->message("User is logged in"); else $this->message("User is NOT logged in.");

It depends on the file system. In a common ext3 with dir_index file system there is apparently a limit of 32k subdirectories per directory, and no practical limit on quantity of files in a directory. In a common ext4 file system there apparently is no limit on subdirectories or files, but a maximum individual file size of 16 TB, so be careful.

Adam actually that wouldn't work because find() returns a PageArray, not a Page. So you'd have to do find(...)->first()->id, but a better way would be to just use get() rather than find(): if(wire('users')->get("email=$username")->id) { // ... }

None of the Inputfields actually support the disabled attribute. When I use it, it's really only for the visual and nothing more. In this case, you are getting the message because the guest role is required and its just adding it back. It's an unnecessary message, though is revealing exactly what you've mentioned (disabled attribute isn't actually supported). Seems like it would be worthwhile to make all Inputfields support eventually (and probably easy to do), so will add this to my list.

Welcome to the forums briangroce. I've begun to understand WillyC's language, but it's taken awhile. I think what he was trying to say is that you need to use $l->files->path(); as a function (method) call, and not as a property. Though that's a good reminder to me that I need to make it work as a property too.

Thanks for the interest Marty. It's pretty much ready, so should be next week.

Might have just found it: the getVariations() function in /wire/core/Pageimage.php calls setFilename() with a non-normalized path from DirectoryIterator. Though still not clear why the $file->getPathname() from DirectoryIterator would be returning a file in the format with both types of slashes (/path/to/file\file.jpg). But that bit of code in Pageimage.php is a problem either way, as it doesn't consider the slashes and it needs to. Luckily an easy fix.

Thanks Steve. We normalize to forward '/' slashes internally, and I normalize them as soon as anything comes from the OS (see /wire/core/Paths.php). I don't think that function is involved in this particular case, but like you pointed out, that function does assume it's dealing with paths in an expected format that have already been normalized. The setFilename() function also assumes it's dealing with filenames in an expected format, so that extra slash must be finding its way in there before the function call. What I'm looking for is any native PHP that would return a path, like a DirectoryIterator loop where maybe I'm doing something like in that function you pointed out -- a trim($dir, '/') rather than a trim($dir, DIRECTORY_SEPARATOR). So far I haven't found it, but the hunt is on.

In your field settings, for your TinyMCE advanced settings under "theme_advanced_buttons1" you currently have this: formatselect,|,bold,italic,|,bullist,numlist,|,link,unlink,|,image,|,code,|,fullscreen Try changing it to this: formatselect,|,bold,italic,|,bullist,numlist,|,forecolorpicker,forecolor,|,link,unlink,|,image,|,code,|,fullscreen Note I added "forecolorpicker" and "forecolor". They are two versions of the same thing, so you'd probably remove one or the other after trying them out. Also google them and it should bring up something at the TinyMCE site for other color picker options, like one that would handle background colors. These are just the two that I know off the top of my head. Next in your "valid_elements" setting, you'll want to enable use of the "style" attribute. I won't post the full valid_elements because it's quite long, but here is just the first part as it would appear currently: @[id|class] You'll want to change it to this: @[id|class|style]

joe_g or DaveP -- can you try replacing your /wire/core/Pagefile.php with the file attached, and let me know if it corrects the issue? Pagefile.php Thanks, Ryan

Soma is right in his suggestion, but chances are that your "non-object" error came because you tried to do it on a page with no images. Thus, first() returned null and you tried to call size() on a non-object. So you'd want to do something like this instead: $productImage = $product->wcart_image->first(); if($productImage) $productImage = $productImage->size(80,60); or this if(count($product->wcart_image)) { $productImage = $product->wcart_image->first()->size(80,60); }

I agree about Recaptcha. It's rare that I don't have to reload the recaptcha several times before I find one I can take a guess with. Though sometimes I get lucky. But I've even had to abandon forms due to being unable to solve the recaptcha. The state of recaptcha makes me wonder if the whole captcha concept is becoming obsolete.

WillyC's solution is a good way to go if you have this need. But want to mention that the whole idea of multiple routes to a page kind of goes against the grain of the ProcessWire philosophy. By design, there is only one URL to any given page. This is different from systems that disconnect their data from URLs (Drupal, EE, etc.). ProcessWire considers pages like files on a file system. We are trying to embrace the way that the web is addressed rather than counter it. I understand the desire to make a shorter URL for a given page, and that's a fine reason to implement a solution like this (and I've done it myself too). But the reason you don't see things like this outlined in the documentation is because I don't think it's a best practice, whether in ProcessWire or on the web in general. So if someone uses multiple routes, I would suggest it only to solve a specific need after a site is produced… not as something to build around from the start.