Jump to content

teppo

PW-Moderators
  • Content Count

    2,216
  • Joined

  • Last visited

  • Days Won

    43

Everything posted by teppo

  1. 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.
  2. 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/
  3. 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.
  4. 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
  5. @Thomas108: this is a Textformatter module, so you need to enable it via field settings: Setup > Fields > your-fieldname > Details > Textformatters.
  6. @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!
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. I think you're looking for something along these lines: $data = file_get_contents('php://input'); See https://stackoverflow.com/questions/8945879/how-to-get-body-of-a-post-in-php for more details. And no, to my best understanding this is not something that $input API var handles
  15. Having built a number of complex projects with tens or hundreds of thousands of pages with ProcessWire, I can say for sure that ProcessWire works very well for all sizes of projects. That being said, it seems to me that your current use case does indeed differ quite a bit from how ProcessWire works right out of the box, and in that case it shouldn't be such a huge surprise that in order to get exactly the result you want, you'll need to modify the system in one way or the other. My point is that it's simply not feasible to add settings for every single use case one might face – and since we're talking about a system such as ProcessWire that already provides a ton of hooks that allow you to modify its behaviour programmatically, there's really no need to do that either. Im not trying to deny that what you've suggested here makes sense, at least in your context, but that's still just one of the million use cases for ProcessWire. Some things to consider: As others have explained above, in ProcessWire "admin pages" are Process modules. Creating a new Process module is surprisingly simple, so rather than customizing the Page tree I'd really suggest that you give them a try and then consider hiding the Page list for roles that don't need to see it. Like LostKobrakai pointed out above, depending on your permission related needs you might be able to get by with one of the third party modules already available – in your case I'd suggest checking out Dynamic Roles and UserGroups. You've mentioned that Page list should be paginated, and it already is. By default pagination is set to display 50 child pages (I think) before paginating the rest. This setting can be tweaked via ProcessPageList module settings. If you have any specific questions, please let us know – we're always happy to help. That being said, if you're going to expect for the system to cater for every possible use case right out of the box, you're definitely going to be disappointed. Just like you'd be with any other CMS, for that matter
  16. Thanks @Robin S, I'll take a look at these ASAP. Part of the reason the new UI works as it does (in context, not overlay) is so that it could play nicely with some admin theme quirks and differences. Another reason is that overlay UI's are a bit of a problem from usability point of view, so I'd rather steer away from them. Anyway, I'll see what I can do about these. The part about checkbox is a bit of a surprise to me. This also means that other icons, such as the default "collapse" icon, disappear when the field gets expanded, right? Seems weird to me, but perhaps that's how it's supposed to work. Not sure how I managed to miss this earlier
  17. @maxf5, I have just removed certain remark from your earlier post as a moderation action. Also my apologies to @cmscritic – you definitely shouldn't have to see that kind of language here. A friendly reminder from the moderating team: please keep the tone of discussion polite. Crude or discriminative remarks and insults of any kind will absolutely not be tolerated on this forum. As a community we're committed to keeping this forum a safe and welcoming place for everyone. Think before you post.
  18. Unless my memory fails me, all I did was add support for multiple answers and user-submitted suggestions. Might've made some general purpose (JavaScript/CSS?) tweaks too, not entirely sure anymore. Once the current version stabilises, i.e. I know whether the updates from @BitPoet get merged in, I could set up a new PR for these
  19. Thanks for letting me know. Self-correcting issues, what fun
  20. @adrian, I'm not seeing that issue here. Any chance you could check your login page for a hidden input with name "javascript" and value "1"? This is how LoginHistory knows that you've got JS enabled, so if that's not there, then it's probably going to report it wrong. Then again, if that doesn't exist, it shouldn't be able to get screen and window dimensions either (are those missing too?) You're not using a custom login form, are you?
  21. I might be in the minority here, but at first I had absolutely no idea what an "input mask" is. This cleared things up nicely: https://css-tricks.com/input-masking/. Seems like a nice addition – either for the core, or as a third party module.
  22. Got to agree with Kongondo: if that is doable for you, i.e. both sites sit on the same server, bootstrapping ProcessWire is probably your best bet. Otherwise I'd recommend checking out the REST API site profile and/or ProcessGraphQL. To my best understanding both provide the ability to create content via the API, and both have some sort of authentication mechanism available. Authentication is basically the main thing here: it's really easy to create a ProcessWire page that takes POST requests and creates pages etc. but you don't want, under any conditions, that to be publicly available without some sort of authentication. This is why I'd recommend checking the existing solutions first, and only rolling out your own solution if it's absolutely your only option
  23. The steps I can think of right away would be... Moving the site files to the server. This is should be quite straightforward: use the scp command, or an SFTP application, or whatever you prefer. Just get the files to the production server somehow. The database part depends a bit on the tools you have available, but basically you need some way of exporting it as an SQL dump from the dev server to the production server. If you're familiar with command line tools, mysqldump is one way to do this – here's one guide for that. If you have a tool like phpMyAdmin installed, it has tools for both exporting (on the dev server) and importing (on the production server) SQL dumps. Note that you may have to create the database and related MySQL user on the server beforehand. This, again, depends a bit on your particular server setup. Check your /site/config.php on the production server and make sure that the domains and database credentials in there match the ones you're using in production. ... and that's pretty much it, I think. Hopefully I didn't forget anything important – my own process is a bit different, so I don't really do this that often Obviously there will be some more generic things to take care, such as connecting a domain to your production server, and so on and so forth. For these I'd refer to any instructions your hosting provider might have.
  24. @Robin S: it's the latter case. I had originally some weird issues with image fields and such, but got those fixed at the last minute, so was a bit worried that there might be other issues I just hadn't noticed yet. Also the UI of the 2.0 branch could be a bit unstable: I've been moving things around, trying to figure out what works best, and I'm still considering rebuilding the History tab from the scratch. That being said, if you're using PW 3.x, I'd definitely recommend going with the 2.0 branch. Current master branch works fine with PW <= 2.7, but not so much on 2.8 or 3.x. Also, if you do run into issues, please let me know so that I can take a closer look at them
  25. teppo

    WirePHPMailer

    @ukyo: first of all, thanks for extending WireMail. I think this makes your module more useful in the long run. Now, sadly there's a bit of a downside to this: a week ago Ryan pushed an update to the dev branch (related to this issue) that changed the way WireMail modules are found by the core. In short, the class name must now start with "WireMail". One can get past this auto-detection feature by manually specifying (in a config setting) the name of the WireMail module to use, but in order to work optimally both now and in the future, I'd still consider renaming this module to something that starts with "WireMail". Thanks again, and sorry for the trouble
×
×
  • Create New...