Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/01/2019 in all areas

  1. OK done some digging and found this absolutely stupid thing in their API: intents work with StripeElements menaing you can create a payment intent and supply that intent id to a form to start taking the payment, you can then use their API to step through the payment process using the language of your choice (pretty much) – I'm looking to implement both a PHP and JS implementation into my module. HOWEVER: if you want to use the cross browser payments button (e.g. pay with apply pay, google pay) then you have to create a new payment request to that js api, e.g. doesnt work with your pre-authed intent id... I've taken this up with them and they say: I consider this a massive oversight as surely the payment intents arethe beginning of ANY interaction with the StripAPI, in this case not. Anyway, will continue to work on this one to implement as much as possible.
    2 points
  2. SeoMaestro (including myself) knows nothing about TemplateLatteReplace, so I cannot influence settings of this module. I am not sure why the LatteReplace would try to render the structured data template, I assume it's because SeoMaestro internally uses a ProcessWire TemplateFile to render the markup: https://github.com/wanze/SeoMaestro/blob/master/src/StructuredData/BreadcrumbStructuredData.php#L52-L55 There is nothing I can do from Seo Maestro's side about this, and I assume you will have problems with other modules as well that are using ProcessWire's TemplateFile for rendering. My TemplateEngineFactory module providing template engines like Twig, Smarty, Pug etc. does not suffer from this problem, because it hooks after Pager::render rather than TemplateFile::render. Cheers
    2 points
  3. See ProcessWire::getHttpHost(). If PW cannot match a host in your $config->httpHosts array from PHP's predefined $_SERVER variable then it gives you the first item from $config->httpHosts.
    2 points
  4. I have been experimenting with the new $page->meta() method and find it useful. Once i figured out that the data i "save" with it is tied to the page where i called the method from. So this is not obvious at least not for me in the documentation: https://processwire.com/api/ref/page/meta/ So i just wanted to share that revelation with the community so you don´t get as confused as i was. Happy Coding Everyone.
    1 point
  5. These were for MarkupMenu, an aria-label within template strings that I wanted to be translatable ? Not sure if I've ever tried this before either; didn't occur to me that it wouldn't be possible, but makes sense now. Anyway, the separate config file idea actually works quite nicely for me in this case. Ready.php would've been a good solution as well ?
    1 point
  6. Already in the works and making good progress ? Great 2 posts, @Robin S! Thank you for all your contributions and always positive and helpful comments. It's really great having you here! ?
    1 point
  7. Buying ProFields for this reason only should be enough ? After all, without Ryan there is no ProcessWire so we need to support him. Anyway, I think ProFields really shines when one needs it for Repeater Matrix. The other modules can also come in handy sometimes but with other free modules and/or other built in modules similar functionalities can also be implemented mostly without too much effort. What I find not powerful enough is Table. The features of Table are quite limited. I understand that implementing such an inputfield is quite time consuming, so developing a much more powerful ProTable module as an independent paid module would make sense. For example, @bernhard has been working on his on his modules (#1 and #2 and maybe more?) and we also have the not-really-worked-on-anymore ProFields: Page Table with lots of lucking features as well (eg.: pagination). All this development effort towards an independent Pro module based on tabulator.info would be welcome. I imagine a "ProFields: Page Table" based on Tabulator which would be a big hit...
    1 point
  8. I've been working remotely this week and haven't had a good place to sit or very particularly reliable internet, so I've put my attention towards things that I could make progress with in small and inconsistent chunks of time. As a result, it worked well to focus on resolving issue reports this week. In addition to updates mentioned last week, 3.0.134 resolves 18+ issues and contains roughly 25 commits relative to 3.0.133. Since most of the commits since last week are focused on resolving issue reports, I don't have much to write here beyond what's in the commit log, but do want to thank everyone for their reports and hope that you have a great weekend!
    1 point
  9. We had this issue recently, it's because of the limit of Input variables in your PHP configuration. Adjusting the value of max_input_vars in your php.ini file to a larger number will increase the number of items you can save ?
    1 point
  10. Exciting that the new processwire.com could arrive within the next week! Caught me by surprise too, as I thought it was early days yet for the design and that there would be more evaluation/discussion/iteration of it before it went out live to the world. But I can appreciate also that a "move fast and break things" approach is often the most productive. A couple of observations/opinions of previous screenshots (I didn't comment earlier because I thought it might have been too early for this sort of thing)... I'm not liking the typeface used in the new design. My main gripe is the curved strokes used on characters such as A, V, w, etc. This design detail looks ugly and amateurish to my eye. I know it's a small detail and such things can be a matter of taste but in support of my opinion I'll add that if you look at the work of the top-tier type foundries such as Hoefler or Klim you won't find any typefaces that curve the strokes on these characters. I also think the x-height is excessively large (the height of the lowercase relative to the uppercase). Again it's a subtle thing but I'd argue this sways the balance too far towards "friendly" versus "serious". My preference would be for something more neutral and serious as the main typeface. As an example, Molde is very affordable at the moment and a great workhorse due to the many included weights and widths. Another observation is that the pages that have the entire page background in blue are pretty intense. It's too strong IMO and not so comfortable or inviting for reading. And when it comes to the Showcase the focus should be on the site screenshots - the page design should aim to show them off as best as possible. A strongly saturated background distracts from and can clash with the content in the screenshots. I think the blue background works better in smaller blocks on the page, to highlight a section or provide differentiation between sections on the page. When it comes to large background areas I think white or greys would be better (this could include dark greys or black if we want some blocks to have reversed type). The other thing that I think it would be good to discuss is who the target user of ProcessWire is. I'd love to hear @ryan's view on this, as well as other community members' views. Of course many different types of user could find value in PW, but when it comes to designing and evaluating marketing materials such as processwire.com I think it can be helpful to form a clear picture of a specific target user. We can't have "everyone who wants to make a website" as a target - so who is the user that will find most value in PW, who is that user we want to draw in? I discovered this older topic recently that has some interesting discussion about promoting ProcessWire as an "enterprise CMS". I'm not saying that "enterprise" is what we want to focus on as a primary target market (I don't think it is), but I do think that we need to have more of these kinds of discussions with the aim of clarifying who ProcessWire is targeted to and how best to reach that audience. My view is that the PW's biggest asset is its powerful and well-documented API. And the user who is most able to benefit from that is a user who has a fair amount of development experience. It's probably a user who is a professional developer in one form or another. It's hard to get a sense of the breakdown of types of users currently working with PW - the forum is one of the few ways but it's not a good guide because there could be many experienced developers using PW who don't need help via the forums and are perhaps too busy to make other contributions there. But generally I get the sense that PW is not reaching experienced professional developers as well as it could. Part of reaching and capturing the target audience involves making sure processwire.com communicates to that audience that you've come to the right place. The cues for this can be subtle. I think the visual and written language of processwire.com should be serious, neutral (PW is "unopinionated"), and prepared with the professional developer in mind. The API should be emphasised and we should be careful to avoid any "dumbing down" that might obscure the fact that PW is a powerful and sophisticated tool. I'm not saying that the proposed design or the existing processwire.com are failing in this regard - just that I think these things should be key considerations.
    1 point
×
×
  • Create New...