mindplay.dk

@Pete your module probably does more than just authenticate with Twitter? Matt Harris' library has a lot of unnecessary code, and it uses OAuth1 protocol - so probably a good fit for a Twitter-specific module, but not a good choice for a multi-provider login module.

Yeah, Twitter will catch up - go vote for OAuth2 support using the link above

Hmm, I looked at a couple of those... they seem pretty complex - they probably do a lot more than just authentication? I think Phil's classes are a perfect starting point - they do precisely what I want, not a whole lot else, and having a single implementation with a multi-provider API means less repetition, and less code to maintain.

Looking at the size and complexity of the OAuth1 and OAuth2 libraries from the same author, it is evident that OAuth2 is considerably less complicated to implement, which is something that appeals to me a lot. I also don't like building for the past - pretty soon, everyone will support OAuth2, and then we'll need to upgrade. It looks like the only major vendor not following suit yet is Twitter - pretty much everyone else is on board with OAuth2, and Twitter probably will be soon... It looks like there is some pressure from developers - and some talk here with other reasons why OAuth2 is the safer bet. I would bet on OAuth2, and wait for Twitter to come along. If the ProcessWire module maintains compatibility with Phil's OAuth2 provider interface, we should be able to port over (Twitter and other) new providers from his project with zero modifications, so that's another plus.

Well, fortunately for me, on this particular project, I have one distinct parent-node with a distinct template, so the problem was easily solved by restricting access to that template - all other templates inherit it's security settings. You work-around is good for sites that are exclusively private - but not for sites that are private by default, but still publish some content.

For the record, I asked Phil Sturgeon, and he confirmed that Twitter does not (yet?) support OAuth2.

That sounds interesting - here's a thought: if the URL is going to be "unguessable" anyhow, then why do the draft pages even have to be real, published pages? It might make more sense to keep them unpublished, so you don't have to "fix it in the mix" by trying to filter them - I suspect that's going to lead down a long road of other side-effects. Instead, you could set up a controller that takes the unguessable key as an argument - so you get something like "site.com/preview/2442cb34cfc234dbf41cbf3c4", where "preview" is a page that accepts the key as an argument... your controller (or I think the term is "process"?) can then fetch the unpublished preview and render the page. Does that sound like a working approach?

Due to the name change, the module is now here: https://github.com/mindplay-dk/PageListPin I have tagged it as 1.0.0.

I wanted it to show up next to the other Page module - but I see now that the optional Page modules aren't named "Process", so I'll go ahead and change that

I'm setting up a site that is private - it has no public viewable pages. First I tried to edit the "Guest" role and turn off "View Pages" - that's not allowed. Then I tried turning off the "Guest" role on the Access tab for the Home page, thinking all the child-pages would inherit that setting by default - that's not allowed either. Are both of these restrictions "real" and in place for a reason? It seems the only way to set up a private site, is to go through all the templates one by one and turn off the "Guest" role for each and every one of them - not a very practical or safe approach for a site that is intentionally private by default...

I'm interested in this too, and did some research. Looks like OAuth2 is going to be the simplest and most durable way to go? I looked at bunch of libraries, and being a minimalist, I clearly favor Phil Sturgeon's implementation, here: https://github.com/philsturgeon/codeigniter-oauth2 This is purely a client, which makes this library really thin and easy to reference for integration with ProcessWire. This is a CodeIgniter module, but seems to have very few dependencies on CI, and has already been independently ported to other frameworks by various people. For some reason it does not seem to have a Twitter provider. I don't know much about OAuth as such, but does Twitter not support OAuth2 yet maybe? There's an OAuth (1) version of the same library: https://github.com/philsturgeon/codeigniter-oauth This one does have the Twitter provider. I wonder why that is... I think the three critical providers are going to be Google, FaceBook and Twitter - those must be supported. If that means we have to stick with OAuth1, maybe that's the way to go... Thoughts?

