Jump to content

ryan

Administrators
 View Profile  See their activity

  • Posts

    16,714

  • Joined

  • Last visited

  • Days Won

    1,515

 Content Type 

Everything posted by ryan

  1. ryan
    For those particular cases, your strategy seems fine, since the site/page/?forgot=1 and site/page/?register=1 are entirely different content from site/page/ without the query string (I'm presuming, as it looks like LoginRegister). Another way would be to block them with a meta robots tag in your document <head>, i.e. if($input->get('forgot') || $input->get('register')) { echo '<meta name="robots" content="noindex, nofollow">'; } Or, you could just deliver unique title tags, and omit the meta description tags, for those cases. But that would take a little more code, and these page variations presumably aren't useful to search engines anyway. So I think what you are doing, or the solution above, is a good way to go. For other cases, where the query string doesn't indicate entirely different content (such as a GET var that changes the sort of a list, or something like that), you'd probably want to use a canonical <link> tag. This will tell the search engine that the request can be considered the same as the one given in the href attribute. And the URL in the href attribute is the canonical, or main one. This will prevent the Google Search Console from flagging duplicate titles or meta descriptions on the query string variations of the page. <link rel='canonical' href='<?=$input->httpUrl()?>'> Btw, the $input->httpUrl() includes URL segments and pagination numbers (when applicable) so is more likely to be preferable to $page->httpUrl() when it comes to canonical link tags.
  2. ryan
    I think that's a good idea. Though I'm not sure we've got enough existing material on the forums to warrant creating a new board for the purpose just yet (?), but would suggest maybe the Pub or Beer Garden as a good place for now. We can always create a new board when the amount of content reaches a critical mass, which is the strategy we've been using so far. I don't think we can support video uploads here, though embedding from YouTube/Vimeo is a good way to go for this.
  3. ryan
    I think they are referring to a Drupal setting that maps to CKEditor's config.fullPage, for editing a full HTML document? That's not something we use. Though it's possible I'm missing something. I noticed CKEditor 4 is now up to version 4.9.2 (we are on 4.8.0). Maybe they have fixed the issue in CKE. I'm going to update to 4.9.2 in PW core 3.0.107 this week, hopefully that'll help.
  4. ryan
    I've been traveling in the second half of this week, so will release ProcessWire version 3.0.107 for next week. This week we look at the WordPress vs. ProcessWire series of videos by Jonathan Lahijani. We talk with him about the how the videos are made, what inspired them, what’s been learned, platform strengths, future plans, and more. https://processwire.com/blog/posts/wordpress-vs-processwire/
  5. ryan
    I've run into this problem on a client site before. I was never able to duplicate it myself, but noticed there were style attributes ending up in the CKE field of my client's site somehow, and the client said they pasted from Word. I don't have Word, and I'm not observing the issue occurring with pasting from anything else, so there must be some Microsoft trickery going on, who knows. I don't understand why CKE's ACF allows it. It does seem like a CKE bug. I'm sure it's possible to configure HTML Purifier to remove that stuff, but haven't looked too closely into it. While there is a way to force CKE to paste as plain text (see thread that flydev linked), I don't really like losing links and normal CKE formatting when I paste, because I'm often pasting from one CKE field to another, and having to redo all the formatting is a pain. Usually if I want to paste as plain text, I just use SHIFT-CMD-V on Mac (SHIFT-CTRL-V on PC), as this is a pretty universal way to paste as plain text, anywhere. But the reality is, clients aren't likely to remember it, and many are doing Edit > Paste, rather than using the keyboard. I'd rather not have the client have to think about whether they need to use plain text pasting or not. A simple way to remove style attributes from CKE fields is to hook after the process input, look for them, and then remove them. This hook at the top of your /site/templates/admin.php file should do the trick: $wire->addHookAfter('InputfieldCKEditor::processInput', function($event) { $inputfield = $event->object; $value = $inputfield->attr('value'); if(strpos($value, 'style=') === false) return; $qty = 0; $value = preg_replace('/\bstyle=(["\'])([^\1]+?)\1/i', '', $value, -1, $qty); if(!$qty) return; $inputfield->attr('value', $value); $inputfield->trackChange('value'); $inputfield->warning("Stripped $qty style attribute(s) from field $inputfield->name"); }); Word may be adding some other weirdness too, but I don't have a good example to look at to know what else there might be (MSO-specific class names?). In any case, we could probably remove it in a similar manner.
  6. ryan
    Nicely timed question— this is actually already in 3.0.107, and I've just been testing it locally this morning. If there are any pages in the trash that a user had edit permission to, then they can see the trash, and see those pages in the trash. The trash and restore actions also are now supported for non-superusers. They can't see pages in the trash that they don't have page-edit/page-delete permission, only superuser can see those.
  7. ryan
    Lenz: If you just output that $config var in your <head>...</head> it will take care of it for you. i.e. <?=$config->pagerHeadTags?> It is just a shorter version of doing this (which you can do in any PW 3.x version): <?php if($config->urls->next) echo "<link rel='next' href='{$config->urls->next}' />"; if($config->urls->prev) echo "<link rel='prev' href='{$config->urls->prev}' />"; ?>
  8. ryan
    That's right, field names have precedence, and it also warns you if you try to create a tag that collides with a field.
  9. ryan
    Several core updates this week including a new way to perform $pages->find() searches by using Field tags, a new Field tag manager, new methods added to our $input API variable, new Inputfield traversal methods, and more… https://processwire.com/blog/posts/pw-3.0.106/
  10. ryan
    I'm still working on the latest version of ProcessWire (version 3.0.106) and don't have it quite ready to push to GitHub today, so we'll save that for next week. But I do have a fairly major FormBuilder release ready, and am placing it for download in the FormBuilder support board today. In this post, I'll cover what's new in this version of FormBuilder. After that, there is a how-to guide for using hooks in FormBuilder, though some might also find it also generally useful for any hooks in ProcessWire. Lastly, there's a FormBuilder hooks reference, which has been asked for a few times lately, so figured that was a good way to round out this FormBuilder blog post. Thanks for reading! https://processwire.com/blog/posts/formbuilder-v34/
  11. ryan
    This latest version on the dev branch adds a new site profile to the core, adds useful new functions to our $mail API variable, and makes significant enhancements to our $sanitizer API variable: https://processwire.com/blog/posts/processwire-3.0.105-core-updates/
  12. ryan
    Today is the last day of school before summer break for my kids—school is getting out early, so I'll keep this post short. But like most weeks, we've got a new core version on the dev branch this week. Core version 3.0.104 contains 13 new commits relative to last week's version, mostly related to resolving minor issues in our GitHub queue. There's not enough interesting material for me to take up your time reading a blog post, so I will save that for next week. But if you are running on the dev branch then it's definitely worth grabbing. If you are using AdminThemeUikit, this version has several minor tweaks and improvements to that admin theme as well. Plenty more to come next week. Thanks for reading, and have a great weekend!
  13. ryan
    This week we've got some really nice upgrades to three core modules: SessionHandlerDB, ProcessForgotPassword and FieldtypeComments. This post covers all the details: https://processwire.com/blog/posts/pw-3.0.103/
  14. ryan
    ProcessWire version 3.0.102 on the dev branch contains more than a dozen commits and PRs. I'll save the blog post till next week, as I continue reviewing pull requests and covering issue reports as they come in. But core updates are really going smoothly while the progress and fun continues, with ProcessWire getting better every week, thanks to your reports and PRs. This week I briefly had to do a small WordPress-to-ProcessWire conversion, but the site wasn't quite big enough to warrant automating the content conversion like I usually would. So I did a copy/paste job for the content, which I always kind of enjoy, so long as there isn't too much of it. But it was the first time that I had really used the new copy/paste images feature that we recently added to our CKEditor (outside of testing it during development). And I have to admit this feature is really handy for a case like this. Being able to “Copy Image…” (from another site), and paste at the location I want it to go in CKEditor …while the image uploads and inserts itself into my images field automatically… is pretty awesome. No more downloading images from the old site, on to my computer, then uploading to the new site, then placing them in CKEditor. What used to be several steps now feels like a single natural step. The new copy/paste process is so much simpler, and was a huge time saver this week. I mention it here because it's easy to forget that it's there at all (just like the drag-n-drop into CKEditor option). So if you haven't had a chance to try out the copy/paste image option in CKEditor, give it a try. It's a good thing to know about for those times when the need presents itself, because it'll save you (or your clients) a ton of time. More details about this feature can be found in the post for core version 3.0.87 (if you haven't read it already) where we covered the additions of drag-n-drop and copy/paste images uploads into CKEditor.
  15. ryan
    That's a good point, and maybe we'll change that before this gets off the dev branch. I left it false by default because it means a little more work for the function to perform. With defaults, I try and find a balance between the most likely to be used settings, with those that perform with the lowest overhead. There's also the matter of the "visible" option being more useful when the "keepTags" or "keepFormatTags" options are in use, where it can make a big difference. Though even without those options in use, there could still be entities counted as more than 1 character, so perhaps visible as true by default might be better.
  16. ryan
    This week's version of ProcessWire on the dev branch continues resolution of GitHub issue reports, and it also adds a new text truncation function to our $sanitizer API, something requested from our requests repository: https://processwire.com/blog/posts/processwire-3.0.101-core-updates/ We didn't have a blog post for last week's version 3.0.100—see the core updates section in ProcessWire Weekly #207 for more details on that version.
  17. ryan
    Happy Friday! Just a short update this week. This latest version of the core on the dev branch contains a whole lot of commits, mostly related to GitHub issue resolutions. See April 23–27 in the dev branch commit log. Thanks for all the continued testing, reports and discussion. I don't have anything new to report other than that, but am working to have another master version here shortly. Thanks and have a great weekend!
  18. ryan
    This week's version of ProcessWire on the dev branch includes some useful updates to the included AdminThemeUikit module. It also adds a new config setting for disabling HTTPS requirements in dev/staging environments, as well as some other updates: https://processwire.com/blog/posts/pw-3.0.99/
  19. ryan
    That property is added by the ProcessWire installer, and reflects the date that PW was installed. Here's the purpose of it: when there are additions/modifications to the core that are potentially not backwards compatible, it will check the installed date to make sure it doesn't need to retain some backwards compatible behavior. There aren't many instances of this, but here are a couple: 1. If your PW was installed after 2017-12-15, then it uses an "ms" suffix on image variations that use the "maxSize" method on Pageimage. 2. Another example has to do with Markup Regions. These were originally introduced supporting class attributes for certain actions, and that was later removed, as Markup Regions now use their own attributes. But if you installed your site before 2017-06-21, then the legacy class attribute actions will still work, if you happen use them.
  20. ryan
    Users have to select the admin theme from their profile before it's active for them. Edit your profile (where you change your password) and select Uikit as your admin theme. Also, delete your /site/modules/AdminThemeUikit/. It's not hurting anything, but you don't need it anymore.
  21. ryan
    No need to reinstall anything. Try doing a Modules > Refresh in your admin. If the admin is too broken to get that far, you could also paste in $modules->refresh(); in your /site/templates/admin.php file, view a page, the remove it.
  22. ryan
    The example you are referring to was not markup regions, but region() function calls. They are very different things. I think Horst may have thought I was talking about region() functions since the terminology is similar. Though I can also recommend region() / wireRegion() function calls (even if I don't often use them myself), as they are also quite useful, and I would certainly be happy to inherit a project using them. Depending on your code editor used to edit site files, they may be preferable to traditional delayed output. What you've described is not consistent with markup regions. You mentioned you would never use them, but I recommend enjoying some time with them before coming to that conclusion because I think you may view them as something different than what they are. Just like in any other methodology, it's your decision as to how you delegate front-end or back-end code, markup regions dictate nothing about that. Markup regions merely designate the target for markup, and are not really any different than delayed or direct output in that respect, other than that it's a little bit simpler to use, and a little more flexible in practice. Markup regions do not use class attributes. You can use id attributes if you want, but using pw-id attributes is independent of whatever is used in the markup. Of course, everyone prefers different methodologies, not to mention different projects have different needs, so there is no one-size-fits-all. PW supports a lot of different options, use whatever works best for your context.
  23. ryan
    For the most part I've been working to wrap up a client project this week, running in ProcessWire of course. At this point I'm using markup regions exclusively on new projects, as they really add an element of fun while also simplifying development, at least in my case. Admittedly, when we first introduced markup regions, I thought they'd be a good alternative for new users (who might otherwise use direct output), and didn't think I'd be using them myself. I was wrong. After I started using them, quite awhile ago, I've found that I rarely want to use anything else. I enjoy using them, whether developing something new, or going back and modifying an existing site that's using markup regions. I'm curious if other people have also taking a liking to them? There have been some commits to the core this week, as well as some other not-yet-committed updates on the dev branch, but not enough to warrant a version bump today. So we'll save the 3.0.99 version for next week. I have been getting lots of good reports on the current PW master version, very few issue reports, and feel we've got a really good solid and stable version on our master branch right now. Just in case there's anyone that's not yet using it, I recommend the upgrade. Thanks for reading, hope you all have a great weekend.
  24. ryan
    While I couldn't duplicate the issue exactly as mentioned above, I did start to see issues when using rows of columns that don't quite add up to 100% and a showIf condition was involved. There also seemed to be a bit of a random element to it when the uk-width-expand class got involved (potentially a bug in Uikit). I found I could avoid it by making sure that the columns added up to 100%, so I adjusted the threshold in AdminThemeUikit to round up to 100% when the columns add up to 95% or more. I'm hoping this might fix the issue that you observed, where your columns added up to 99%. If you get a chance to try it on the dev branch, please let me know. Thanks.
  25. ryan
    This is one reason why ProCache buster supports file.version.ext URLs as an option. But I wouldn't use that option if the reason is to accommodate a proxy server issue, which by all indications no longer exists. Use it if you prefer it for some other reason (maybe GTmetrix is a valid one). From what I understand, there was a version of a proxy server (Squid) that didn't cache query string assets due to a configuration issue that was fixed like 10 years ago or more. But mention of it ended up in some O'Reilly web optimization book around the same time, and so the issue took on a life of its own, and carries on due to tools continuing to look for it, even if apparently no longer relevant. Technically, query string is simpler and just slightly more efficient because no Apache rewrite rules have to get involved.
×
×
  • Create New...