teppo

Ryan: I've run some tests regarding this fix and so far it seems to work as intended. Haven't had an opportunity to really test it thoroughly, though, which is a shame. Anyway, do you have any further information about when this might end up in master -- is that unlikely to happen before 2.3 is out? And as a related question, have you already decided when 2.3 might come out? In the latter case I might have to copy related changes for this client or make their site use dev branch, though that's not something I'd like to do without a very good reason..

Ryan: that makes sense.. and thanks for the example. Hooking right after ProcessController::execute did the trick in this case

Soma: I think you're right there. Should've thought this through before even asking, but.. at this point I'm also tempted to say that hooks look like the only possible answer to this particular problem

Now I have. Same effect. Also, just realized that if I was doing this by extending ModuleJS there wouldn't really be any need for custom code at init() -- just calling parent::init() would be enough. But then again, ModuleJS clearly isn't supposed to be autoload, which (I think) is a requirement in this case, so I guess that's out of the question anyway. The more I think about this the more I believe that what I originally asked just isn't possible, not the way I was trying to do it at least. So I'm guessing I had to misunderstand that post I quoted before and this really has to be done with a hook.

Sorry, my mistake for taking things too literally Yeah, first post does. But later when asked about the best way to inject JS into admin Ryan provided an answer where scripts get added to $this->config->scripts at init(), which is why I ended up with a combination of these two. Guess I was misunderstanding what that example really meant. Still kind of confused about this, especially since the question there was (quoting) "Also wanted to ask what is the best way to inject javascript in admin pages".. exactly what I'm trying to do here I just wanted to know if it was possible to inject scripts into admin views through $this->config->scripts at the init() method of my own module, without utilizing any hooks. Like I've mentioned above, I've solved this with a hook already, but that's just not nearly as pretty as adding them to scripts would be. I had a closer look at that thread, and this answer by Ryan pretty much explains what's happening here (quoting): "it's feasible that an autoload Process module could load before JqueryCore." My module isn't a process module, but I guess same still applies here -- and that would essentially mean that the answer to my first question is "you can't do that." Which is a shame, but I can live with that. Anyway, thanks for your time, this has once again been interesting

Soma: in my test case I'm using the code slkwrm has at the first post from the thread I linked to, but with addLinks() removed and code from Ryan's post included in init() method. Execute functions only apply to process modules, right? Since this isn't a process module, I'm not so sure that they're what's missing here. To be honest this problem probably is quite easy to work around by simply adding the script right before </head> in rendered markup, but the method posted in that thread looks so much cleaner that I'd rather do it that way Edit: replaced aforementioned method with simple replace hooked after Page::render, which essentially gives the result I need here. Still, the original problem remains unclear. At least to me

Like the title says, I'm trying to inject my own little JS file into certain admin views and the problem is that jQuery gets loaded after my custom JS file -- in fact $this->config->scripts seems to be null at the init phase of my module. I've confirmed this by taking a look at markup of rendered page also; custom script is the first one added (even before jQuery) and thus won't work properly. The funny thing here is that (after getting same error while trying to hack this up myself) I tried doing exactly what Ryan mentioned here, and I'm still getting exactly the same problem. Is it possible that something has changed since then, or is it just me doing something wrong? Any help would be highly appreciated!

As a quick fix, you could add it to the top of /wire/templates-admin/default.php. If you want to write a module for doing that, a simple autoload module which hooks right before Page::render and just sends the header there should be enough. The Helloworld.module that ships with ProcessWire default theme is a nice starting point for this (it's already autoload and demonstrates how hooks are used.) The only code you'll need in init() would look pretty much like this: $this->addHookBefore('Page::render', $this, "sendHeader"); And your sendHeader() method would only need to contain that header you've posted above: public function sendHeader() { header("Content-Type: text/html;charset=UTF-8"); } Hope this helps!

I agree with Antti here. Using "ProcessWire" (or "PW") in the name of your site / product / module / whatever may imply that you have an official bond with ProcessWire project itself, whether or not that's really the situation, and thus should be avoided (unless that really is the situation of course.) That's also why the way @Luis' site above uses (modified but still very much recognizable) PW logo makes me think of an official PW apparel shop or something like that. I'm really sorry for having to be a bit blunt here, but that's the image I'm getting. And just for the record, I also think that PHP devs are being surprisingly lax regarding this matter. They're not saying that you can't use PHP in product naming, just that you "should seriously consider avoiding it", which for most developers out there seems to mean "it's all OK, we don't really care!" Then again, changing an old policy like that afterwards would not only cause a shitload of work, it would also be quite impossible to supervise and possibly even harmful to the spirit of the PHP community. So I guess they're pretty much out of options already

Strange. Would've expected something to show up in error log if upload fails, as it seems to have done. Some things you might want to check at this point: Double check that /site/assets/files/1143/ has write access to whoever Apache is running as (or 777, if you really need to -- although I've actually encountered some hosts that, as a security measure, specifically won't work with chmod 777.. but in that case an error should definitely be triggered) Watch your browsers console and net panels while doing the upload; something should show up there also. Check if your file could be too large for PHP to handle or somehow malformed (very unlikely, if it's just an ordinary image) Make sure that you're watching the right error log (seriously, I've made this mistake more than once.. watched general Apache error log while site logs were actually being saved in their respective directories etc.. ) Try uploading files to other pages / other files to this page; is the error consistently there or does it only exist a) on this page or b) with this file? What if you try with a different browser, is the problem still there? Sorry for not being able to pinpoint the problem right away. File-related quirks can be really, really annoying at times

