ryan

Static hooks apply to all instances of a class, whereas direct instance hooks apply to just 1 instance (the one you assign it to). For example, you'd use a static hook if you wanted to hook into or add some new method to all Page instances. Whereas, if you are hooking any API variable ($session, $pages, $modules, etc.), it's better to use a direct/instance hook since there is only ever going to be 1 instance of those variables anyway. While you could use a static hook anywhere, direct hooks are a little more efficient because they are stored with the actual object instance rather than in the larger pool of static hooks. Meaning, direct/instance hooks result in less for ProcessWire to sift through when executing hooks (though it probably doesn't matter much in the larger scheme of things). But this is also the reason why they aren't prioritized together, as they are stored in different places.

I've asked again if they can produce any examples of open source projects that are integrated and distributed with Redactor. So if we can follow some other project's lead, then that's cool with me. But so far it doesn't seem like any freely distributed open source project actually uses Redactor. I'm hoping they'll reply with an example or two though (they must be out there). One possibility is that we could use an older version, which is CC-noncommercial licensed. Can't exactly distribute it with ProcessWire itself, but could distribute as a free module: https://github.com/dybskiy/redactor-js

Glad you got it working. Static hooks ("Session::login") are treated separately from direct hooks. The direct hooks are more specific so they get executed before the static ones. But I wasn't really thinking much about priority level when building this, so not sure if that's the way it should be or not.

That's correct. At least, that was the intention. It's one of those things I thought would come in more handy than it has… I'm not aware of it ever being used. So I think the only time it has even been tested is when I originally coded it in there (at which time it was working). No recent confirmation of current functionality though. A quick glance in the code seems to indicate that it should work as intended, though please let me know if you find otherwise. Default priority level is 100 (that's what gets assigned when none assigned).

Unless you can find some way to use the existing user pages for this purpose… They are protected under the admin, somewhere you probably don't want your public users going. But like you saw, it's pretty easy to make any other page behave as a user page by using URL segments. So that's probably the way I'd do it.

Good to know there is still an RSS available. But if it's only for a few months, it's probably not the long term solution we need for this module (though great that it buys us some time). Is Twitter going out of business or something? Just wondering why they are closing things down. It seems unusual because the natural result of this change will be for people to create their "tweets" elsewhere… relegating Twitter to be a carbon copier rather than a source. Obsoletion. The last version of my "oneliner" software (for Wildcat BBS) came out in 1993. Now thinking I need to make a new version for ProcessWire.

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.