ryan

I think the problem may be $entry->images->profile. The "->profile" portion of that doesn't match up with any ProcessWire 2 syntax (though would have in ProcessWire 1, but thats years ago). Where is "profile" coming from? If your image field is actually named "profile" then you should be referencing $entry->profile. Or, if your images field is literally named "images" then you would access it by $entry->images. Also the code examples you attributed to me are different enough from the ones I posted that I don't understand them. Based on the examples you are posting, I'm guessing maybe what you want is instead this? $width = 100; $height = 100; if($page->profile) { $thumbnail = $page->profile->size($width, $height); echo "<img src='$thumbnail->url' alt='$thumbnail->description' />"; } The code example above assumes 'profile' is the name of an image field set to contain a max of 1 image. If you want it to contain more than 1 image, then you'd need to adjust the code example to pull one image from it, like: if(count($page->profile)) { $thumbnail = $page->profile->first()->size($width, $height); // ... } If I'm on the wrong track here, us know exactly what you are trying to do (without code examples) and we should be able to reply with a code example of how to do it.

I got a response from the Redactor people. The response was: That's basically what I thought. They say they "allow" it, but the problem is the GNU license doesn't. He didn't say anything to indicate an understanding of the GNU license. The liability falls on to the developer that's integrating with GNU software. I'm continuing the email conversation with more questions to get more clarification. But so far it seems to me like we'd have to build this as a commercial module in order to keep control over the distribution. That's fine, but would just mean that TinyMCE would have to continue as the default wysiwyg editor in ProcessWire, with an option to replace it with a commercial module.

Users don't represent viewable pages on the front-end so you may want to connect them with some other template by way of URL segments. i.e. $username = $sanitizer->pageName($input->urlSegment1); if(empty($username)) throw new Wire404Exception(); $page = $users->get($username); if(!$page->id) throw new Wire404Exception(); // prevent superuser or users that don't have a specific role from being viewed if($page->isSuperuser() || !$page->hasRole('some-role-you-want')) throw new Wire404Exception(); $page->of(true); // now you can continue just as if this were the user template // as $page now represents a user As for finding users by role, try adding "check_access=0" or "include=all" to the selector. Those user pages are going to be protected from normal access, so adding one of those to the selector makes them accessible to the find().

If I understand the question correctly, you indicated "new ProcessWire sites" in which case you should check out the Site Profile Exporter to create your own starting profile to use instead of the included Basic Profile.

If you aren't using Apache, just double check that ProcessWire's files are protected. You should get a 403 "Forbidden" error if you try to access URLs like this: /wire/core/ProcessWire.php /site/templates/basic-page.php /wire/modules/PageRender.module /site/assets/sessions/ This is just a random sampling of URLs to test. But if you don't get a 403 Forbidden error for those URLs, you've got a major security problem then needs to be addressed with the server's rewrite engine. This is the main thing I worry about when people use web servers other than Apache.

Anyone interested in working on this module (or starting a new one)? Looks like it's going to have to start from scratch, or at least close to it. @diogo Regarding Zend_Service_Twitter, is this the sort of thing that requires installing the whole Zend framework, or can the class function without too many dependencies?

Looks good, thanks for your module submissions geniestreiche.

I will add it to some more pages. But the reality is that the ones rated above us will likely remain rated above us simply because their audience sizes are a lot larger and they've been around longer.

Version 0.1.6 is actually the latest, but the differences between 0.1.4 and 0.1.6 are just specific feature additions rather than bugfixes or the like. I've updated your access so you can download it from the Form Builder support board (thanks for your order!). The error you got occurs if a form render is called and there's nothing there. Check to make sure you have at least one field in that form. If that still doesn't do it, let me know what your form builder easy embed code is? Double check that the form name in your embed code matches up exactly with the one in your form settings (must be all lowercase too).

Wow that really sucks of them to do that. Kind of takes Twitter out of the web site integration picture doesn't it? Seems like a major branding loss for them, as people will migrate to other solutions to do the same thing. That is, unless this server-side authentication is feasible... I have no idea what's involved there, but glad to implement it for this module if it's not a major hurdle. Anyone worked with this before?

This is about javascript rather than PW, so don't have tutorials about this specifically. I think what I mentioned should work, but it's just a matter of debugging to find out why it's not working. Where I would start is to just get it working with hard-coded URLs. Meaning, if your arrow-up.png file is in /site/templates/scripts/js/img/arrow-up.png, then hard code that location and see if it starts working: .scrollUp({location:"right",image_src: "/site/templates/scripts/js/img/arrow_up.png",wait:100,time:300}); Also make sure you have a javascript console open (like in Chrome: View > Developer > Javascript Console), as it's nearly impossible to debug this kind of stuff without a console to tell you when an error occurs.

Interesting, I didn't realize we didn't have those implemented for FieldtypeComments, but you are right. We've already got the fulltext index there to do it, so definitely need to add this support. I have added it and will test locally before pushing to the dev branch.

That's right, if you are using URL segments for something else, then that use would have to be considered by your language gateway. If the page you are rendering has a template that is also looking for URL segments (perhaps for some other purpose), then you could set them manually: $input->setUrlSegment(1, 'something'); $input->setUrlSegment(2, 'something-else'); // and so on This one would be even simpler: $input->get->some_variable = 'some-value';

The fonts in the logo are Avenir (Process) and Mahalia (Wire). The Avenir is either the Heavy or Black weight (can't remember which).

I think it might be a fairly major change to the PW core to make it work with uppercase characters in URLs built on page names (though not 100% certain). But I think there are a lot of good reasons to normalize the case for URLs, so it's a change that might not be ideal for the larger system. Obviously those reasons don't apply to a URL shortener, and I can totally see the benefits for the URL shortener. The best way may be to have some kind of translation system in place where an underscore preceding a page name means the following character is uppercase, or something like that. Then your module's __construct() method could modify the value of $_GET['it'] before PW gets to it, i.e. if(strpos($_GET['it'], '/r/') === 0) { // if URL matches the format you are looking for // replace uppercase character with the lowercase version preceded by an underscore $_GET['it'] = strtolower(preg_replace('/([A-Z])/', '_$1', $_GET['it'])); } Btw, that $_GET['it'] is set by your htaccess file and it's where ProcessWire looks for the URL from Apache's RewriteEngine. It's nothing more than the currently requested URL. Another thing I want to mention is that there is no lowercase restriction with URL segments. So if you had your LinkShortenerHome.php template allowing URL segments, you could do something like this: if($input->urlSegment1) { $name = strtolower(preg_replace('/([A-Z])/', '_$1', $input->urlSegment1); $p = $page->child("name=$name"); if($p->id) $session->redirect($p->full_link); else throw new Wire404Exception(); } Also using URL segments, Another alternative is that you could just use your own custom text field to hold the short link (using upper and lower), and just let the page name take on the page's ID or something that wouldn't crossover with your short link names. Another idea, but maybe for a future version. If you wanted to handle short links right from your homepage rather than /r/ (which would further shorten the URL), you could hook in before Page::render when the $page->id is 1 and have your module check if there is an $input->urlSegment1 present.

These should be in the dev branch. I've got a lot going on in that branch, and thinking we'll merge it all for 2.3.

Thanks for posting this Philipp--nice site, and nice to hear about the switch from Typo3 too!

Thanks Alan, that looks like a good letter. I had a little trouble figuring out how to contact them, so sent to their support email address. If I don't get a response, I'll try to contact them via Twitter.

Hmm that's a good question, I've not tried to do that before. Though as a general thing, I think it's good for a module to uninstall everything that it installs. Is there a situation where you think someone uninstalling would want to leave those things there? If there is, then it might be better to take the strategy of uninstalling nothing and just include manual uninstall documentation. But if you think it's worthwhile to have something more, I'll keep thinking here. Right now I don't know how we'd set this up exactly, but I'm sure there's a way.

Of course -- nobody ever needs to ask if they can ask. Just ask.

Sorry there was a typo in my previous code, and I'm pretty sure that's why it didn't work. You want to use getField() rather than get(). $ls_fieldgroup->getField('title', true); The reason for this is that getField() can return a field in context but get() can't (as it only has 1 argument).

Try this: $title = $ls_fieldgroup->get('title', true); $title->collapsed = Inputfield::collapsedHidden; wire('fields')->saveFieldgroupContext($title, $ls_fieldgroup); I could probably make this simpler from the API perspective (to work more like your code example), but only you and I have needed this capability so far.

Sorry I missed this before. Got your PM so replying here. I'm still having some trouble understanding the question, but think I follow a bit. It sounds like you are trying to use $pages->get() to retrieve a page via a path like /a/b/ where /a/ is an actual page and /b/ is a urlSegment. A path with a urlSegment in it doesn't resolve to an actual page except when requested from the browser. So you can't use the API to retrieve a page by path with a urlSegment in it -- you'll get a NullPage. You would want to use just the /a/ (the part that is actually a page) in your API call. urlSegments are just runtime things for you to branch from in your template. They don't represent physical pages to the API.

But there's a difference between integration and distribution. If it was really GNU compatible, then I could take Redactor and make my own version that just changes the name (RyRedactor), and then offer it available for use to anyone for free. At that point, people would no longer have to pay for Redactor. As a result, I think when they say "integration with open source software" they aren't telling the full story. But if we can find an example of another GNU open source software doing it, then we can follow their lead.

If you guys see another GNU open source licensed CMS using this, then I'll assume that means we can too. Perch isn't a GNU/open source, so they don't have to consider the issue. If there's a way to make it legal, I'll be glad to handle the dev side of making this Inputfield if others want to chip in to buy the necessary license. But just the fact that it's necessary to buy a license makes me think it's not technically GNU compatible... could land us in hot water to distribute it with PW. Another way to do it would be to make it a commercial module (like Form Builder) where it doesn't come with PW, but you can add it on separately. That way the distribution is controlled in the same manner as Redactor, which would keep it legal.