ryan

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.

Thank you for the offer! I figured I could code the back-end of this thing pretty easily once Form Builder has page publishing ability. But I'm still about 2 weeks away from that. If you or anyone else wants to handle the design and/or markup, that would be great, and help to get this moving forward more quickly. Also might be good to look at processwire.net as the wrapper template since it'll be coming into play very soon.

Also want to mention that you don't need to do the $pages->find(); because ProcessWire already provides you with a $users API variable. The $users API variable is like a special $pages API variable that only acts on users. Though unlike the $pages API variable, you can foreach($users).

This sounds like a good job for FormBuilder. Now I just need to finish the Publish to Pages capability, and it should make an easy job of setting up this directory.

Thanks for stopping by Mike -- this sounds great! I nominated ProcessWire yesterday. Do you need only 1 nomination per product, or does it require nominations from multiple people for consideration?

I'm happy to setup a subdomain, or even integrate it into the main site. It probably makes sense for it to be a section on the main site, like it is with ModX http://modx.com/modx-professionals-directory/ though not sure this is the right format for us.

Sure! Mike over at CMSCritic is a good guy and I'd support anything he's doing over there. I'd encourage anyone that wants to vote for ProcessWire in any of those categories to please do so! I know I will. My experience is these guys are pretty hard to get through to. I've personally talked to Eric Meyer and Jeremy Keith about ProcessWire and gave them a card with the URL on it. Even had lunch with Eric Meyer (he sat down next to me at an AEA event), and he's about the nicest person I've met. But I think he was relieved to talk about family and kids rather than webdev. These guys get hounded with everyone they meet telling them about their project, and it's pretty much all noise to them (as most of it probably should be). The mention of a "CMS" is especially noisy, as nearly every developer has dabbled into making their own CMS at one time or another. I'd venture to guess these guys hear about some new CMS almost every day. They make a genuine effort to act interested, but they really aren't. They need to hear about something many times, or from one they know really well, before they will take the time to investigate. Ultimately I'm just interested in making sure ProcessWire is the best tool of its kind. Whether its "known" or not is beside the point. Granted, I'd like to share it with as many people that will benefit from it as possible, but would rather let folks find it at their own pace. I think ProcessWire is a real competitive advantage for many (at least is for me), enabling us to get things done quicker and at less cost. So if everyone was using it, it'd be harder for me to get work.

Something like this might be good? http://director-ee.com/ I also think that the client's concern is more one of proprietary vs. open source. The client is wise to have a real concern if they are dealing with a proprietary software. If they are dealing with an open source PHP software, they are already ahead of the game in terms of insurance. But a network or directory like you guys are talking about can only make things better, so seems like a great idea.

Sounds good! Lets go for a pull request if it's convenient for you. Or just post the .module file and I can go through the diff.

I tracked down what the issue was here. I'm betting you have a field called 'notes' ? ProcessWire's form rendering was getting confused, since that is a reserved word to Inputfields. However, it was an easy fix, so it'll show up in the source in the next day or two.

Just got your pull request -- this is great, thanks for taking the time to help out with this!

This capability will be included in the first version, as I've now got it working. Here's a screenshot of a form configured to cross-post to Salesforce. When a form is submitted, it saves locally, emails to me, and then posts to Salesforce. Like many other services, Salesforce requires some extra variables in the request like "oid" (some sort of customer ID they use). They also use some of their own variable names, which you find when exporting a web-to-lead form there. In the screenshot you'll also see how to do these variable replacements. This same method can easily be used with other services like Campaign Monitor, Mail Chimp, etc. So we'll have this capability right from the beginning.

I actually have a site exhibiting this same behavior on my dev server right now, so already can reproduce. Just haven't figured out what's causing it, but not far off. As for your Textformatter module that won't uninstall-- likely it's not related to the other issue. Double check that your Textformatter module doesn't have "permament=true" in it's getModuleInfo() function at the top. If it does, remove it. If that's not it, then check that you don't have any Text/Textarea fields with that Textformatter module assigned to them. If they do, they will install the module themselves unless you physically remove the module's files.

It's not in the live source yet. I like to test things out locally for a day or two before I commit them to GitHub, just to play it safe. So I'll usually push several updates at a time.

Changing the fieldtype is non destructive in this case. For example, changing a field from Text to TextLanguage, or from PageTitle to PageTitleLanguage, will not wipe out what's currently in the field. However, if you do the reverse (change from TextLanguage to Text) then it would of course be destructive to all but the default language. When in doubt, backup your DB before making a change like this, so that you can always revert should you want to.

I'm not sure I understand that last bit of code: $random_images->images->getRandom() ? I guess it's that first variable $random_images that I'm not sure I understand what it is or where it came from. But if I understand the parts before correctly, then it seems like this is what you want: $image = $page->images->getRandom(); if($image) { echo "<div id='home' style='background: url($image->url}); width: {$image->width}px; height: {$image->height}px;'></div>"; }

Just added that optional options array to the size() function, so it should appear in the core this week. Currently you can specify: quality (1-100), upscaling (boolean), cropping (boolean). The position stuff will be added later. $image->size($width, $height, $options); You can also choose a default set of options and specify them in your /site/config.php: $config->imageSizerOptions = array( 'upscaling' => true, 'cropping' => true, 'quality' => 90, );

Thanks got it (sorry, didn't see it earlier). I've logged in and don't see any red flags. However, I did find something interesting. If you add the "debug=1" param to the URL, it works: /service-pages/?template=picture&debug=1 I can't find a reason for why it works with that and not without. I've gone through the code and nothing in ServicePages throws a 404. So it's really unclear where that 404 is coming from. I also tracked the live HTTP headers, and noticed that ServicePages "content-type: application/json" header never gets sent, meaning the 404 appears to be happening before the module is executed. Since this module has no initialization, I'm of the opinion right now that something else is interfering with the request. I've gone through your modules and don't see anything that appears to be a problem. The only thing you might want to try is temporarily switching back to the default admin theme, just in case there is something there. Though not sure how there could be, but give it a try. Next steps is that it may be good for me to get a look at your phpinfo(), and I can do further tests but probably need FTP or SSH if you want me to. I would modify the ServicePages module while doing the requests, which should give a much closer look at what's going on.

I've updated this with the suggested improvement, thanks for finding it.

There is some redundancy there, so you can shorten it up to this: foreach($page->photo as $image){ $description = $image->description; if(strpos($description, '@') !== false) { list($description, $link) = explode('@', $description); } else { $link = $img->url; } $thumb = "<img src='{$image->getThumb('thumbnail')}' width='50' height='50' alt='$description'>"; echo "<div class='single'><a href='$link' rel='prettyPhoto[gal1]' title='$description'>$thumb</a></div>"; }