Leaderboard

That's a tricky one. At least I didn't find anything like this some months ago. What about using something like Turnjs , which is for html5 content, not pdf, but use imagemagick to convert the PDFs to PNGs?

Just a quick update this week. The dev branch version is now at 3.0.202 as of today. Relative to 3.0.201 this includes 22 commits of various fixes, issue resolutions, improvements and additions. While there's nothing major that's new to report in this version, there is nonetheless quite a bit there, and if you are already running on the dev branch it's a worthwhile upgrade. For full details be sure to see the dev branch commit log. Thanks for reading and have a great weekend!

Docs & Download: rockettpw/seo/markup-sitemap Modules Directory: MarkupSitemap Composer: rockett/sitemap ⚠️ NEW MAINTAINER NEEDED: Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there. MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added. Example when using the built-in multi-language profile: <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process. The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO). Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.) As of December 2017, you can also exclude templates from sitemap access altogether, whilst retaining their settings if previously configured. Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level. The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set). Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own. Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.

I have a single page with an image field that hold ~600 images. Now apart from it being not very handy to handle, it also takes A LOT of time to load (had to increase PHP timeout to 120s) and it only displays roughly a third of the images in the backend (although I can see all 600 image files in the corresponding assets/files/ folder). There are also no errors in the console. I read in another forum post a comment from Ryan that image fields don’t scale infinitely, but no explanation to why that happens. Does anyone have experiences with such an amount of images or alternative solutions to the problem? Just to be clear: This is not about rendering the images on the frontend, but about adding them to an image field. I’m on localhost with MAMP and PHP performance settings bumped. I’m using PW 3.0.200 and PHP 7.3.3.

Could this be a solution? https://mediamanager.kongondo.com/

No jQuery ?

Almost exactly 6 years ago Ryan released pagination support for ProFields Table and was thinking about implementing this for more Fieldtypes such as Images: https://processwire.com/blog/posts/fieldtype-pagination/ Unfortunately this hasn’t happened yet, so maybe commission a website from Ryan that involves 600 images per page and he'll prioritise the feature ? The first thing I would do to remedy the immediate problem would be to move the images to a separate tab in the page editor. That should keep the loading times down when you just want to change some other stuff. Otherwise, I guess you’ll have to build a custom Inputfield (perhaps without thumbnails) or structure your site differently. Here is a longish thread about turning off the Image field's auto-thumbnails, maybe it has some pointers relevant to your endeavour: https://processwire.com/talk/topic/21112-do-not-create-default-image-variation-on-image-upload/ You could also try using a Files field instead. I imagine the page editor performance will be better and it won’t auto-generate thumbnails. Of course, you’ll have a harder time scaling and using the images in the front-end. Check this thread for more info https://processwire.com/talk/topic/26113-resize-image-manually/

Hm, for indexing, I would assume that's worse, since google would see it as a bunch of different documents. Also, I'm not sure about how efficient it would be to have pdf.js running individually for each page. I think you should separate indexing and viewing in two issues: show the pdf in a viewer, and link to it directly for indexing. I only checked pdf.js superficially, but I have the feeling that you could use it's api and css to control it as you wish. See this example from their page: https://jsfiddle.net/pdfjs/wagvs9Lf/, For what I've seen, you can also control zoom, and so on... Have a look at this video on how to build a PDF viewer with it. Maybe this is overkill for your project, but it's interesting for sure ?

On one Website, i use "wowBook", but it's not free and unfortunately also requires jQuery... Have also been looking for a better solution for a long time.

If you don't need specifically an imitation of a magazine, there might be other solutions. That one might be a good idea ? Did you see pdf.js from Mozilla?

Good day, @teppo! Hope you're doing fine. I am using Wireframe in everything I build now) And devs I collaborate with love it as it gives us a defined common ground. Thanks! We are using components a lot. Particularly for RM based content builder. And we often need to call some component-unique logic from the component view. I wish we could do it like we can in regular views: just calling a public method of component controller as a function (or a property). It doesn't seem to be a feature now. Could this be added?

Good day, Ivan. Glad to hear that you're enjoying Wireframe ? Could you clarify how you're calling such methods in case of regular views? You should be already able to access component class methods from a component view with $this->method_name, similar to they way you access controller class methods from regular views. Both Controller and Component base classes implement MethodPropsTrait, which enables this behaviour. But if you're looking for something along the lines of View::getController(), ComponentView didn't have a direct method for that. Pretty sure this was originally by design (to keep component views from becoming too complex), but I've added a similar method in latest version (0.26.0) just in case: ComponentView::getComponent().

If you are adding the class in a hook rather than in an inputfield you are creating then the likely reason is that your hook is firing too late, after this module has already done its work. You would need to hook at the renderReady state and may need to adjust your hook priority to be sure of adding the class in advance of this module. Remember that this module also provides a hookable method allowing you to disable the module for specific inputfields - see the Usage section in the readme.

I wonder if PW should check the memory limit during install? Done: https://github.com/processwire/processwire-requests/issues/449

Thanks @Robin S – that's an excellent explanation. I didn't previously know about the difference between PageFinder and in-memory selectors. It'd probably be good if allowable date formats were explained on the selectors documentation page. (I'm not sure what the best process for suggesting documentation updates is.)