chrizz

That's because I don't want to mess around in the PW-provided htaccess whenever possible. And because the regular site redirects to www. the staging site does as well (same htaccess). But I think I am close to solve this issue. Your input enabled me to read the documentation again and challenge my current assumptions, that httpHost is determined automatically and httpsHosts should list all available configurations. What I am actually confused about is the fact that it is working everywhere as expected - except for IONOS. -- and after a short call with their support, I have to admit, that they are quite confused by their own systems. Maybe it was bad luck, with the one support member I was talking to, but they actually saw redirects where no redirects were and vice versa. And the absolute downer (sorry for OT): Having a wildcard SSL certificate which is claimed to be valid for one domain and all subdomains *DOES NOT* include subdomains like www.stage.website.de. The support recommended to just buy another certificate. -- end of story: IONOS is a poor hoster and I have adapted the staging website to be reachable just via stage.website.de thanks anyways ?

It is driving me nuts... and i hope that someone has faced (and solved) a similar issues already ... I have a staging website hosted on IONOS. htaccess tells to redirect everything to www.. So the website is reachable via www.stage.website.de. This website includes a form which populates it's action URL via $form->action = '//' . $config->httpHost . $page->url; then the fun part: within my local environment and on some other (non-IONOS) server the markup prints as action "www.stage.website.de". On IONOS for whatever reason the action is "stage.website.de" (without www) which makes the form disfunctional (because the POST request is forwared (via htaccess) to www.stage.website.de and it loses it's parameters on the way). If I extend the htaccess to not redirect stage.website.de to www.stage.website.de it works fine. has anyone faced the same/similar issue? My current assumption is that IONOS is doing something very special which breaks the automatic detection by PW of the current httpHost. But I have no clue how to fix this, nor where to start searching for it. Site notes config.php lists both: www.stage.website.de and stage.website.de as httpHosts index.config.php points also both stage/nonstage to the same site directory.

are you sure that this would work? In the test I did above, the value wasn't returned from cache once the cache has expired echo "4: <pre>".print_r($this->cache->get("cachetest"),true)."</pre>";

sorry for getting back to you guys this late and thanks for all your input. Using ImageSizer directly sounds pretty handy - although I have to tell you, that for my particular case, I have decided to just create a hidden page which acts as a container. So exactly the opposite what I was looking for, but in the end this approach turned out to be the most efficient one ? Anyways: Thanks a lot!

to me it looks like a bug as well, but I didn't mention it yesterday because I didn't even know what exactly to expect ? Using the lifetime only during save could lead to unwanted behavior, that the cache is gone during the get request (e.g. the API is down for longer than 5min). That's why I would need some kind of fallback... So basically: * GET logic: use always data from cache * SAVE: retrieve data from API and save to cache if last save is > 5min I think I will go another way, ignoring the cache capabilites and use pages instead. Nevertheless: thanks for your input ?

maybe it's to late, maybe I am just overseeing an important detail. I have read the docs for WireCache multiple times, I have debugged a lot but for some reason I cannot find a useful explanation and I am starting to feel concerned that my use case isn't even covered by WireCache. Using a expire date during the get requests leads to the desired result only if the original expire date (during save) was lower. This one way approach seems to make ithe following impossible: What I want to achieve: I want to store data in cache retrieved from an external API make sure that data is always present, even if the API is down: I set the expire date during cache->save() to 1 month cached data is retrieved via $cache->get("cacheName") without an explicit expireDate (means: it expires in a month) a cronjob should update this cache on a 5-minute basis. Therefore I am trying to get the cached data via $cache->get("cacheName", (5*60)) Unfortunately it seems as if this cannot be achieved with the WireCache implementation, because lower expireDates during the ->get will *always* result in a "cache miss". It seems that what would help me is a creation timestamp for a cache entry which could be checked as well. The more I think about the more I come to the conclusion that this kind of "two-expire-dates" isn't coverable with WireCache Do I oversee something or is this known/wanted behavior? some code in case you want to try it on your own: $this->cache->save("cachetest","abc", 10); echo "1: <pre>".print_r($this->cache->get("cachetest"),true)."</pre>"; echo "2: <pre>".print_r($this->cache->get("cachetest", 5),true)."</pre>"; echo "3: <pre>".print_r($this->cache->get("cachetest", 30),true)."</pre>"; sleep(15); echo "4: <pre>".print_r($this->cache->get("cachetest"),true)."</pre>"; echo "5: <pre>".print_r($this->cache->get("cachetest", 5),true)."</pre>"; echo "6: <pre>".print_r($this->cache->get("cachetest", 30),true)."</pre>"; Output: 1: abc 2: 3: abc 4: 5: abc 6: abc I would have expected that number 2 would result in a cache hit, because the expire date is still 5s in the future.