Is this a bug? I'm seeing this on multiple different PW setups using release 2.2.9...

No, I've been aware of that for a long time - it just doesn't really work for me. Most of the time, I intuitively hit the PAGES link when that's where I want to go. Having to first think about where to click seems counter-intuitive to me. Going back to the page list is possibly the most common and frequent operation, so I don't want to have to stop and think just to do that. Every UI makes assumptions - I don't like the assumption that I would need to go back to the sitemap having absolutely nothing open at all. How often do you edit one of your root pages? In my experience, they are the least likely to be edited - much more likely you're going to edit, say, a few articles in the same folder, a few products in the same category, etc. I've already had a couple of people tell me how annoying it is that you return to a fully collapsed page list all the time, which tells me that other people intuitively click the same place too - it just doesn't seem like something you should need to think to do. Anyhow, the module is working nicely on two sites already, so I will tag this as 1.0.0 and submit my first official module listing, woo hoo Oh, before I submit this, one quick question - you guys think the name makes any sense?? I'm open to ideas.

@kolewu I see, thanks - I never clicked on that, guess I was just looking for the word "preview" which most forums have right next to the submit-button...

Come to think of it, I've used IP board and not hated it. Maybe it's just not configured well for code - smilies are probably just one issue. For code-related boards, I tend to prefer wiki/markdown-syntax of some sort, over HTML input. Just never seems to work well for code...

This thing drives me nuts - if at least it had a post preview... every post I have to edit, it screws up smilies and code every time, ugh...

Ha ha, I don't personally - haven't used 5.2 since 2010 ... But someone quickly posted a "bug report", and apparently I love working for free - isn't that the spirit of open source?

It was fine for my purposes, the two API points I'm using do use the abstraction - not consistently, but in the two conditions that affect my module. Here's the module, by the way: https://github.com/mindplay-dk/ProcessPagePin This is another one of those small features I think should be standard - I wouldn't ship a solution without this module. I think it's more a matter of developer preference than client preference - the client, I think, would either prefer this behavior, or perhaps not care if they didn't know it was an option. I'd prefer to see something like this already available to install out of the box, but I know you're a minimalist, and I actually appreciate that about you, so - hopefully those who want this behavior will find my module. It's such a small thing, it almost seemed silly to do it as a module though... but it was educational, and I feel increasingly like I can make PW do just about whatever I want - something I've never felt with another CMS!

@ryan I've been poking through ProcessPageList, ProcessPageEdit and ProcessPageAdd for a module I'm tinkering with. I was wondering, how come WireInputData is not used consistently throughout ProcessWire? Many of these modules directly access $_GET and $_POST, and in my case, I'm snooping/injecting on certain GET/POST variables, and this code has to be tailored to each specific module/function, because $_GET and $_POST are copied (rather than referenced) by WireInput. EDIT: to clarify - if you wanted to inject a GET-variable (from a hook) you would have to either inject the value into both wire('input') and $_GET[], and/or figure out how/why the individual module/function accesses a particular GET-variable. Is this just an artifact of an incomplete effort to move away from direct $_GET and $_POST access?

Right, thanks @somatonic - I had forgotten... Just integrated that change, seems to work

On another note, @ryan - looks like TemplateDecorator still can't work with PHP prior to 5.3, because I'm using ReflectionProperty::setAccessible() in this method: https://github.com/mindplay-dk/TemplateDecorator/blob/master/TemplateDecorator.module#L154 Would you consider exposing the property, so I can make my module work with PHP 5.2?

Hmm, but I don't want to hook every MarkupAdminDataTable::row() call - just for that particular instance. Perhaps the simpler solution is to add a hookable createTable() function that takes the list of templates as argument, and returns the MarkupAdminDataTable instance? That way, you could choose whatever approach works best for a given situation - either hooking the row() method of just that instance using a before-hook, or iterating through the rows in an after-hook.