Site folder shouldn't require 777, and I'd even consider it a bad practice, since strictly speaking PW doesn't need that. Combined with improper filtering of user input, for an example, it could lead to very severe security issues (injecting code into template files, altering config file etc.) What errors (if any) are you getting in the developer console of [insert your browser here]? What about Apache and/or PW error log? Edit: especially if you're running in a shared hosting environment (you're not, right?) you should be extremely cautious about giving "others" write access to anything. Just saying

Assets (/site/assets/) and everything below that point. AFAIK (after install at least) nothing else should require write permission.

Page Link Abstractor is a splendid module, but it also introduces a rather big change to the way PW handles links. If you "just" want a one-time fix for changed links, it might be easier to run a simple SQL query for fields that contain changed links, replacing old links with new ones. Something like "UPDATE field_yourfield SET data = REPLACE(data, 'href="/newsite', 'href="');" should do the trick. Since I'm not sure how familiar you are with MySQL / SQL in general, this may be self-evident to you, but still: a) if you're not absolutely sure about what you're doing, don't try method I mentioned above and b) always make a backup of the table you're working with before making any changes to existing data (CREATE TABLE backup_field_yourfield LIKE field_yourfield; INSERT INTO backup_field_yourfield SELECT * FROM field_yourfield;) By the way, Page Link Abstractors description says that "This module hasn't yet been tested with migrating a site from subdirectory to root, but I will be testing this soon." Old information perhaps?

Hello there, You wouldn't happen to have this page online, so we could see it in action? If you're sure that you haven't changed edit link markup in your template, most logical option I can think of would be that link href is added beside that particular link with CSS. This is quite common in print stylesheets, but why it would be used here beats me. Anyway, this should be pretty easy to find out; just look for something along these lines in your stylesheet file: a:after { content:" (" attr(href) ") "; }

Just to make sure, you've used the "HTML" button in TinyMCE and pasted the code there? Could you paste it here too, so that we can take a look and possibly determine what's the problem? Anyway, the first thing I'd check would be body fields settings. Under Input > TinyMCE Advanced Configuration Options there's a valid_elements input. Check if all elements in your code are included there. If I remember correctly, this might not be the only thing that affects which HTML tags are allowed in a TinyMCE field, but that's a good starting point.

@ryan: Thank you! @apeisa: I've got it implemented in our testing environment already, though it's a bit ugly at the moment so I'll probably find better way to do it. I'll take a look at this asap and send you a pm or something, unless you're in a hurry? .. and you're absolutely right about it being behind a setting, now that I think about it -- don't want to break anything for existing users, 'cause that would be just mean.

Pretty much like that, though at the moment only space is supported separator. Should probably add support for commas too, now that you mentioned it

Pete, I agree with you on the fact that Twitter is important and widely used. After reading couple of threads and posts about the subject, it doesn't seem obvious that they're going to support OAuth2 anytime soon either. It's just that these kind of "short-time compromises" are quite difficult to get rid of later on without breaking anything for existing users. What I'm suggesting is that perhaps we're actually talking about two different modules here -- one for dinosaurs like Twitter, another for forward-oriented services which already support OAuth2?

@apeisa, thanks for this module -- it's working beautifully! For our needs I had to implement support for alternative domains (each extra domain can have n alternatives, which all point to the same location.) With separate domains for development and secure addresses -- not to mention that in this case the client required alternative domains that couldn't be handled very well with just redirects -- that was pretty much the easiest way to put together a consistent experience. So, basically I'm asking if you'd be interested in incorporating that addition in the main module if I sent you a pull request for it (of course once I've tested it properly first?)

@apeisa: thanks, that's actually a good idea and something I could probably work with. I'd still prefer to have rootParent work consistently with or without Multisite in use -- it's a core feature after all and I'm kind of used to it already

Pete, you're right in saying that download size won't make a big difference, but complicated codebase sure does. Of course good code should be modular and allow relatively minor additions (such as new auth methods in this case) without the need to alter "core module"..

Little bit of background: I'm trying to use (and hack) Multisite-module by @apeisa for a client project, but got stuck on one somewhat annoying problem: it doesn't do anything to $page->rootParent(), thus that still returns site root or first page after that, which isn't very useful here. Most straightforward way to override this would seem to be hooking into rootParent and altering it's return value or completely replacing it with my own method. I've tested this with local installation and this method seems to work. So, my question is: would it be possible to make $page->rootParent() hookable or do I have to hack my way around this problem? Not really sure if altering rootParent is a common need, but it sounds justified in cases where you're overwriting PW URL scheme somehow (like Antti's Multisite module does.) Of course if there's a better way, I'm open for ideas too

I thought it might be that too, but on the other hand PW doesn't seem to have any problem with me creating a setup where one page with view access denied for guests has another page below it with view access granted to guests -- in that setup guests can still access that subpage, even though they cannot access it's parent. Or perhaps it's completely another matter when we're talking about the root page..? Anyway, to sum it up, I'm a bit confused about what's happening here

I've solved this problem in the past with similar solution SiNNuT mentioned; in our case all templates actually use one template file which functions as a front controller and redirects queries to actual template files, making it relatively simple to determine whether or not access should be (artificially) limited. Would still like to hear an answer to the first question by Ryan / someone who knows exactly why this is happening. It's more than a bit annoying sometimes and this kind of solution still feels a bit like a hack