hey, a quick question about importing images from an external URL: I know that this is possible in general (at least that's what a forum search told me). My use case is slighty different and I am just curious if there's a way to achieve the following: I am currently writing a module which shows external news from Facebook which could contain an image. The news are simply cached in the database - there is no page created from it. What I want to make use of are the handy image functions to crop and resize images coming from FB - *without* having a page. Is this even possible? If yes: awesome. If not, I guess the most promising workaround would be having a hidden page somewhere acting as image container for such posts as usual: happy to hear your thoughts on that one ?

not sure whether a feature request should be dropped here, or @github, but I'll try it here first ? First off: I love that module. It's handy, easy to implement/adapt and it just does what it is supposed to do. Thanks for sharing! What I was looking for is a way to customize the markup of the consent blueprint. For the time being I have edited the original shipped file, but actually it would be great if this file can be configured the same way as the banner. Maybe that's something you could consider in the future as well? /update ? https://github.com/webworkerJoshua/privacywire/pull/16

that was exactly what I was looking for. I wasn't aware of the requiredAttr. Works like charm ? Thanks

I am currently experimenting with a form which required specific fields. I want to have front-end (via JS) and backend validation (via PW built-in) but I am struggeling with the "required" attribute. In order to use form.checkValidity(), inputfields need "required='required'" as attribute To make use of the PW validation, the field has to be initialized with $field->required = true; This makes the input field look like this $field = $this->modules->get("InputfieldText"); $field->label = "test"; $field->attr("id+name", "test"); $field->attr("type", "number"); $field->attr("step", "0.001"); $field->attr("placeholder", "placeholder"); $field->attr("required", true); $field->required = 1; $form->add($field); For some reason the results are not the desired ones and I have no clue how this could be solved. The above results in the following output <input id="test" class="required InputfieldMaxWidth" name="test" type="number" maxlength="2048" placeholder="placeholder" step="0.001"> Backend validation will work, but frontend validation fails because of the missing "required" attribute Removing the line $field->required = 1, make it look like this <input id="test" class="InputfieldMaxWidth" name="test" type="number" maxlength="2048" placeholder="placeholder" step="0.001" required="required"> Now the frontend validation works, but the backend validation fails (obviously because the "required" class is missing. Actually I am wondering why the build-in "required" results in a CSS class, rather than in the attribute and why an additional attribute and the class collides. And because I am pretty sure that I am not the first one struggling with this, any hints are much appreciated ? Thanks!

hey guys - thanks again for your valuable input! I think I got just confused by the fact that the same code behaves differently in the last to master versions. Nevertheless, I am going to refactor a bit and take care of my own that an exception is thrown as soon as the page name already exists. thanks again!

that's exactly what I don't want ? I guess there's no other way than hooking into these methods (same would apply for page updates (if the name changes as well). Maybe someone knows why/when this chnage has been implemented and/or why I experience differences between the two PW versions.

okay - maybe then it's some weird other co-incidence: Originally I was creating pages via API. Based upon your question I tested the behavior in Admin and guess what: The UI warns me that a page with this name already exists but then adds it's own number at the end. It seems as if PW adds a numbering and checks which first (lowest) number is not already taken yet: A quick research showed that this is wanted behavior. PW takes care of the name automatically. *BUT* How can I avoid this? What I need is a way that duplicates are not created. I want PW do a lot of things, but not in this case ? The following code behaves differently based on the PW version. $title = "mytitle"; $channel = new Page(); $channel->template = "basic-page"; $channel->parent = $pages->get("/styleguide/"); $channel->title = $title; $channel->name = $this->sanitizer->pageName($title); $channel->save(); with PW 3.0.123 it runs once - a second run results in an SQL exception: Error: Exception: SQLSTATE[23000]: Integrity constraint violation: with PW3.0.148 the code runs as often as you want and generates page names on it's own. So... bug or feature? ^^

I recently upgraded one of my projects to 3.0.148 and I got screwed by the new "unique" flag for pages introdueced here. Until now I was relying on PW's internal logic to throw an exception if a page with the same name already exists using the same parent page. Now I am trying to find a clever and easy to use method which can bring back that functionality. Is there maybe a config option I am not aware of? Because I need this duplicate check in many places of the project I want to find a solution which reduces code duplication. So, is there by chance a config for this? If not: ideas are welcome how this could be solved :) Cheers! chrizz

as discussed yesterday this wasn't the last Wireabend-Bier (perfect wording @marcus!) in Berlin. I am looking forward to meet more of you in the future with another beer ?