Jump to content

teppo

PW-Moderators
  • Posts

    3,227
  • Joined

  • Last visited

  • Days Won

    109

Everything posted by teppo

  1. Not familiar with your particular issue, so I'd start from the basics: have you checked error logs yet? A 500 error should leave something in the Apache error.log, and that something should at least point us to the right direction. I'd also check PW log files, especially /site/assets/logs/errors.txt, for any inconsistencies. Edit: additionally, please make sure that /site/assets/cache/ and /site/assets/sessions/ are writable by the Apache user.
  2. RT @chrismessina: The state of the art in terms of service UIs on TV from @netflix. Ready to read 106 pages of legalese? http://t.co/FkbZAY…

  3. RT @processwire: New blog post: Target templates w/field editor, better field clone & tons of session updates… https://t.co/LEjo8EHiyc (Pro…

  4. I think the issue Soma is referring to was that in fact only the person originally reporting the issue (or Ryan) can reopen a closed issue at GitHub. Last time this resulted in a bit of a mess when existing issues (and feature requests) where the reporting person had disappeared were closed and reopening them seemed rather difficult. That's why I really don't believe in this strategy either. If there's a bug report, discussion, or feature request, it's probably there for a reason, and closing those en masse feels plain wrong On the other hand, I do believe that issues that are solved can be swiftly closed without waiting for an answer. I also generally speaking agree with what's being said here, i.e. that these figures matter. Helping Ryan by tracking down any bugs and commenting on feature requests etc. sounds like a potential first step towards this goal to me.
  5. Got a coffee ticket as a compensation for the train being over an hour late. Tried to cash it in, but they're out of coffee. #doingitwrong

  6. It's been a while, but just for the record: this issue (or at least one with identical symptoms) has been fixed some time ago.
  7. @majkiris: it's quite simple, really. Groups are just pages and view/edit permissions are defined by page fields view_groups and edit_groups. There's also a separate manage_access checkbox field, which defines whether a specific page manages permissions itself, or if it uses permissions from one of it's parent pages. If you want to add a new group, just add a page with template user-group under the groups page at Admin. If you want to grant this new group view permission to a page, find the page and add this new group into its view_groups field. Then save the page, and UserGroupsHooks.module should handle the rest -- though you might also have to enable manage_access (setting it to '1'), can't remember how exactly this worked. Hope this helps a bit. Please let us know if you need more specific instructions.
  8. This is solvable by using Jumplinks, but especially if there's a potential of a lot of traffic, redirect at .htaccess level would be more efficient. Jumplinks is flexible and easy to use, but the downside is that the whole system has to be started just to realise that "oh, this request doesn't belong to this site at all". Waste of time and resources, really Never seen this particular issue, but it sounds like you're, perhaps, doing this at the end of your .htaccess file, or something like that? The .htaccess file adds ?it=... and in a case like this that part of it shouldn't run at all. As a first step I'd try moving this as close to the beginning of the .htaccess file as possible. This is a simple redirect, so it's quite likely that the issue is something simple too
  9. Especially if the site is working otherwise, i.e. you can navigate pages and so on, this sounds more like a compatibility issue with URLs in use (or perhaps something else in Plesk) and ProcessWire's method of finding out required paths. Much of related magic happens in index.php, so that's where I'd start looking. Never used Plesk myself, and sadly it seems that I can't get my hands on one of those without paying for it, so I probably won't be able to debug this further
  10. RT @processwire: New blog post: a new Fieldtype for supporting selectable option fields (w/o pages) in ProcessWire (2.5.17) – https://t.co/…

  11. Regarding HHVM, this could be of interest: https://processwire.com/talk/topic/5226-does-processwire-work-with-the-hiphop-virtual-machine-hhvm/
  12. Exactly. It would be nice to know a) how big the need really is, and b) how much work is needed to add and maintain this. I don't have anything against IIS, but it's also very unlikely that I'll ever need it either. We've already got native support for Apache, and personally I'd like to see native support for nginx too. On my list that's much higher than IIS. .. although I did specifically make the Changelog module IIS compatible, so who am I to speak
  13. Technology is no longer a barrier for remote work. Outdated and/or misinformed attitudes are.

  14. "Adventure games from the 1990s are notorious for puzzles that are obtuse and often nonsensical". But isn't that exactly why we love them?

  15. Not exactly: $pages->uncache($page) calls $page->uncache(). Both have it, scope is slightly different
  16. Hi there, @jacknails! This thread over here might be worth checking out. Same subject, different name. Currently ProcessWire roughly follows the URI spec (RFC 3986), while what you're describing would require support for the IRI spec (RFC 3987). +1 for this from me, though it doesn't seem to be very common need yet. This is probably the third time or so I've seen it asked for. Once there's enough need for it, I'm sure Ryan will take it into more serious consideration.
  17. You're right in that saveReady happens just before Page is saved, but the values of this Page object have already changed. Database contains old values, Page object contains new values, so if you ask the Page for any of it's fields, it'll return the values as they are now (already changed). This is one of the reasons why my Version Control module, for an example, actually stores current values instead of old values. On the next change+save it stores next set of values, and so on. For my use case this didn't make much of a difference, and it was (at the moment) only simple way to do it. That's probably something you could do here too; otherwise you'll have to hook at some point where the values are sure to be unchanged, store them, and later compare them with changed values at saveReady (or find a way to create a copy of current page and return it to database defaults while leaving the ready-to-be-saved Page object intact, though if your uncache trick above isn't doing this, I'm not entirely sure how to do it). Another thing you could check out would be the (relatively new, 2.4+) ___changed() method. This commit contains all the changes related to this feature.
  18. Regarding "related posts", I also think that it's a pretty important for any blog out there. As a blogger you want readers to stay as long as possible and visit as many posts as possible. A feed of related posts is a great way to achieve that. Not sure if it's still up-to-date, but I've used this Gist by Soma in some projects a while ago, mainly for the scoring part
  19. RT @Joss_Sanglier: 2014 Critics' Choice Award Winner - Best Free PHP CMS https://t.co/JGbxKTSVRF

  20. RT @TuomoTH: We here @avoine are not the only ones who love #ProcessWire http://t.co/761lSAhctf. Forget #Wordpress and #Drupal...

  21. RT @processwire: Check out the new ProcessWire developer directory, built by @Notanotherdev at http://t.co/NXeywCEXPD and please add yourse…

×
×
  • Create New...