ryan

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>"; }

Agree with you. I'm planning to use the same purchase options as Gravity Forms, which does include a Developer license with use on unlimited sites.

Thanks for finding this, I have updated the code. Most likely it's been there since the beginning, as there haven't been any recent changes to the code in question. It can be challenging dragging a page to be the first child of another, and might take a couple tries. Keep at it and you'll get there. Admittedly I struggled with getting all the movements right on this action in particular, and found we might be pushing the limits of what jQuery UI draggable/droppable was wanting to do. I'm not sure how to improve that particular action, and it might take someone looking at it that is better with Javascript than me. One alternative is to edit the page you want to move and change the parent from its settings tab.

Loaded fast for me … felt the same speed as any other fast site. There is a nice plugin for Firefox called YSlow (or something like that) that can help with debugging this stuff. But I'm not convinced Google is right about the load time.

I've done something like this before and just ended repurposing the image description field to store the external link URL. But if you want to be able to have both a description and a link, then you would put both your description and URL in the field, and just be consistent with how you put in the URL so that you can easily parse it out at runtime. For example, lets say you decided that you would always put in your description first, and follow it with the text "@http://domain.com/" (using the '@' to indicate to yourself it's a URL), so a full description might look like: Then you might parse it out at runtime like this: foreach($page->photo as $image) { $description = $image->description; if(strpos($description, '@') !== false) { list($description, $link) = explode('@', $description); } else { $link = ''; } $out = "<img src='{$image->url}' alt='$description'>"; if($link) $out = "<a href='$link'>$out</a>"; echo $out; }

Yes, this will definitely be coming if the Form Builder is sustainable. Unlike other Inputfields, the File/Image Inputfields in ProcessWire require a $page to operate. I'll have to build custom file Inputfields for use with the Form Builder. However, the bigger issue is just the security. Anything that lets a user (especially an anonymous user) upload a file to a server is a huge security consideration and a lot of responsibility. I'll probably spend a month just on developing that and ensuring that it's absolutely bulletproof. I don't want to hold up the rest of the Form Builder just for file support, so decided to tackle it after the product is out there and confirmed I can afford to take the time off my regular job to really build it well. Because of the environment of this input (anonymous, public facing) the approach just has to be very different from the file inputs in PW's admin. We actually do support rich text, but indirectly. It wants you to specify what page and field to pull the success text from. So basically you would create a "thank you" page in ProcessWire and populate the body field with everything you need. Then in the Form Builder, enter "/path/to/page/:body" for your success text. However, there's a better option: Use the success redirect option instead. That way it redirects to your success page which can contain whatever you want. When using the frame-based embed options, this is preferable to having the Form Builder output any success message for you. That's because Form Builder is running from a template that may not be consistent with your site's type styles. So you can get around that just by doing a success redirect. To use the redirect option, just specify the /path/to/page/ in your success text (and nothing more). Good idea, I'll look into this and plan to implement.

Anything in TinyMCE text is pretty much raw HTML, so I've tried not to introduce any other factors into that in order to ensure the portability of the content. However, the PageLinkAbstractor module (soon to be replaced by LinkMonitor) does convert them to/from page ID references, so that links don't get broken when you move a site to another subdir or move an individual page. The disadvantage of PageLinkAbstractor/LinkMonitor is that because the link data is then abstracted, your content is no longer portable. If you ever uninstall the module, any links it has abstracted will then be broken. There's also a small amount of overhead associated with converting links to/from abstractions on the fly, but I think it's a worthwhile compromise for most. You might also want to look at the PagePathHistory module (included with the PW core). This keeps track of page moves and maintains redirects when a page is accessed at an old URL.