horst

I think the WireMailMandrill module is wrongly set to singular: https://github.com/craigrodway/WireMailMandrill/blob/develop/WireMailMandrill.module#L31 Juts try out with setting this to false, and if it works, drop a note to @Craig. My WireMailSmtp is set to false here, Teppos WireMailSwiftMailer is also set to false.

This site definitely need some caching and lazy loading. Also when I switch the language, I have to wait again a long time.

Many thanks! I have updated the repo!

I love Shaun, ...

https://medium.com/artificial-labs/why-we-don-t-use-wordpress-anymore-df1c4462cb48

OT: @mr-fan, thanks for the "reminder"! Forgot to implement this myself. (I need to add some noscript - background url images!)

This is nothing that urges. In the past (not a PW site!) I simply logged all 404 to 2 files, one with only the urls. Then, from time to time, I have manually loaded it into my editor which has a function to make all entries (lines) unique (drop all copies). From the resulting lines I created entries for the htaccess like: Redirect gone /admin/ Redirect gone /db/ Redirect gone /dbadmin/ Redirect gone /ecommerce/ Redirect gone /sqlmanager/ Redirect gone /typo3/ Redirect gone /webstats/ Redirect gone /wordpress/ Redirect gone /connector.php Redirect gone /index2.php Redirect gone /wp-login.php This way my 404 log becomes more and more clean and the attackers hopefully gets a feeling like "Damn, to late again!" A 404 monitor module that determine a scan attack optionally can send 410 headers for the next 5 or 10 minutes to the originating IP. No more editing the htaccess for this. I will send you the sqlite wrapper. I have looked at it, but currently it depends on a subclass of mine in regards to filelocking. I will change this to result in a single class before sending.

Hi Mike, I have installed jumplinks on my new homepage and enabled the 404 logger. When I want to just edit a small piece in a page, I could see life a scanning attack for vulnarebilities: These attacks can test several hundred links. So, after such a scan, the 404 Monitor (limited to the last 100 hits) is pretty useless. What about (optional) alternative storage of the links? Simple logfile or maybe better a sqlite db file? This way you don't need to spam the MySQL-DB with those spam entries but the useful links also don't get dropped. So, with lots of entries, the 404-Monitor table needs to have pagination then and maybe a function to select / delete entries. If you interested in this, I can provide a ready to use wrapper class for sqlite, (create, insert, update, read, delete). ----------- Edit: Also useful solution could be to exclude the 404-Monitor as separate module and give it some more functions like detecting IPs and when seeing those attacks, temporary block the IP for a short time. But this has nothing to do with jumplinks. That's why I said make 404-Monitor a external / submodule, that can be used for / from different other modules.

depends on how the fields are weightened, more to include or more to exclude. I prefer to write lesser. You also can make this decision configurable. ;-)

Yep, you can exclude fields on a page. This is not a hacky solution, you can use it as a customized version, or you make the module configurable with at least one Textarea field where you define imagefields to exclude, one per line. This way you can drop it into diferent sites and no need to hack.

So, when storing those pagetable child pages as native children in the pagetree, we can easily get them selected. But when we need to store them on a different (out of the way) location in the pagetree, this relation is lost. Wouldn't it be nice to have the ability to build a selector like: $pagetablechildren = $pages->find("parent-pagetablefield={$page->pagetablefield->id}, template=xyz"); Or is this already possible and I simply don't know it?

The first part of your idea is practicable, the second one not. At least I don't want to add properties to pageimage from a croppableimage cropsettimgs field. For example if someone calls his thumb "crop", it collides with existing pageimage property from new core. Also it has potential that properties from (other) third party modules collides with those properties. I'm not 100% sure, but tend more to no then yes. Best way to contributing is to send pull requests to Github.

Another way could be to use two image fields, one called imagesbefore and the other imagesafter. Set them up to be displayed side by side each 50% width in the template. You can get them like for ($i=0; $i<count($page->imagesbefore); $i++) { $urlbefore = $page->imagesbefore->eq($i)->url; $urlafter = $page->imagesafter->eq($i)->url; }

