Jump to content

teppo

PW-Moderators
  • Content Count

    2,423
  • Joined

  • Last visited

  • Days Won

    64

Everything posted by teppo

  1. Something along these lines would be great! Nitpicking, but I wouldn't use an icon alone (for accessibility and usability reasons), but other than that it's definitely a feature I'd be using. Idea for a module? πŸ™‚
  2. Couple of related issues: https://github.com/processwire/processwire-requests/issues/144 https://github.com/processwire/processwire-issues/issues/703
  3. The limit of 128 characters has been in place for many years now. Personally I don't see a huge issue in raising it, or at least allowing longer names but making this an optional feature, but in the end that's a decision for @ryan. You can always open a new issue at the processwire-requests repository, requesting support for longer page names and explaining your use case and need for these. I can't remember if the reason for this limit has been discussed before. Browsers have some kind of limits in place, but these days those should be pretty much a non-issue as far as I can tell. Database level scalability probably shouldn't be a massive issue here either. That being said, I must add that this might be the first time I've heard anyone requesting longer than 128 character page names – so while it may seem messed up to you, it seems to me that your use case is actually not a particularly common one. In fact for most sites page names longer than 128 characters would very likely result in usability issues, and – just for an example – for the sort of projects I usually work on I definitely wouldn't want to allow that. 128 characters is already much longer than what makes sense πŸ™‚ As for workarounds, depending on your use case you might be able to use URL segments here instead. That's just one idea, though. The name field in the pages table is varchar(128), so that's at least one place that will enforce the limit.
  4. Actually the fix/change @dragan mentioned above was about URL segments only. Page names are still limited to 128 characters as far as I can tell.
  5. WP core doesn't have built-in multi-language features like that, and the way popular multi-language plugins (Polylang and WPML) handle this is by duplicating a page or post, which means that technically one post never has more than one URL – so yeah, this is a non-issue in the WP world.
  6. I'm in the "URLs should never change" camp myself πŸ™‚ To clarify: page names should remain constant even if titles are changed, and it's a good thing that they do – for UX, for SEO, and for various other reasons as well. While automatic redirect from old URL makes things better in some ways, it still isn't nearly as good as a constant URL structure. That being said, one problem I've ran into quite often is that name is (by default) "hidden" on the Settings tab, and I've never had much luck in explaining to non-technical clients that the Settings tab indeed contains values that should sometimes be changed (or checked after making changes). So yeah, cloning is indeed one of those actions that quite often result in nonsensical URLs. But since (unless I'm missing something here) built-in clone feature doesn't allow changing (or setting) the title while cloning the page, there's currently no intuitive way to handle this. If cloning did ask for a new title, it would make a lot of sense to redefine the name based on that new title as well, but changing it after the page has already been created is not such a great idea (in my opinion). Just for the record the way WordPress displays URL ("permalink") below title but still as a "non-editable by default" field (i.e. there's a separate edit button) is, in my experience, a good compromise: this way it's much harder to miss, but still "less prominent" and clearly not just a regular field among other regular fields. ... but that's probably a sidetrack here.
  7. Yeah, edited my message as well. Didn't read the original question properly, thought it was only about templates. Just gave these both a try and so far they seem to work – though this is a rare use case, so wouldn't be entirely surprised if there were some gotchas along the way πŸ™‚
  8. Don't think I've ever used this, but according to the ProcessTemplate core module the template part should be possible if you create a new "template-admin" permission and assign it to any non-superuser role. Based on a quick test it seems to work. ProcessField supports similar "field-admin" permission, which might give you the expected result regarding fields. This does seem like a rather unlikely need, so I'd first check if this is really what you want. Certain tasks are limited to superusers for a good reason πŸ™‚
  9. What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead. The general rule of thumb is to always sanitize user input πŸ™‚ That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.
  10. I'm not entirely sure about the "non well formed numeric value" problem, but your version of ProcessWire (3.0.32) actually predates our current GitHub repository, which means that it's ~3 years old – I wouldn't be too surprised if this was something that has since then been fixed. Of course it would require a bit of testing, but I'd suggest updating your site to a more recent version if possible. Countable notices are also problems that have been fixed in the dev branch, see this issue: https://github.com/processwire/processwire-issues/issues/408. If it's the same issue, this is due to a change in PHP 7.2, where they changed the count() behaviour in a backwards-incompatible way. Note that at least some of those countable-related fixes are currently only fixed in the dev branch; in the case of ProcessWire the dev branch tends to be quite stable, but if this is a production site you may still consider living with some of these warnings until these fixes are merged to master.
  11. I wouldn't necessarily recommend making www-data the owning group of the entire directory, but that's just me. As long as the group doesn't have write access to all files, that doesn't really make matter a whole lot. Technically Apache only needs write access to /site/assets/, and (if you want to use the built-in modules installer in Admin) the /site/modules/ directory. (Latter is something I personally never allow, as I don't think it's worth the risk.) Anyway, in my opinion the setup you've described above should be safe. When configuring the permissions of a system like this, there are always two important factors: Are there other users in addition to you who have access to the system, i.e. is it a shared system? If so, giving "others" write/read/execute permissions can sometimes be problematic, as it could technically allow any logged-in system user to access those files – though in shared systems some sort of jail mechanism is usually implemented to prevent this. Also, I'm assuming that this isn't the case here, since you've mentioned setting up the server yourself. The Apache user (www-data) is what most "third parties" will technically access your site with (through the web server). While ProcessWire is known to be exceptionally secure, it's still a good idea to limit the excess to which this user/group can access (and particularly write to) content on your server. For an example, I prefer not to give www-data write access to directories that contain executable code, such as /site/modules/ (as mentioned above). In the case of ProcessWire www-data needs write access to /site/assets/files/, or at the very least specific directories below it. It also needs read access to most files on your site. So yeah – your settings make sense to me πŸ™‚ This is strange: it seems that a file or image field on your site is saying that the assets/files/ directory it's trying to write to is not writable. I'd start by checking which user/group is the owner of the /site/assets/files/[page ID]/ directory, and if it's writable for www-data. Same thing for the /site/assets/files/ directory. Alternatively: is it possible that sometimes the user actually isn't www-data? Just guessing here, since I'm not familiar with your particular setup. Edit: just realised that in your message above you mentioned adding chmod 664 to all files within /site/assets/. Please make sure that group has write access to directories as well – otherwise you'll no doubt run into problems.
  12. Actually the API provides access to the hashed password. If this password hash (the one you use for your secure URLs) needs to remain constant, I guess that's as good approach as any – mash some non-public variables together, generate a hash, and then check if the user has provided the correct hash. If you're looking for a ready-made solution I'm not aware of one, but on the other hand this sounds like something you could put together in a few lines of code, so not really a massive problem. The specific implementation depends on how your site is built, but technically you just need to add a bit of code somewhere before any markup is rendered – check a GET param from $input->get->token_var_name, and then compare that to a correct token (or one stored in user details – more about that in the list below). I would probably use URL segments here, so that first segment contains the username and second one the token, though. If there's a match, do something (display page content), otherwise throw a Wire404Exception (preferable over displaying a clear message such as "wrong token"; you don't want third parties to know even if they got the username right.) Some additional steps to consider, mainly for security reasons: Instead of calculating the token on the go, you could generate it automatically for every user, and store it in a custom field added to the user template. This way you can also include random data in the original hash, which means that it cannot, under any circumstances, be used to uncover (hashed) passwords or any other type of sensitive data. Note: this would still mean that the token is stored in the database as-is, which would become a problem in case this information ever leaks. Technically the safest thing to do might be to send the private token to the user, and never store it as-is, but rather convert it to a hash using a salt and then store those locally πŸ™‚ Add some sort of brute force protection to the page, i.e. after a few incorrect attempts block the IP for a while. Preferably refresh (recreate) tokens after a set amount of time. This may not be particularly important, but personally I believe it's a good practice in these sorts of situations. Provide a way for users to change (reset) this key, in case there's a chance that someone else has gained access to it. Preferably this new key should also be randomly generated, so that users cannot manually type in a weak key. Use username or some other value in the URL itself, so that keys become much harder to guess (via brute force attack) – but also make sure that third parties can't use these URLs to collect a list of existing usernames πŸ™‚ ... although the security level of course depends on the type of information you're providing via this calendar. If it's not particularly sensitive data, then it won't be such a big deal, but if there's a chance that it may, for an example, contain personal data, then definitely take every possible precaution.
  13. The easiest approach might be setting the owner of the whole /site/assets/ directory (and everything in it) as the Apache user (www-data:www-data). If you want to retain easy write access to those directories (without sudo), you can set your own user as the owner, the owning group as www-data, and change the permissions for that directory to 664 instead of 644 – though depending on your setup when www-data creates new files and directories, it will likely overwrite the owner for those files anyway. Usually this isn't a problem, though, since you shouldn't upload files to /site/assets/ manually, and even then it would only be limited to files that www-data is already managing πŸ™‚
  14. Thanks for pointing these out. Latest release (2.1.0) includes improvements to spacings and the position of the triangle. Just for the record, the positioning is of the triangle was actually intended to be consistent with Admin Theme Uikit, where it's also off-centre, but I've now centered it in Admin Bar anyway πŸ™‚ In 2.1.0 the problem with "add new" button has been fixed. My initial idea was indeed to leave these buttons out if they have no purpose, but opted to leave them as-is, because that's how it's always been. For the same reason I was slightly hesitant to remove the full stop: this change will break existing translations. I've now done it anyway, since it's a relatively small thing. Note that 2.1.0 is actually bigger update than I anticipated. Class names have changed a bit, all themes had to be updated slightly, there's new JS, layout is now based on flexbox instead of floats, etc. So far things seem to work as expected (better than before), but let me know if there are any new issues πŸ˜…
  15. Yeah, this should be an easy one. You can hook before or after AdminBar::getItems: either modify $args['strings'] before it gets passed to the method, or modify the resulting array of items before it is put to use πŸ™‚ Makes sense. I would definitely take a route that affects actual permissions. Since AdminBar checks Page::editable() before displaying the edit link, if this was done using permissions, I believe it should just work out of the box, i.e. the edit link shouldn't display at all πŸ€”
  16. Thanks, @adrian. I've been using this module for a long time, and it has actually been quite fun to work on it πŸ™‚ A profile edit button seems like a good idea. That was on my list for a while actually, but I wanted to get 2.x out sooner rather than later, so had to leave that for a later release πŸ™‚ I think we'll also need a "select enabled links/features" option to avoid too much clutter. On many (most) of the sites I've built this feature, for an example, profile edit feature wouldn't have been particularly useful – users often edit their profiles really, really rarely – so I'd like to leave it to superusers to figure out which features are necessary. (Could also make the feature selection configurable per user, if there's demand for such a feature.) Restricting editable pages to ones the user has created seems to me like a relatively specific need – at least I haven't personally come across a project where this would've been particularly useful. As such, my initial view is that this might be best implemented as a per-site customisation. Unless, of course, I'm wrong and it's actually a commonly needed feature, in which case it may make sense to add a setting for it πŸ™‚ Note that one key point about the hooks I've added is that it's now quite easy to customise what is displayed in the Admin Bar, and how. One example of this is what I've done with the "Uikit" theme, where I've added icons to existing items, and also the PW logo/mark as a new item. If you hook into AdminBar::getItems, you can easily modify the list, and – for an example – only show the edit link under specific circumstances. (And if this is a feature you require often, you can always bundle this, and any other modifications, into a separate module.) By the way, I'm assuming that this would actually be just about displaying the edit link – not modifying permissions? Modifying permissions would, in my opinion, definitely belong to another module. As far as I can tell, this item has been "Browse" since the beginning – at least for the past 8 years or so, according to GitHub πŸ™‚ I'm slightly hesitant to change what I consider established terminology. Also, I don't personally see the problem: technically what this item being active means is that you're currently browsing the site. Kind of like "browse mode" vs. "edit mode". When you're in admin and want to view a specific page, "view" is indeed better word, but in this context I actually prefer "browse". Again it's quite simple to modify this with a hook, of course, but I think I'd rather stick with current terminology for the default state.
  17. It's quite possible that I've misunderstood what you're saying here, but if by "restricted permissions" you mean current settings (755/644), then I don't really see a problem here – as long as the Apache user (apache, www-data, or whatever it is called in this case) is the owner of the FileCompiler directory and compiled files are created by this user (via web requests), it should work just fine πŸ™‚
  18. AdminBar 2.0.1 released: Plenty of updates behind the scenes. So far "end user" functionality remains largely the same, though. New options for hooking – decent support for modifying generated output and adding all-new links and other features programmatically. Extended theming support: the module now comes with three built-in themes ("original", "tires" per the theme submitted earlier by @tires, and "uikit"). Uikit is an adapted version of the top bar in admin, and it's now the default theme for the module. Each theme may include its own settings (Uikit, for an example, allows displaying/hiding some or all of its icons and the ProcessWire mark). Custom theme support is still there, but requires a few modifications: custom theme needs to be selected via module config screen, you need to provide a directory where theme files live, and this directory has to contain (at least) a theme.css file (but optionally also theme.js for custom JS, theme.php for hooks, and config.php for custom module config settings). Oh, and the module is installable via Composer now – just run "composer require teppokoivula/admin-bar" in your sites root directory, or the /site/ directory. New requirements for 2.0.1 are ProcessWire >= 3.0.112 and PHP >= 7.1.0. For earlier version of ProcessWire or PHP, use release 1.1.5 (this version won't be updated anymore, but should work in ancient version of PW and PHP). Below is a screenshot of the "Uikit" theme in action on the Wireframe website. In this case I've disabled the icons from the left side of the Admin Bar – by default each action there would have its own icon as well.
  19. 644 means that only owner is allowed to write to the files. I'd start by checking if you already have matching files (the ones mentioned in the warnings), and if so, which user is set as their owner (and if the permissions to said files is really 644). In case the owner is not the same as the Apache user, that's likely the problem here. If you've migrated these files with the site, a safe bet would be to clear everything within the FileCompiler directory to get a "blank state" – but if permissions are too strict, that obviously won't help for long. (Note: if you sometimes run ProcessWire via CLI using the bootstrap method as another user, that can also result in these compiled files being owned by the user you've executed that CLI command with, which can cause similar issues.)
  20. Not an answer really, but technically just having ProCache could help with situations like these. The idea is to bypass PHP and MySQL entirely, after all. In fact in the past I've had a situation where MySQL was dead but the site I was monitoring kept working due to ProCache, so the issue didn't become apparent for quite a while... πŸ˜… Another thing to consider would be something like Cloudflare ("always on" feature in particular), or adding Squid or Varnish (or some other proxy/cache/accelerator) in front of the site.
  21. If you update to module version 0.9.0 (latest release), you can πŸ™‚ More details here: https://github.com/teppokoivula/SearchEngine#rebuilding-the-search-index. Note that indexing the pages is also possible via module config screen. There's an option for "Manual indexing", where you can either index all indexable pages, or those matching a specific selector.
  22. Added a note about new maintainer to the top of the first post, and updated the "grab the code" link. Might make some sense to rewrite the first post altogether, but the forum doesn't (as far as I know) allow replacing it, so creating a new support thread might make sense as well πŸ™‚
  23. Makes sense to me. To be honest the two things I was mostly worried about with Tailwind were repetition and consistency, but the component approach should definitely help with that πŸ™‚ I wouldn't really describe Foundation as a full design, because the "normal" workflow with it involves more configuration than overriding. That's the main reason I preferred Foundation over Bootstrap and early versions of Uikit: "randomly" overriding what someone else was already doing always felt dirty, and at least in my experience (based on maintaining Bootstrap sites built elsewhere) was somewhat prone to problems... particularly when things had to be updated "upstream" to fix problems within the framework itself. Haven't been keeping tabs on frontend frameworks lately, but at least Uikit seems to include something similar these days with their SASS/LESS builds πŸ™‚ We've been crafting styles mostly from scratch. We have what you might call a frontend framework, but it's relatively unopinionated – mostly just stuff like common file structure, build process, font size management, image helpers, and some utility features. One of the benefits of that approach is that each site gets exactly the styles it needs, while one obvious downside is that there's a lot to do. In my experience this approach works well for very large or very simple projects: you're essentially building your own component library for each site, so you need either big enough budget, or reasonably narrow scope.
  24. Some updates for AdminBar in the latest release (1.1.0): Got rid of the jQuery dependency. Not a big deal, but that's still one setting and one dependency less. As a result the module probably won't work as expected in IE < 11, so if someone is still stuck with ancient browsers, it's better to stay with version 1.0.7 (tagged in the GitHub repository). Some minor optimisations and tweaks here and there. Nothing major, really. Just tested @tiress styles, and they seem to still work as expected, so most custom themes are likely unaffected πŸ™‚ For the record, I'm thinking of releasing a 2.0.0 of this module pretty soon. This would be a breaking change, and require ProcessWire 3.x, PHP 7.x, etc. I'm also thinking of moving custom styles out of the module directory so that the whole directory can be safely removed during updates.
  25. I should definitely give this a proper try πŸ™‚ I was actually writing a longer question here, but then I found this: https://tailwindcss.com/docs/extracting-components/. One of the benefits of BEM approach has been that when a site has been designed with components in mind, it's easy to start from the lowest level ("button looks like this"), and then re-use the same element. For big sites in particular this is quite nice, while you can still create variations of those elements for use in specific situations (.button--cta, .button--success, .button--click-to-call, etc.) It looks to me like you achieve a very similar result with Tailwind. Please correct me if I'm wrong, though πŸ™‚
Γ—
Γ—
  • Create New...