Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/16/2019 in all areas

  1. This week we take a look at what’s in ProcessWire 3.0.126 which focuses largely on resolving issue reports, but also includes a handy new $page->if() method— https://processwire.com/blog/posts/pw-3.0.126/
    9 points
  2. I just wanted to share what I've just discovered after looking at Dragan's "CMS evaluation / checklist / usability (only in german for now)" article, even if I can't read german currently. https://animejs.com https://github.com/juliangarnier/anime
    5 points
  3. Here is another progress report for development (early state) of my GroupMailer module: The dashboard and the message lister are nearly finished. Behind the scenes I created a custom field which holds all MessageMeta data. This special field can be attached to each template you like and will immediately make all corresponding pages a GroupMailer message. This allows to maintain the extreme flexibility of ProcessWire. More to come ...
    3 points
  4. For what I can tell the tables use jquery table sorter for this task. Maybe you can check in their documentation how to restart the plugin with the format you require. Found this also, specific to date formats.
    2 points
  5. Not sure where to post this, I'm hesitant to file it as a GitHub issue. I noticed that in the database's image fields, the fractional part of focus values are a bit overkill: e.g. {"focus":{"top":93.400000000000005684341886080801486968994140625,"left":49.39999999999999857891452847979962825775146484375,"zoom":0}} Don't know that it matters much, but hey, the super-extra-hyper-10x-Retina displays aren't on sale yet, so... ?
    2 points
  6. Good catch - I've unpinned it. That said, there are still lots of modules that aren't tagged as v3 compatibly that probably are, but if the authors haven't mad the change by now, they probably never will ?
    2 points
  7. Hey @adrian. Just wondering if this thread might've served it's purpose already, or do we still want to keep it pinned to the Modules/Plugins area? I'd say that it's been long enough, but it's your call ?
    2 points
  8. Relying on .htaccess is not really uncommon for php cms's out there. Some are more minimal on utilising apache, processwire is probably more on the "take what we can get"-side. Having php serve everything – especially static assets – is just not performant enough in any way. That's the reason for needing to rely on the webserver in front of php in the first place. The reason for apache specifically is because of .htaccess. Other webservers are usually only statically configurable, which is a deal-breaker for any shared-hoster, where a (global) webserver cannot be restarted whenever a single user needs to change his configuration. So if you only support one webserver, it better be apache.
    2 points
  9. Using .htaccess is efficient. You could, in theory, handle (nearly) everything in PHP, but this would add serious overhead, both memory and speed wise. Others have adapted the rules for NGINX, a few like me use IIS with URL Rewrite to power PW, but in all cases, it makes sense to filter and rewrite requests in the web server itself. The topic of supporting more platforms than just Apache out of the box has been brought up a few times already here in the forums. Ryan himself is not opposed to it, but he lacks the time to develop and test the rule sets, and he is of course wary of including anything that hasn't been well tested or that might end up without active support (any changes he makes for .htaccess need to be quickly adapted for other platforms). So I guess it would need a team of knowledgeable volunteers who develop the rules, adapt the installer script, test everything well and provide quick support before he considers integration into the PW project.
    2 points
  10. A module helping you to manage SEO related tasks like a boss! Automatically generates and maintains a XML sitemap from your pages. Includes a Fieldtype and Inputfield to manage sitemap settings and meta data for pages (Title, Description, Canonical URL, Opengraph, Twitter, Structured Data etc.) Multi language support for the sitemap and meta data. Configure default values for meta data on template level and let pages inherit or overwrite them individually. Map existing fields to meta data, reducing the need to duplicate content. Live preview for content editors how the entered meta data appears on Google. Live preview for content editors how the entered Opengraph data looks like when sharing a page with Facebook. Check out the README on GitHub for more details, including usage instructions. The module is currently released as beta and needs testing! Please report any issues on GitHub or in this forum thread, if you find time to give it a try ? Examples Here is an example of rendered meta data you will get from a single SeoMaestro field: <title>Sed dictum eros quis massa semper rutrum. | acme.com</title> <meta name="description" content="Si lobortis singularis genitus ibidem saluto. Dolore ad nunc, mos accumsan paratus duis suscipit luptatum facilisis macto uxor iaceo quadrum. Demoveo, appellatio elit neque ad commodo ea. Wisi, iaceo, tincidunt at commoveo rusticus et, ludus."> <meta name="keywords" content="Foo,Bar"> <link rel="canonical" href="https://acme.com/en/about/"> <meta property="og:title" content="Sed dictum eros quis massa semper rutrum."> <meta property="og:description" content="Si lobortis singularis genitus ibidem saluto. Dolore ad nunc, mos accumsan paratus duis suscipit luptatum facilisis macto uxor iaceo quadrum. Demoveo, appellatio elit neque ad commodo ea. Wisi, iaceo, tincidunt at commoveo rusticus et, ludus."> <meta property="og:image" content="https://acme.com/site/assets/files/1001/og-image.jpg"> <meta property="og:image:type" content="image/jpg"> <meta property="og:image:width" content="1600"> <meta property="og:image:height" content="1200"> <meta property="og:image:alt" content="Lorem Ipsum"> <meta property="og:type" content="website"> <meta property="og:url" content="https://acme.com/en/about/"> <meta property="og:locale" content="en_EN"> <meta name="twitter:card" content="summary"> <meta name="twitter:creator" content="@schtifu"> <meta name="twitter:site" content="@schtifu"> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "About", "item": "https://acme.com/en/about/" } ] } </script> <meta name="generator" content="ProcessWire"> <link rel="alternate" href="https://acme.com/en/about/" hreflang="en"> <link rel="alternate" href="https://acme.com/en/about/" hreflang="x-default"> <link rel="alternate" href="https://acme.com/de/ueber/" hreflang="de"> <link rel="alternate" href="https://acme.com/fi/tietoja/" hreflang="fi"> And some screenshots of the UI:
    1 point
  11. I've created a small module which lets you define a timestamp after which a page should be accessible. In addition you can define a timestamp when the release should end and the page should not be accessable any more. ProcessWire-Module: http://modules.processwire.com/modules/page-access-releasetime/ Github: https://github.com/Sebiworld/PageAccessReleasetime Usage PageAccessReleasetime can be installed like every other module in ProcessWire. Check the following guide for detailed information: How-To Install or Uninstall Modules After that, you will find checkboxes for activating the releasetime-fields at the settings-tab of each page. You don't need to add the fields to your templates manually. Check e.g. the checkbox "Activate Releasetime from?" and fill in a date in the future. The page will not be accessable for your users until the given date is reached. If you have $config->pagefileSecure = true, the module will protect files of unreleased pages as well. How it works This module hooks into Page::viewable to prevent users to access unreleased pages: public function hookPageViewable($event) { $page = $event->object; $viewable = $event->return; if($viewable){ // If the page would be viewable, additionally check Releasetime and User-Permission $viewable = $this->canUserSee($page); } $event->return = $viewable; } To prevent access to the files of unreleased pages, we hook into Page::isPublic and ProcessPageView::sendFile. public function hookPageIsPublic($e) { $page = $e->object; if($e->return && $this->isReleaseTimeSet($page)) { $e->return = false; } } The site/assets/files/ directory of pages, which isPublic() returns false, will get a '-' as prefix. This indicates ProcessWire (with activated $config->pagefileSecure) to check the file's permissions via PHP before delivering it to the client. The check wether a not-public file should be accessable happens in ProcessPageView::sendFile. We throw an 404 Exception if the current user must not see the file. public function hookProcessPageViewSendFile($e) { $page = $e->arguments[0]; if(!$this->canUserSee($page)) { throw new Wire404Exception('File not found'); } } Additionally we hook into ProcessPageEdit::buildForm to add the PageAccessReleasetime fields to each page and move them to the settings tab. Limitations In the current version, releasetime-protected pages will appear in wire('pages')->find() queries. If you want to display a list of pages, where pages could be releasetime-protected, you should double-check with $page->viewable() wether the page can be accessed. $page->viewable() returns false, if the page is not released yet. If you have an idea how unreleased pages can be filtered out of ProcessWire selector queries, feel free to write an issue, comment or make a pull request!
    1 point
  12. Not sure how well documented MarkupAdminDataTable is, but I've managed to work out quite a bit and have found it very useful for custom admin pages. One thing that has me stumped, however, is sorting dates. Obviously if the date is just rendered as a unix integer, it sorts fine but is not very meaningful. If I apply a datetime format, it sorts it as as string, which again is fine for 'Y/m/d' but no good for a more user-friendly format like 'd/m/Y' or 'relative'. I've tried applying class="datetime" to the items (which I spotted you can do by supplying an array of [item, class]) but that seems not to help. Any ideas or pointers to more documentation?
    1 point
  13. Brill, thanks. Looks like mmddyyyy is hard-coded into the jquery tablesorter in wire. I hacked that to ddmmyyyy and it works fine (until the next update ? ) Anyone any ideas how I put that over-ride into my site?
    1 point
  14. thanks for the advice, I submitted it as an issue.
    1 point
  15. Actually I would recommend posting this as a GitHub issue. It's not really a "problem" per se, but I also don't see any point in storing all those decimals, so they're just unnecessary clutter. Hard to say if Ryan will consider it worth acting on though ?
    1 point
  16. Maybe this could help... if it's the same error/behaviour:
    1 point
  17. Thank you all for your helpful comments. I think I will go with the solution building the new site in a sub-directory. The old site is quite large (100+ pages), and therefore I plan to merge some content from the new processwire-subdirectory via the fantastic API that processwire provides into the old site, during the conversion-process. Quite messy, I know. But with such a complex-reducing system as processwire, I think it is doable. Thanks again!
    1 point
  18. Well, it might be technically possible, but there's no core support for it, and I wouldn't recommend it ? In this case you would probably have to modify index.php, .htaccess, and at least some other core files: wire/core/ProcessWire.php, wire/modules/Process/ProcessLogin/ProcessLogin.module, and wire/modules/Process/ProcessPageView.module. Modifying core files is never a good idea, as it makes updating ProcessWire difficult (usually you can just replace certain core files and that's it), and there's also no guarantee that some third party module etc. isn't expecting the core to remain as-is. So, long story short: if you really have to, you can of course modify it, but there's no guarantee that things will work as expected afterwards. If possible, I'd recommend developing the ProcessWire site elsewhere (subdirectory, or another domain, or locally) and then replacing the old site in one go. ?
    1 point
  19. @MateThemes Could you please share your code and the error you are getting? Also, make sure that you are not passing a menu name or title as the first argument of the render method. In ML setup it should be id, an array of menu items or page object.
    1 point
  20. OK, we have #1 configurable and working fine (Ajax Save Yes/No). The page is added to the inputfield but not saved to the field. Such pages can be re-positioned, edited, etc, just like the other saved pages. In the frontend, they do not show up since they are not saved to the field yet. On save, the pages are added to the field. If the page is manually reloaded without saving, these pages are not saved to the field. The only snafu is that when the pages are added to the modal, in case one is not using "Close Modal On Add Page", there is no visual indication (the light grey background on table rows or if using Thumbs View, the greenish border) that the pages are in the field, which sort of makes sense because they are not yet saved to the field. However, I think they should be presented as if they are in the field. I'm not sure how to resolve this atm. Thoughts? Thanks.
    1 point
  21. ProcessWire Core (Master) ProcessWire master 3.0.123 Croppable Image 3 (Wrapper-Module) CroppableImage3 1.1.16 Ok my mistake is solved. My CPI3 Field was gallery and not images, this was the standard field in the PW demo
    1 point
  22. Your cache function doesn't return JSON though, but rather a PageArray with the full user objects. I suggest only returning the JSON data you need to see if that makes a difference. That's correct. A solution is to use $pages->findMany() with the user template. $members = $cache->get('members', '+10 minutes', function($pages) { $member_pages = $pages->findMany('template=user, roles=member, sort=lastname, limit=3000, check_access=0'); return json_encode($member_pages->explode(['name', 'email'])); // Whatever fields/properties you need from the member pages });
    1 point
  23. MySQL's utf8 encoding can only represent a tiny (though useful) subset of the full 31-bit range of Unicode; it's not UTF-8 at all. To fix what never should've been broken, they came up with utf8mb4. It's "of course" (i.e. UTF-8 is some properly designed piece of stuff) upwards compatible with the broken utf8 type. Well, not exactly, but more on that later. Would it be possible to default to the real UTF-8 type, when available? (MySQL 5.5.3+) (even wp did it! nudge nudge) And here comes that "later" you've all been waiting for. This important(ish) change would require the noble sacrifice of cutting some of the core (YES, CORE!) fields down to 250 characters to satisfy MySQL's sad-pathetic-deplorable limitation on index sizes. I know, that's 5 precious characters lost, but think about all those suffering emojis and suddenly you'll feel all fuzzy and warm, right? Anw, just a suggestion, because i18n and l10n and all the like. Edit: It seems a cruel RFC took away much of UTF-8's expressive beauty, and it is now valid only up to 4-byte lengths and values of 0x10FFFF, whichever smaller; I'm gonna go and cry myself to sleep now, goodbye.
    1 point
×
×
  • Create New...