Jump to content

ryan

Administrators
  • Posts

    16,772
  • Joined

  • Last visited

  • Days Won

    1,531

Everything posted by ryan

  1. Okay I think I understand what you are saying. So you want to just load a fresh copy from the database, not keep an existing copy at some state in memory. Do this to load a fresh copy from the database: wire('pages')->uncacheAll(); $oldPage = wire('pages')->get($page->id);
  2. DaveP, can you try this from your template: var_dump($page->field); Replacing 'field' with the name of that field. See what it tells you. Since this is a textarea field, check what Text formatters are applied to it on the 'details' tab of your field settings. Try removing any temporarily and testing again (just don't forget to add them back). Let us know what you find.
  3. Can you double check that you have the LanguageSupportFields module installed? Also, I did fix a related issue a couple weeks ago, just in case you are running on an older version. Just tested here with a simple textarea field and is working. I created "summary" and "summary_se". It's identifying "summary_se" with the label "Swedish" above it. Let me know if you still can't get it working after double checking the items above. I'll need to know which fieldtype you are using so that I can duplicate a test here as closely as possible.
  4. ProcessWire keeps a memory cache of pages loaded, so when you retrieve a page, its going to be the same instance of that page when you retrieve it elsewhere. But once you save a page (in the API) that memory cache gets cleared. If you wanted to keep an in-memory copy of it before it was saved, you'd want to clone it sometime before the page is saved: $pageCopy = clone $page; From that point forward, any changes to $page won't be seen in $pageCopy. This clone will cease to exist once it is out of memory scope. For obvious reasons, file-based assets aren't cloned here. So if your clone depends on file/image assets, then you have to create a new page not just in memory, but on database/disk too. Here's how you do that: $pageCopy = $pages->clone($page); That does a recursive clone, cloning not just that page, but any children too. See the parameters to the $pages->clone() function for additional options to control this. You can also specify that you want it to clone to a different parent. Be careful with the cloning as it's something you probably don't want to do on every page save. It can be an expensive operation if there are lots of files or subpages associated with the cloned page.
  5. I had to try it on another installation, but was finally able to duplicate the autopopulating date issue. It turned out to be a rather complex thing, took me a couple hours to figure out. But I did figure it out, and committed it yesterday. I also fixed the issue Wes mentioned with the access in a file/image field. There were more considerations with file/image fields. The fact that they get submitted by ajax is rather confusing for the repeater. So if you added a new item, uploaded an image, then entered a description or sorted it, then description or sort would be lost. This issue has been fixed. I think this might be related to the issues mentioned above that were fixed yesterday. I just tried to duplicate here and couldn't, so am hoping I got this one fixed. Though if you could double check that it fixed it there too, that'd be great. Sorry I missed this before, thanks for letting me know. This doesn't sound good. I will definitely avoid cloning any pages with repeaters on them until I can get into this one. I will try to fix asap, hopefully early next week.
  6. Good points. Lots more cleverness to add to the Modules page for sure, including the solution you've already implemented with collapsing the module sections. Just not ready to jump into that pool just yet (battling time and work), but figure small improvements are worthwhile till then. We'll plan to get some nice upgrades with the Modules section in 2.3.
  7. Welcome to the forums Didjee! Thanks for the fix. Great first post!
  8. I think for the sites that adopt flags, they do it because it's pretty, looks international, and can catch the eye quicker. Also, maybe there isn't a technical 1-to-1 relationship among many, but the communication is still there (though I'm sure there are exceptions). For something that involves a very large number of languages, then I agree flags lead to inaccurate generalizations. But when I go to a site in another language, I see the US or British flag a lot quicker than I see the word "English", so I tend to have a slight usability preference for the flags (as a user). Even if they aren't perfect, they are a familiar landmark in a sea of unfamiliar language where it's easier to spot landmarks than words. For me the worst cases are when sites use language names in a dropdown selection, and the label on the dropown is not one that I can read to even know what it's for. I'm a little afraid of this just from an SEO standpoint. This clearly violates Google's webmaster guidelines (delivering different textual content at the same URL based on client-side factors), but maybe they have an exception for a case like this? (at least that would make sense) It sounds like RTL support has more to do with the markup than anything else? Are you aware of any factors on the data storage side? Thanks for sharing your expertise and experience in these areas -- glad to have you here, Ryan
  9. Soma, that was fixed earlier this week. Might require a JS refresh though. Let me know if you still experience the issue.
  10. ryan

    ZwedenWeb

    Nice job Jasper! Quite a big site with lots of content and looks like you brought it all together extremely well!
  11. So what you are talking about here is a known service API? One where the system of access URLs, expected input/output data are known ahead of time? In this case, I totally agree on the value of a wrapper for it. It's the general purpose, unknown service REST wrapper that I question the value of. Btw, ProcessPageSearch has a service API, and I've wondered about re-introducing this as a distributable template that people can install and use on their front end as a read-only web service with authentication. We could easily build the wrapper class for accessing it from PHP which would mimic use of $pages.
  12. The only modules that PW loads on every request are: 1) those called upon by that request, aka on-demand; or 2) those designated as 'autoload'. Most modules are of type 1 (on-demand) so they aren't included or loaded (or taking up memory) unless asked for. When it comes to autoload modules, it is a best practice for autoload modules not to add their hooks until they've determined that they are applicable to the given request. For instance, an autoload module that only needs to do something in the admin would add a hook from its ready() function after determining that the $page was part of the admin. Down the road, there is room for further optimization here. We could have an autoload module that only loads when template is 'admin' or page is X or has parent Y, or any number of things. But this is added complexity for both the user and the module developer. So it's something I'm not sure we need to consider too much until memory issues are a concern. Currently memory is not an issue, even with a lot of autoload modules. But longer term we will benefit from an 'autoload if' type designation for modules, and good to start planning for.
  13. Default values aren't yet supported. I've been planning and looking for a way to support them with all fieldtypes globally, but if I don't come up with a good solution there, I'll start adding default value support individually to fieldtypes where it makes sense. That checkbox one is a great example. It's looking like this is the way it will go, but I just didn't want to start having individual fieldtypes support their own default values only to later go back and have a separate solution independent of fieldtype. The same goes for required values, so the two will probably come at the same time, and it should be soon.
  14. Thanks for posting that Netcarver. Definitely useful and interesting. Bookmarked and plan to revisit for sure. Also very impressive the work that you did with the MLP pack in Textpattern! We've kind of skipped over the issue of language names in PW, and are letting people use whatever names they want for their languages (whether iso/codes, names, or something else). Though the <html> lang attribute, and PHP setlocale() codes are set with the translation files. But the intention here was just to broaden the utility of the language capabilities. For instance, one could have a language called "greenhorn" that provides lots of additional details for everything, and another called "coder" that has API/usage notes. There are all kinds of possibilities for using the language capabilities beyond languages themselves. Not that I'm suggesting it's something we need regularly, but just wanted to keep it open ended for when we do. I've not done anything with regard to right-to-left languages, and don't have a good understanding of what is necessary to support them. The question has come up before. What is your experience in supporting these languages? I'm curious what steps we would need to take (if any?) to properly support them. Thanks, Ryan
  15. Thanks for the additional details Sevarf2, I will keep trying here.
  16. I think this is a good example of why I'm a little scared of supporting context for any factor. If you set "max files" to "1" in one context, and "0" in another, then those fields are going to behave differently from the API (Pagefile vs array of Pagefiles). Same thing with a Page reference field, where you can define its type with the field (Page, PageArray, NullPage, false). I think it could cause a confusion and bugs in people's code. Another example is just a plain text field. It might have an entities encoder added to it in one context, and not in another. That could be not just confusing, but an output and potential security issue (depending on the source of the text). Uncontrolled field contexts are a bit of a can of worms. So before we open up context beyond the existing built-in factors, I want to come up with a way for fieldtype authors to identify a factor as being safe (or not safe) for multi-context.
  17. I think it'd be worthwhile for marketing, but not sure how useful it would be unless it can make some assumptions about the service API (like PW-to-PW or something). The reason I question the usefulness is just because outside of a known service API, the read-only aspects don't amount to much more than this: $data = json_decode(file_get_contents('http://domain/path/to/service?a=b')); I'm just not sure a wrapper class adds much value here? But once we know about the service, then a wrapper class seems to start adding value. So perhaps the value comes from defining an interface or abstract class to be extended, rather than adding a layer to something that doesn't need it. While I've built a lot of web services, and built tools to read from a lot of services, I'm not an expert on web service standards by any means. Someone correct me if I'm missing anything obvious. I also agree that it looks interesting. I like the ideas behind it for sure. But I've not been able to make much sense of it after half an hour, so I guess I'd say it's a bit muddy for me too. Anything makes sense after enough time reading, researching, etc., But my brief exposure gives me the impression that CMIS seems like a complex answer for a simple question (and I admit that's an uninformed opinion). I might feel differently after more time. But initial impressions are that it's something to watch and follow, and put on the roadmap if there is high demand for it someday in the future.
  18. Thanks AlexV! This module was written before multi-language support in PW, and hasn't yet been updated to support multi language title/text/textarea fields (though does support multi language alternate fields). However, even if it had been updated, you would still need a title specified for the page in the 'default' language (since it is a required field). It doesn't care what language the 'default' language is, whether English, Russian, etc. But when you are importing with this module, it is assuming that default language for any multi-language fields. It sounds like in your case, you may want to have Russian as your default language, and English as an add-on language. That way you don't have to translate to English before importing.
  19. I think there were good intentions behind them and I understand the original purpose, but i've just never come across anyone actually using them in their API. Though I'm sure they are out there. But there's nothing you can't do with them that you can't already do without them, so I think many see them as unnecessary barriers to adoption of their API.
  20. PW is a perfect platform for your RESTful APIs or any kind of web services. Some of my clients keep multiple sites that need to talk and share data with each other at regular intervals, and I always build "RESTful" web services with ProcessWire to accomplish this. PW was designed to make this particularly easy. But I'm not a fan of the terms "REST" or "RESTful", as I think it implies that there's something more than what it is. This is the way we were doing web services before those terms existed, and it is basically the way you would think to do it even if you never heard of it. If you are dealing with primarily GET requests (which covers most of my needs), then you don't need anything other than ProcessWire and PHP's standard file_get_contents(), json_encode() and json_decode() (or simple_xml) functions. If your needs also involve POST requests (or your PHP doesn't let you load URLs with its file functions), then I recommend grabbing the really simple and easy-to-use Snoopy class too. I don't personally bother with PUT or DELETE requests, or understand why they would be necessary or preferable over authorized GET/POST requests doing the same thing. Let me know if you'd like me to supply any simple code examples of how you might use ProcessWire in this manner.
  21. Actually those were added at the same time as this update. I experimented with it and it works nicely, but decided just to make them bold rather than changing the color. But you can change the color, background color (or the entire row) or anything else with it from an admin theme. Here are the relevant classes: #ProcessTemplateEdit .asmFieldset - applies to both starting and ending fieldsets or tabs #ProcessTemplateEdit .asmFieldsetStart - applies just to starting fieldsets or tabs #ProcessTemplateEdit .asmFieldsetEnd - applies just to ending fieldsets or tabs #ProcessTemplateEdit .asmFieldsetIndent - controls the width of the indent, adjust with css width property
  22. I committed a couple small additions this morning: 1. Fieldset indentation in the template editor. Hard to describe, but I needed some way to make the grouping of fieldsets a little easier to see in the asmSelect list in the template editor. Here's a screenshot which describes it better than I can: 2. The InputfieldCheckboxes field now supports columns. This would typically be used if you had a Page reference field using the Checkboxes input. When editing the field, you'll see a new option on the 'input' tab where you can specify a number of columns you want it to use. This is just a way to tighten things up for when you have lots of short-labeled checkboxes (see bottom of screenshot).
  23. Not at present, but definitely interested in doing that for the future. It's just a matter of time/resources and putting it towards the stuff that matters most in the short term. Longer term it would be really nice to have something like this, especially as PW gets used more and more as a framework. I would version control your /site/templates/ and /site/modules/, but not your /site/assets/ as they are tied to DB entries. Though if you combine it with a DB export for each commit, then that would solve it. But this is something we'll have built-in version control for, further down the road.
  24. Thanks Pete, sounds like we should definitely go ahead and add the octits-stream to keep the firefox happy. I will plan to add this. Thanks for your research and testing here.
  25. I think this makes sense, but a little clarification to that message. It's taking about making it non-writable to the web server, not non-writable to you. I don't suggest removing your own write access from any file. But I think you are talking about the situation where Apache runs as the same user as your account, and it makes sense there. I will plan to combine these messages in a manner that fits that situation --good suggestion.
×
×
  • Create New...