Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by chrizz

  1. 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>";
  2. 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!
  3. 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 πŸ™‚
  4. 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.
  5. 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 πŸ™‚
  6. 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
  7. that was exactly what I was looking for. I wasn't aware of the requiredAttr. Works like charm πŸ™‚ Thanks
  8. 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!
  9. 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!
  10. 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.
  11. 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? ^^
  12. 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
  13. 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 πŸ™‚
  14. what about the others Berliners here: @blickwerker, @Bron, @ceberlin, @Dave Damage, @dlen, @fermion, @Jan Fromm, @masslevel, @Mitko, @neophron, @Neue Rituale, @Nico Knoll, @operat, @ottogal, @owzim, @Philipp Nowinski, @RSA, @sisterlarao, @skovar, @skries πŸ™‚
  15. @marcus, is Monday still the plan for the meetup? Looks as if we are the only ones for now though, or do you know from others planning to join us?
  16. @marcus, yep. that works and I'd available for beers πŸ™‚
  17. haha. obviously.... the wrong question... yes πŸ€¦β€β™‚οΈ Thanks a lot for pointing me into the right direction
  18. @bernhard, thats what I did as well - but then I ran into trouble because I needed to access the same class from a different module (autoloaded as well). And then it became tricky because I don't know any way to control the order of autoloading πŸ˜‰
  19. I have a module (autoload: true) which uses a custom class. If it would be only relevant for templates, _init.php would be the way to go but due to autoload functionality I need the class also to be availabel in the backend - this is where _init.php stops working. If the class is declared in config.php it works fine - but is this the recommended way or is there a better solution for this?
  20. I am running into the same issue. Unfortunately I wasn't able to reproduce it isolated, but it happens constantly in my current setup during debugging. Has this issue been solved for you @FrancisChung or is it still happening for you as well?
  21. thanks for bringing this up. To me this means: a cronjob will always use the first defined host, as there's no $_SERVER variable available, aye? Unless for sure the cronjob is called via http (e.g. "curl https:host.../") Thanks for your feedback - helps a lot πŸ™‚
  22. I was wondering which logic is behind the httpUrl method when multiple hosts are availble? My config says $config->httpHosts = array('api.local', 'www.api.local', ''); $page->httpUrl returns always api.local. In the current setup would be appreciated. Is there any logic behind this or is just the first host taken for the httpUrl() call? Checking the code brings up this comment But: How is this runtime valued defined when I use this method in a hook?
  23. whoop. Perfect! Thanks for that link πŸ™‚
  24. I already checked the CaptainHook cheatsheet - only the httpUrl method for PageFiles is hookable. It looks as if hooking the counterpart for pages is not possible πŸ˜• I currently use httpUrl at many places in the code but the URLs need to be rewritten. When hooks are not appropriate: Is there a way to add a custom method for all pages (e.g. $page->myCustomPath()) which actually returns the URL I need?
  25. nahhh.... I found the issue. If I would have followed @LostKobrakai advice: serialize can cause unforseen issues. The above example works fine, but actually (and I didn't test this yesterday) I (un-)serialize the array before replacing one item. When I use the example and serialize WireArray before getting and replacing the element it simply does nothing but it shows the old item I guess I have to go with the "use pages for every item" solution which is much less error prone. thanks @kongondo for testing this
  • Create New...