• Content count

  • Joined

  • Last visited

  • Days Won


teppo last won the day on June 2

teppo had the most liked content!

Community Reputation

3,634 Excellent

About teppo

  • Rank
    Captain Earth
  • Birthday 08/21/1984

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

37,679 profile views
  1. teppo

    Every time this topic comes up I'm slightly worried about the relation between any community-led documentation project and the new(ish) API reference at https://processwire.com/api/ref/. This already gets (somewhat?) automatically populated based on the latest core release, and I seem to remember @ryan mentioning something along the lines of updating / releasing a new cheatsheet that would use same data. If that's really the plan, it could easily make any manually updated documentation obsolete. That being said, I'm not 100% sure that this actually was Ryan's plan – or if it was, is that still true. Additionally it might take a very long time before he gets there (he's a busy fellow, after all.) Would be great if the man himself could chime in and let us know what's the current plan is, and if we can somehow help make that happen One problem with the current, auto-generated docs might be that (as far as I remember correctly) the code that generates it is also powering the (commercial) API Explorer module, which could make Ryan somewhat hesitant to share it with others – which is perfectly fine, of course, but could also mean that we can't do much to help him there. But anyway, this is mostly just guessing. I've been quite happy with the new API reference, with the main problem being that one can't switch between core versions. For us who manage and work on ProcessWire 2.2 ... 3.0 that's a major downside: currently when I'm working on anything other than my own pet projects, where the core version is generally speaking always the latest one, it's much easier to forget the docs and dive into the codebase to see which methods were available at the time.
  2. Short answer: this sounds like a use case for the "Custom PHP code" option of the Page field you're storing tag references into. This way you can do a lot more than with just selectors.
  3. teppo

    Definitely an interesting move, and I'm also wondering what Microsoft is planning to do with GitHub How will the focus of the platform evolve and will there be new restrictions for projects or users? Do they plan to integrate GitHub more tightly with their own tools? Could this mean that they're so attached to the GitHub platform that they need to make sure one of their competitors doesn't buy it first? Or perhaps this is just one more step in their ongoing effort to impress developers? There's not enough data to make any kind of educated guesses yet, so we'll just have to wait and see how it goes. One obvious thing is that a corporate entity like Microsoft wouldn't just go around buying services/platforms for the heck of it, or because said services/platforms have a great community, or whatever. Their primary goal will always be growing their business and bringing in more money – and somehow, directly or indirectly, GitHub is now part of that. Although I'm not particularly worried, I do think it's reasonable to be a bit concerned when a massive corporation like Microsoft buys out a platform as influential as GitHub – especially when that influence is probably most prominent within the open source community and individual developers working on non-commercial projects. Anyway, I can't see how wrecking the legacy of GitHub would be good for their business, so there's (probably) no need to be worried.
  4. teppo

    Fieldtype Page IDs is a third party Fieldtype that, simply put, stores Page references as integers (Page IDs). This fieldtype was built as a quick and dirty workaround for Page Reference fields' inability handle self-references due to circular reference issues. A project I've been working on for a while now includes a combination of RepeaterMatrix content blocks and tagging/categorization system that would've resulted in a lot of duplicate pages (and plenty of unnecessary manual work for content editors) had I used built-in Page Reference fields, and thus a new Fieldtype felt like the most sensible approach. Fieldtype Page IDs was designed to be loosely compatible with Page References in order to make conversions between the two feasible, but it is quite limited feature wise: largely due to the fact that stored values are actually just integers with no connection to Pages whatsoever some advanced selectors and related features are not supported, and page values can't be directly accessed configuration settings are limited to the bare essentials (selector string and Inputfield class) only a handful of Inputfields (AsmSelect, Checkboxes, Text) are (currently) supported Anyway, in case you need to store Page IDs (and Page IDs only) and are happy with the limitations mentioned above, feel free to give this Fieldtype a try. It has been working fine for me in one particular project, but hasn't been tested that much, so please tread carefully – and let me know if you run into any issues. GitHub repository: https://github.com/teppokoivula/FieldtypePageIDs Modules directory: https://modules.processwire.com/modules/fieldtype-page-ids/
  5. teppo

    Just a quick heads up: Modules area of the support forum is intended for dedicated support boards for third party modules. This seems to be a a general / core related issue, so I'm moving this thread to the General Support area.
  6. Hey there, @theo! Just wanted to notify you that I'm moving this topic to the "Module/Plugin Development" subforum. The "Modules/Plugins" forum area is where support boards for existing modules live, while all module development related topics belong to the "Module/Plugin Development" subforum. Thanks, and sorry for the disturbance
  7. teppo

    @Thomas108: this is a Textformatter module, so you need to enable it via field settings: Setup > Fields > your-fieldname > Details > Textformatters.
  8. teppo

    @horst, sorry to bother you with this (and sorry if it's a dumb question in the first place), but what's the current state of this module like? I'm in desperate need of "pixel perfect" pre-defined crops, and while the focus and zoom feature is really cool, it solves a different problem entirely. Reading some of the posts here I'm wondering if this module is still something I should go with, or do I just need to wait and hope that @ryan decides to add pre-defined crop areas to the core one day? Thanks!
  9. teppo

    Depends on your use case, but.. that's not entirely true. When you embed an image into a CKEditor field, for an example, you get to choose from which page you want to pick the image from. Similarly you can request an image from any given page via the API in your template files. So no, an image is not strictly tied to one page: you can embed images anywhere, and you can indeed use them in multiple places on your site. There are also some modules that make reusing media easier, such as MediaLibrary (free) and Media Manager (commercial). It is true, though, that behind the scenes an image is always connected to a single page, and because of that ... A) you can't have a single image showing up in image fields of multiple pages, B) only one copy of each image file is stored in a page-specific directory under /site/assets/files/, and C) if you have restricted access to a given page and enabled $config->pagefileSecure, access to files (including images) on that page will also be restricted.
  10. teppo

    There's a little gotcha related to this module: if you have it enabled on a late version of ProcessWire, it could break the language translation UI if one or more of your translation strings include the phrase "</head>". ProcessPageDelete inserts a script block in front of all of those, which breaks the scripts on the page. None of such phrases in the core (by default) as far as I can tell, but it is found from some rather popular modules (Minify, FormBuilder). Not sure if this module is even needed on newer installations – just happened to have it installed on a site I'm currently updating from 2.x to 3.x, ran into this issue, and thought I'd mention it in case it will save someone else a bit of debugging time
  11. teppo

    Not really sure where to go from here. The latest error itself seems to indicate that $config->preloadCacheNames is null, so either that setting is missing, or the entire config is not working right. Some things you might try: Make sure that /wire/config.php exists and is readable for your Apache user Check if $config->preloadCacheNames is set in /wire/config.php (value should be an array) Make sure that you aren't overriding aforementioned config setting in /site/config.php I must admit that I don't have a slightest clue about what has gone wrong here, so these are just random ideas. In theory it could have something to do with ProcessWire being installed in a subdirectory (haven't done that in ages myself). According to your server, the PHP version shouldn't be an issue here, and since you're running on Apache, it's unlikely to be a web server issue – at least unless your host has done something strange for their setup.
  12. There should be an "unselect" button next to the selected page. Similar to the select button, this also becomes visible when you hover over the page. If that doesn't appear for you, I'd recommend submitting a new issue at GitHub.
  13. teppo

    That's a pretty good idea right there If that doesn't help, I'd start by checking if /wire/modules/Inputfield/InputfieldInteger.module exists and is readable to your Apache user. In case you have a /site/assets/cache/FileCompiler/ directory, I'd also clear that, just to be sure.
  14. teppo

    Just chiming in to point out that this sounds like something that might be better solved by the Field Change Notifier module. I'm not sure what the state of said module is, and it doesn't currently seem to support selecting notified user based on the page being edited either, but perhaps it would be easier to adapt to this need?
  15. teppo

    Sorry for the delay, folks – been a bit busy lately, but I'm now slowly trying to work my way through your reports Version 2.1.6 includes a couple of fixes related to this one: Revision tables are now vertically scrollable. This isn't necessarily a perfect solution, but at least the UI is now usable even if the inputfield itself is very narrow. I've also added some UI hints to signal if/when scrolling is expected. InputfieldColumnWidths() is triggered after showing/hiding a revision table, so the first thing mentioned here should be fixed now (hopefully). I couldn't reproduce the 1px overlap. Might've already fixed that one, or perhaps I just wasn't able to recreate the setup needed, but I'll get back to that if it's still an issue. The absolute positioning thing I kind of covered in my previous post (I'd prefer to avoid that), and the panel thing is exactly as mentioned above: they seem to require an URL, which is then opened in an iframe, and that would be a bit problematic (to say the least) for my use case here.