Hi, I have uploaded a new version to Github that fully supports PW 2.6+ with its new naming scheme. The package now ships with two Pim versions, the older one, called Pim, that can be used until PW 2.5 stable, and the new one, Pim2 that should be used with PW 2.6+ So, if you start a new site with PW 2.6+, simply install Pim2 only! If you have upgraded PW to 2.6 on an existing site with lots of image variations, you should install Pim2 additionally to the older one, (do not uninstall it yet!) then you should start to change your API calls in your templates like the following explanation . here is a code line from the older Pim: $image = $image->pimLoad($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . To start with smooth change from Pim to Pim2, you can change it to this: // use the old Pim to remove the PimVariations with old naming scheme: $image->pimLoad($prefix)->removePimVariations(); // in the copied original code line, only change pimLoad to pim2Load, note the number 2 ! in the new start method ! $image = $image->pim2Load($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . This way you have some control on which parts the new creation may take effect, e.g. on a small site you can change all API calls at once and drop caches if exists. On bigger sites you may start at one template / page first, and add more changes later. . Regardless of this, you can safely let the call to the older removePimVariations() method stay in your code for a while, as they do not interact with the newer one. After a while, when you do not see any of those old filenames in your assets/files folders, you can remove those lines from your code and also uninstall the older Pim. All other methods than pimLoad / pim2Load are completly identical and can be seen here in the API

You need to apply the watermarking to the right image(field). If you don't want oversized, watermarked images in your header menu, simply do not apply it there. Look through your template code and find the right position, not where you have the header menu but where you output the postcard image. Also be aware that currently, when trying out things, you may get displayed cached images also when altering the code. To force new creation of Pim images put as a second argument to pimLoad() a boolean true, BUT don't forget to remove it, once you have finished your code!

This error says that there is something wrong with your PNG file. Please check on the tools template if the watermarkfield is set for a single image or for multiple images. If it is setup for multiple images, please correct it. You can also check in your template if you got an imageobject: $png = $pages->get('/tools/')->watermarkfield; if (empty($png)) { // uhm, something went wrong! ... stop with further execution }

Hi @grumpy, It looks to me that you have done nearly everything right. The only thing you left out is to populate $images in your code. I think you simply forgot $images = $page->images; , assumed that your current $page has an images field that is called "images". But you also can ommit this extra line and change your code in line 10 to be: foreach($page->images as $image) {

And what's about the risc, that when once finished translating a huge text to 12 languages, hitting that button by accident?

Sorry to hear this, - but despite this unfortunate fact: welcome to the forums. All settings can be seen in the wire/config.php, but please copy those you need into site/config.php and edit them there. (settings in wire/config.php are the defaults, individual custom settings goes into site/config.php, so they are save on upgrades and / or can be detected & collected by site exports, etc.) And, yes, now you know it, more often saving (also if needed without publishing a page) is better. And besides that, I use a Plugin with my browser (FireFox) that stores all textarea inputs for a configurable time: https://addons.mozilla.org/en-US/firefox/addon/textarea-cache/ This I do because I run into the same situation some time ago, ;-)

Hey, this works here too. But it isn't the best solution because hardcoded page-ids isn't practical. I need to export / import that at some point to another site and need to use generic properties like name. I will file an issue with this, at least I'm interested why it works with id but not with subfield.name. But also nice to have it working for a first tests here.

Thanks for looking at it. Is there a chance that I have setup something wrong? The place in pagetree where the data is saved?

Have you used the showOnlyIf conditional? Here is a exported siteprofile of it. It is a clean and fresh install from 2.6.0 stable from today started with a blank profile: site-wrongShowonlyif.zip

It is when they are visible.

Hi, I have setup a new blank site with PW 2.6.0 stable version. I have created a template that has two fields, the Title and a PageTable. The PageTable 's template contains besides the title a single Pagefield with radios plus three other fields (text or integer) that should only be shown if the right option from the Pagefield is selected. This works fine and as expected! But the values entered into the fields do not get stored in the DB! If I strip the showOnlyIf condition, the values get stored as expected! With the SHowOnlyIf condition, the data isn't stored when opening the page from the PageTable-field in a modal window, nor when selecting the page from the pagetree and open it directly for editing. ?? Is this expected behave or do I miss something?

Hi @soma, thanks for the continuous maintenance of this (and other) tool(s). This is one of my favourite modules.