Jump to content

teppo

PW-Moderators
  • Posts

    3,208
  • Joined

  • Last visited

  • Days Won

    107

Everything posted by teppo

  1. A bit of background: rendering partials (using the partial name as method) is a relatively new addition, while including partials with chained syntax (<?php include $partials->common->summary ?>) has been an option since the very beginning. I don't have a strong opinion about what should be the default behaviour, but the main reason why I likely won't change this is that it would potentially break a lot of sites ? At this point I would recommend against partial names with dots or dashes. Personally I tend to use snake_case for naming, as I find that the most sensible option: dashes or dots won't work, and camelCase and PascalCase are prone to errors (although it's customary to use them in class names). It is actually possible to access properties with dashes as well, but it's not exactly pretty: <?= $partials->common->{'summary-block'}(['heading' => 'Hi!']) ?>. Extending $partials->get() with support for paths does seem like a good idea, though, so I'll add this to my todo list ?
  2. Sorry for missing this question — and no, it doesn't seem like intended behaviour. I've made some adjustments to the latest version, 0.30.4, that should make things better in this regard. At least it helped with these exact terms (business/businesses/businessmen) in my limited tests. Please let me know if this doesn't work, or if it makes things somehow worse, though ?
  3. Very good points there and definitely a big thumbs up for this topic in general, but not sure if I can fully agree with this part: Any module that supports Hari's composer installer, Wireframe composer installer, or the official composer installers package will automatically be installed in the correct directory. Technically only requirements are that the module includes composer.json, and is marked as pw-module or processwire-module. If you're using a custom directory structure (like we do), you'll indeed need a config setting in your main composer.json to specify where your modules directory is located — but even then it's a once-per-project thing. Hari's installer doesn't support this but others do, and Wireframe installer will also automatically detect any module's using Hari's installer and override it to make this work. On a loosely related note, in case module authors are reading this: Hari's installer may still be the most popular option, but it's somewhat outdated. It lacks support for Composer 2, doesn't provide any configuration settings, etc. I would strongly recommend moving to more recent (and actively maintained) alternatives. I always add the modules directory to Git ignore, so it's definitely doable. This works out of the box for composer installed modules, and modules that are not installed via composer can still be added to the repository with the -f flag, which essentially makes Git ignore the ignore rule. Only problem would be modules added in a production environment via GUI, but since we're talking about version controlling stuff, this doesn't seem like a particularly relevant concern to me. In case of modules that don't support Composer installation, creating a private fork is of course always an option. This works nicely for commercial modules as well, but requires installing said modules via Git repository (which is a bit clunky), or via private Packagist (which is more elegant, but requires paid plan.) In my setup ProcessWire is installed and updated via Composer. Again doable, but this part could admittedly be more elegant: since the wire directory needs to be in a publicly accessible location, typically you'll need post-install-cmd/post-update-cmd in your composer.json (or something similar) to move / copy said directory from vendor to another location. Anyway, would definitely like to see this topic getting more attention in future releases. And it would of course be great if more module authors would add their modules to Packagist — that would make things easier for Composer users, and setting this up is quite straightforward. ? In WP plugin installs via Composer are — for the most part — solved by wpackagist.org, which mirrors all plugins in the official plugins directory. In a nutshell this means that plugin authors just need to submit their plugins to the directory, and they automatically become installable via Composer (composer install wpackagist-plugin/plugin-name). Having something like that for PW would be an interesting option for sure.
  4. 15 inch MacBook Pro, no external monitors. I'm used to pretty small print — cranking the resolution setting to max space and then decreasing the font size a few times works wonders ?
  5. Talking about dinosaurs... (To be fair I'm mostly just a "late adopter". I don't mind trying out new stuff, but rarely jump to new tools until they've been battle tested first.) IDE: VSCode, with a bunch of handy extensions (PHP Intelephense, Tailwind CSS IntelliSense, SCSS IntelliSense, phpcs, EditorConfig for VS Code, Git Blame, GitLens, Remote, etc.) Emacs when it makes sense to work on the live server, or I just need to make a few quick changes for a local site — though Remote extension for VScode works really well over SSH, so been using that more lately ? Dev environment: VirtualBox or Docker, depending on the project. Some of my own old projects, mostly the ones that I rarely need to touch, I tinker with on the live server ? Staging... is not really a part of my usual process. Changes go from local dev environment to live server ?‍♂️ Syncing between environments: combination of (bash) shell scripts and rsync ? Hosting: AWS for client stuff, Contabo for personal projects. Currently considering switching away from Contabo. It's super cheap, but sluggish. Could be my own making, but I would happily spend a few more bucks a month if it helps. Modules: that's a long list, but development oriented ones are Tracy, Wireframe, and lately ProfilerPro. Other modules I use on pretty much all sites include AdminBar, MarkupMenu, SearchEngine, ProCache, ProFields (particularly Repeater Matrix), FormBuilder, SchedulePages, Redirects, Process Changelog, Process Login History, WireMailMailgun, PrivacyWire ... and a handful of others, many of which were built by @Robin S ? Front-end: Tailwind CSS + build process powered by Gulp. Vue for some JS work, but mostly just plain old JS/ES. With all the goodies baked into the language nowadays, jQuery is obsolete. (Literally have had one case where I wanted to use it in the past two or three years: needed to serialize form data.) What else? Composer for managing PHP libraries and ProcessWire modules, NPM for JS, Git for version control (surprise). Think that's just about it ?
  6. This was in the support area for Repeater Matrix, so not on the public forum.
  7. This was indeed an intentional change in the core. @ryan explained it earlier elsewhere, and provided following snippet (which should be placed in /site/templates/admin.php) for cases where this behaviour is unwanted: if($page->process == 'ProcessPageEditImageSelect') { $editorPageId = (int) $input->get('edit_page_id'); $imagesPageId = (int) $input->get('id'); if($editorPageId && $imagesPageId && $editorPageId != $imagesPageId) { $imagesPage = $pages->get($imagesPageId); if($imagesPage instanceof RepeaterPage) { $input->get->id = $editorPageId; } } } While I get the reasoning (you're editing a Repeater Page, and thus it's logical for images to also be loaded from that same Repeater Page — plus there may be cases where an image gets unintentionally deleted since it's not used in any CKEditor field(s)), I've got a similar hook in place on all of our new sites, since I also find the previous behaviour preferable. Basically it restores pre-3.0.184 behaviour ?
  8. Sorry for taking "a while" to respond, completely missed this message. First of all it looks like this should've been versionControlRevisions() method, not property (my bad). That might've been the issue here. If not, I'm not sure why print_r() returns 1 — I use it very rarely and am somewhat unfamiliar (and uncomfortable) with how it formats stuff. I'd start debugging by 1) using var_dump() or var_export() instead of print_r(), 2) checking with gettype() what type is returned and perhaps get_class() what class if it's an object, and/or 3) using Tracy Debugger to dump the value ?
  9. These seem very much related: there shouldn't be any need to skip over identical (consecutive) entries, since such entries shouldn't occur ? In the latest dev version of the module I have some issues with image fields, where a) adding an image via AJAX is registered as a change, and then b) on page save field content is updated, also registering as a change. This could be related, perhaps? You could check which fields are involved by querying version_control__data and version_control__revisions database tables: the data table is connected to the revisions table with "revisions_id" column, and each row in the data table refers to a single fields_id + property pair, so there may be multiple data rows for each revision row. I'm hoping to get the latest changes (currently in feature-data-objects branch at GitHub) polished and merged to dev, hopefully that will fix this issue as well. Fingers crossed that I'll get there soon. Any changes/updates to this module are pretty time consuming — part of why the feature-data-objects branch exists is to reorganise things, hopefully bringing sanity to the module's architecture ?
  10. teppo

    Snippets

    Version 1.5.0 of the module adds support for selecting users by selector. This should help here. Alternatively it's possible to hook into Snippets::isApplicable() and programmatically define if a specific snippet should be applied. Note that I've also added a warning about page caching: in case (page) content is cached for authenticated users, snippet content may also get cached, which in turn may end up displaying the snippet to even those users it was not intended for. This is not an issue unless you're caching authenticated requests — something that is generally speaking not recommended either way. When you say "default admin uikit styles", do you mean that this button is only loaded in the admin? Usually admin styles wouldn't be loaded on the front-end of your site at all. If this occurs in admin, it might be some kind of issue with permissions / loaded modules. Very hard to say without understanding the full context here. Anyway, I would definitely check for JS errors and missing styles first. From what I can tell at this point, this does not sound like an issue with the Snippets module, but rather something else on your site.
  11. Thanks — it's been a few years, but I would expect results to be somewhat in line now. Though we can always run a new poll if that makes sense ? In my experience... experienced users are likely to use the blank profile or have a site profile (or a prebuilt starter site) of their own, while new users would find a simple starter site profile — one that looks like a real site but is still unopinionated — valuable. Regardless of whether we end up bundling a new "simple" site profile, I think this would be a good idea. Assuming that it can be done in a way that makes it reliable, flexible, and most importantly secure. As Ryan pointed out, installing site profiles from the directory has some interesting security implications: if they can be installed during the normal install flow, any issue with them will directly reflect to ProcessWire itself ?
  12. Whether it's via RM or some other method, having proper support for handling migrations in the core would be huge ? One thing I miss from WordPress is the ability to define data structures programmatically. It's nice to be able to store such definitions in Git, share them among developers, modify or roll them back with ease, and then deploy to any number of environments automatically. The contexts are of course different: custom fields and custom post types have no real table structure(s) per se, so certain things are very easy, while others are very hard (or inefficient). Pros and cons ? From my point of view RM and Composer both have their use cases, and neither can replace the other. Where RM and Composer overlap is mostly just installing modules and perhaps managing core updates. While one can run all sorts of stuff with scripts or installer modules in Composer, it's not really intended as a tool for creating, implementing, or rolling back migrations.
  13. Same thing here. Perhaps all foreign (or european or extracontinental or something) traffic is automatically blocked? (Which of course might be a good idea if the site gets a lot of traffic and actual users are very likely local...) Either that, or there's a slightly overprotective set of rules in place ?
  14. teppo

    Snippets

    Hey @stanoliver. Are you trying to render the snippet on the front-end only for logged-in users? If so, I've just added an option for that to the latest version of the module (1.4.0). Users to render the snippet for (all, logged in, or non-logged in) can now be selected via snippet settings. Let me know if I misunderstood your question, though ?
  15. Agreed, this is kind of annoying. I don't run into this too often nowadays since I tend to keep only those files open which I currently work on — and usually all of them are visible at the same time, with the editor split into 2-5 columns/rows — but your suggestion makes sense to me. I'll look into this ?
  16. Thanks for the clarifications, Ivan. At the moment the <?= $partials->sublayouts->sublayout_name() ?> approach is probably the closest alternative one to what you've been using. Or, alternatively, you could split common parts of the layout to partials, and include those in two different layouts, leaving out the layout/sublayout separation altogether. That being said, I just mocked up locally a setup where layouts can be embedded within layouts. This is probably even closer, though I feel like it needs a bit more polish and testing ?
  17. Not sure how common this sort of practice is, but we always define custom colours for each project — usually with generic names such as brand-1, brand-2, etc. (unless the client has named colours or a lot of colours, in which case more specific naming helps). In fact in most cases I only use two colours from the default palette: black and white. Everything else (including shades of gray) are either custom colours, or just black/white with specific opacity applied ? Same thing goes with paddings: while we use the default spacing scale, there are always a few "project specific" values; half, single, double, triple, etc. Usually these are pretty straightforward (single = 1rem, etc.) but sticking to predefined, named values does make it a tad easier to make changes later. I don't think there's a built-in way for this. Depending on the specific use case I'd probably pick one of two options: If it's just a few colours etc. that need to change, add those to the shared theme config file for the site and handle the "colour theme" in code. If there are a lot of changes and/or for some other reason you want to clearly separate styles for different parts of the site, create a separate Tailwind config file and adjust your build process accordingly. How that would work depends on what kind of build process is in use, but generally speaking it shouldn't be too difficult ? If you google something like "tailwind multiple themes", you'll probably find other solutions as well. I've never needed this type of functionality, so haven't given it much thought.
  18. I've been using Tailwind for years, yet there are still both those days that I really enjoy using it, and others when I wonder if it really makes sense, so I get what you're saying. Also: even though we use it for just about all of our projects nowadays, we often combine it with "custom" CSS classes (mostly BEM style), simply because Tailwind isn't always the correct tool for the job ?‍♂️ Others have probably said it already, but for me/us the benefits of Tailwind boil down to... super fast development, particularly when mocking things up / designing in the browser, common set of tools and guidelines, which is very nice when working in a team (having to dig into an older project that doesn't use Tailwind is a bit of a pain), and superb efficiency — by which I mean that using Tailwind results in very small CSS files, in most cases much smaller than I would get by writing my own vanilla CSS. There are a couple of things I'd view as downsides: a) markup becomes entangled with styles, and b) sometimes it feels like I'm just learning alternative ways to do the stuff I would already know how to do with vanilla CSS. First one is something that, in my opinion, can't be completely avoided, but using components for shared sets of classes helps a lot. Second issue becomes less of an issue day by day. Other than that, I'm quite happy with Tailwind, and it suits my workflow very nicely. It's not the perfect fit for everyone (or for every project), and that's fine too ? "What about keeping the main layout styling in vanilla css and put only utility classes for final layout tweaking?" Well, we use a combination of custom CSS and Tailwind already, but the literal "layout" part is one that's actually so efficient to do with Tailwind that I wouldn't bother doing it in vanilla CSS anymore. In my experience changes to the layout are often easier to implement with Tailwind than with vanilla CSS, and the resulting markup is actually quite clean. "Having said that, how many percent of all the available tailwind utility classes are really going to be used?" It doesn't really matter how much of Tailwind I / we use. Thanks to the tree shaking logic the "compiled" result only includes what is necessary. There's zero overhead in having a large toolbox but not using each tool for every project. "That brings me to the idea to sort out only the most useful ideas and classes from Bulma, Spectre and Bootstrap and bring them in your own utility class framework. That would make things certainly more effective." Exactly how would this make things more effective? We're in the business of building custom sites and/or applications, so pre-built components offered by a front-end framework won't help much (if at all), at which point — from my point of view — all Bootstrap and likes can offer is a very limited set of utility-first tools. Sure, we use prebuilt tools elsewhere (Vuetify for PWA apps etc.) but for custom-built sites Tailwind is (IMHO) a better fit.
  19. Just a quick heads-up: https://tailwindcss.com/blog/tailwindcss-v3.
  20. Hey Bernhard! First of all: congratulations, this looks and sounds like a brilliant project. And thanks for sharing all those details, always love to hear how things were actually solved ?? Your site search is something I'm curious about, so hoped you might shed some light particularly into the part about sorting. How did you go about that? Do you store the index content on PW fields, or do you have a custom data structure? Do you trigger multiple queries behind the scenes, or did you manage to handle sorting in a single query, in the database? Any SQL involved? Asking partly because this is a kind of a long standing issue / todo item for the SearchEngine module. Weighing is relatively simple to do with custom database tables / queries (or rather there are existing formulas for that), but with selectors... well, it's tricky. By which I mean that I haven't been able to figure it out yet without a) custom SQL queries or b) expensive in-memory operations. And yes, I'm kind of fishing for good ideas here... ?
  21. If I got this right, you've got a three-layer approach (layout - sublayout - view) instead of Wireframe's regular two-layer design (layout - view). If so, this is not really something I've had much need for before, but here are a couple of rough ideas: If you have, say, "single column sublayout" and "two column sublayout", you could include the content that you'd usually put into these directly in the main layout file, accompanied by some sort of switch. For an example you could pass an argument to the layout via the bootstrap file (or from the Controller class), stating which sublayout you want to use for current page/template, and then just include related if statement in the layout file. This is, of course, not a very clean solution if sublayouts differ a lot from each other. But if the differences are minor and/or sublayouts are relatively simple, then introducing a whole new layer might be overcomplicating things a bit. You could use partials: instead of directly including <?= $placeholders->default ?> in your layout file, you could call <?= $partials->sublayouts->single_column() ?> etc. and thus mimic that extra layer. Of course this still requires some method of defining which sublayout to use for each template or page. Now, one thing I don't fully grasp is that how do you decide which template(s) use a specific sublayout? If I knew that, I might be able to suggest better solution. Would also be interesting to hear a bit more about what exactly is in the layout vs. sublayout. This might be something that we could support in Wireframe right out of the box — though before that I'd like to fully understand how it should work, and what is / what are the problem(s) it solves ?
  22. Hey Bernhard. Just to confirm: do you mean that the corrected image rotations array didn't fix the issue for you? If so, did you have client side image resizing enabled, and did you try if disabling that makes any change? PM'd.
  23. The link abstraction part sounds a lot like https://github.com/processwire/processwire-issues/issues/1244 to me. Just cross-linking for reference.
  24. Hey @horst — sorry for pinging, but I'm pretty sure you're most likely to know what's going on here ? So, I've been having similar issues with one site, where there are a lot of profile pics etc. Quite often uploaded images are not correctly rotated by ProcessWire. It's not super common issue, but common enough to cause major problems for admins. Now, one pic which I'm currently testing (I can share a link if it's important) reports EXIF orientation as 8: Based on our built-in corrections array, orientation 8 should be rotate 90 degrees (clockwise, I presume). Based on some other sources, such as https://www.impulseadventure.com/photo/exif-orientation.html, orientation 8 actually requires 90 degrees CCW (or 270 degrees CW). Am I reading that source wrong, or is there a mistake? The array provided by @bernhard fixes the issue for me, and seems to be in line with at least that single source. I am not well versed in this topic, so be kind; I may be entirely missing the point here ?
  25. Hey @Ivan Gretsky No reason whatsoever — probably just forgot. Submitted ?
×
×
  • Create New...