Jump to content

teppo

PW-Moderators
  • Posts

    3,208
  • Joined

  • Last visited

  • Days Won

    107

Everything posted by teppo

  1. Thanks Ryan IP logging was intentionally left out to avoid collecting too much "identifying" data, but right now I'm thinking of adding it anyway -- it shouldn't come as a surprise to anyone that this can (and will) be logged, not to mention that Apache already keeps track of this information. This was also suggested when I asked a coworker for comments earlier today.
  2. This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.
  3. Didn't realize that. That at least partly solves the problem, though I'd imagine that this could cause some confusion in certain rare cases when uninstalled module is suddenly installed again. Not sure if that's such a big deal, just thinking out loud. Cough. Yeah. Sorry for that, it was a typo -- it was really late when I wrote that post after all. What I meant was that A requires and installs B, B requires and installs A.. Even though my post was pretty confusing, you've understood it perfectly. That's exactly what I was going after.
  4. First of all, can't help admiring your attitude Based on very quick look at the code, LanguageSupport seems to use external installer / uninstaller script to manage dependencies. This is probably something I'll have to take a closer look at tomorrow (11 pm here, seen way too many lines of code for one day already) but according to (equally quick) test it doesn't seem to solve my problem straight away: LanguageSupport installs ProcessLanguage and ProcessLanguageTranslator, both of which are uninstalled with LanguageSupport itself, but I can still remove either one of those latter modules without affecting ProcessLanguage if I so decide. Not sure if that's a problem for LanguageSupport (possibly not, don't really know it's inner workings well enough to say) but it's essentially same behaviour I'm experiencing with my modules (in which case it is a problem.)
  5. I'm having a minor nervous breakdown here, so I'd appreciate if someone could tell me exactly what it is that I'm doing wrong. I've got two modules that need each other to work properly. What I'm trying to achieve is that when user installs one of these modules, it automagically installs other module. Also when user uninstalls one of them, other one is also uninstalled. My question is if there's any way to have two modules which a) install and b) uninstall each other automatically? I did try setting up some hand crafted install/uninstall magic, but results ranged from bad to worse, especially regarding automatic uninstallation. Anyway, since ProcessWire these days manages automatic installations / uninstallations itself, that's what I've been mostly focusing. Results, as you can see below, haven't so far been that great. (Sorry for very long post -- I tried to keep it simple, but there were quite a few things to mention and I didn't want to accidentally leave anything important out.) First part, installation, was easy to setup using AutoInstall logic and following settings: A: 'installs' => 'B' B: 'requires' => 'A' This way module B cannot be installed alone, user has to install module A first. When she installs A, B is installed right away and everything is cool so far. What I can't seem to get working is the AutoUninstall part. If user uninstalls A, B is uninstalled too, but things get complicated when she suddenly decides uninstall B first. That way module B is uninstalled but A stays intact, which is not cool at all. Seemingly there's nothing I can do to stop that either. A: 'installs' => 'B', 'requires' => 'B' B: 'requires' => 'A' As you can see above, I tried to solve this by making module A require module B, which makes it impossible to uninstall B first, but that also seems to render AutoInstall useless: while uninstalling module A an error pops out: "Module is required by other modules that must be uninstalled first." After that module A is uninstalled but module B left intact. Bugger. A: 'requires' => 'A', 'installs' => 'B' B: 'requires' => 'A', 'installs' => 'A' My next experiment was telling module B to install module A (and thus also uninstall it) which actually seemed to work -- but with the slight setback that it also caused a loop which ends with PHP timeouting. After timeout both modules are uninstalled, but that's not exactly the way I'd like it to happen. A: 'installs' => 'B' B: 'installs' => 'A' At my final moment of desperation I removed requires from both modules and instead told them to just install each other. Which, naturally, only made things worse; with that setting neither module (no matter how much they claim that "This will also uninstall other modules - A" etc.) can uninstall the other. No errors, nothing. Other module just sits there like nothing happened. I've banged my head on wall with this for way too long already, so I'd appreciate if someone could point me to the right direction. And if what I'm trying to achieve isn't possible with automatic installs / uninstalls, that's also very nice to know.
  6. Each page knows when it was added and when it was last updated, since this data is contained within pages database table. There's no such data available for file fields. Your best bet would probably be creating either a custom fieldtype or (perhaps easier method) a module that hooks to page save, checks if file fields exist and if their contents have changed and then keeps a log of newly added files in page-specific (hidden) text / textarea field. JSON format is nice for storing that kind of data. There might be a better way or this method may contain some unexpected problems, can't really test it right now, but that's what I'd suggest.
  7. 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..
  8. Ryan: that makes sense.. and thanks for the example. Hooking right after ProcessController::execute did the trick in this case
  9. 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
  10. 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.
  11. 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
  12. 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
  13. 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!
  14. 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!
  15. 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
  16. 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
  17. 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
  18. Assets (/site/assets/) and everything below that point. AFAIK (after install at least) nothing else should require write permission.
  19. There's still time to vote #ProcessWire as Best Open Source CMS or Best Budget CMS at Critic's Choice CMS Awards! http://t.co/NcMQTUZ9

  20. 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?
  21. 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) ") "; }
  22. 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.
  23. @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.
  24. 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
  25. 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?
×
×
  • Create New...