bfncs

Hey Ryan, being a huge fond of the CKEditor module, I just stumbled over a tinyish bug: the icon images of the Codemirror plugin are actually missing. I already filed a pull request, would be great if you could merge that anytime soon: https://github.com/ryancramerdesign/InputfieldCKEditor/pull/11

Hey Ryan, thanks a lot, that worked perfectly! I wouldn't even dare thinking about hacking the core normally, but in this case I think it is ok, because this is just a temporary change either way in my case. Really nice to see, how flexible the permission system can be. I can understand that this being admin only is hard coded because of security considerations. Still it would be great to have this potentially available for users in some point in the future, especially for big websites that change a lot (in code). With kind regards, Marc

Hi Martin, thanks a lot for adding this option, very nice! Because of the Github trouble, I manually created a patch from your changes and commited it: https://github.com/boundaryfunctions/TextareaCounter/commit/f740d8f8 I recognized that your repository is not actually a fork of mine from a Git point of view, and this is what made it complicated. The normal development model is "Fork and Pull" and should more or less include these steps: Create a fork of the repository you want to work on. Clone your fork to your computer, create a new branch and do all changes on one topic in there. Push that branch to your fork on Github. File a pull request. With kind regards, Marc

So, I built something ugly und unDRY that works for me. http://processwire.com/talk/topic/3761-dropzonejs-and-file-uploads/?p=47209 https://github.com/bytebus/AjaxImageUpload This is just a proof-of-concept and by no means ready to use as a drop-in, so take it with caution.

Thanks for your comment Ryan! Good that you point out the "proof of concept" area in the modules directory, I didn't think of it in the first place, but for sure you're right, this is the right place. http://modules.processwire.com/modules/ajax-image-upload/ With the relatively complicated "installation" needing a lot of custom code at the moment, I also don't see a big problem, if some installs this by accident.

Hey everyone, ajax enabled file uploads in the frontend is something, that I also always wanted, so I did a really dirty hands on to get it done without core hacking. You can find my current state here: https://github.com/bytebus/AjaxImageUpload I consciously don't want to put this into the modules subforum because it's definitely not even close to be used as a drop-in module. The way it works is more or less this: * Provide an API endpoint for ajax uploads. * On each upload, create a new, temporary page with an only an image field. * Provide a method to easily copy the uploaded image to a "real" page and delete the temporary page. I think the concept is definitely simple and ok, so this is why I'm still posting the code and hope it might be a starting point for someone doing a cleaner implementation. I'm also glad about all suggestions (and pull requests ) on how to implement this in a more easy to use and flexible way. P.S.: I originally wanted to use dropzone.js for this because of the nice user interface. On a more in-depth look at it, I had the feeling that it's not flexible enough, though. I used jQuery File Upload instead which seems to be more widely supported, more flexible and also provides drag-and-drop functionality.

I also stumbled upon Sir Trevor a few days ago and immediately thought, that it would be a really great addition to Processwire, making especially that small area where it isn't awesome already - flexible content blocks - great. I think that a lot of users would appreciate having a tightly integrated module based on it. To make it really perfect, though, I think it would need a mechanism for users to build own templates with partials to make up their own content types - ideally this would also work with the built-in types. A huge amount of work... Still, I would really love to see an integration done and I think that it might attract a lot of users that didn't consider Pw before.

Edit: Oh, I should have known, that Soma is not only faster at answering but also already has a probably great solution for it! So, nevermind, I'll keep this post here for reference, though. --- Hi Meiros, that is definitely something you stumbled upon that should be possible but I don't think it has been implemented by anyone. The obvious and quick workaround would be to manually enter the URL in the right language, for sure, but this is not really satisfactory. It'll definitely need a patch to the core to get this working, because the TinyMCE module is part of it. The places to look for are: the TinyMCE PwLink Plugin to enable a language switching behaviour, and the ProcessPageList module that is delivering the data to the "Insert link" modal via Ajax and doesn't support fetching the list for different languages indepentently of the currently selected user's language. It would really be great to have a solution for this problem.

Haven't looked in here for a while, but now that I see it I still want to answer: Speaking about unixoid OSes, hard links contrary to soft links are not distinguishable from "real files" - actually there isn't a "real" file because this also is only a hard link to an inode. All hard links to a file are equally important. So, didn't try it, but there's no possibility that it doesn't work with hard links. About resolving the soft link problem: it is possible to check whether a given path is a softlink and if yes follow that link to the actual file to solve this in PHP without strains. This should even work in Windows from PHP >= 5.3.0 on, so maybe it's worth to give it a try?

Thanks a lot for answering! I tried it with the template rights (i.e. making language pages and/or admin pages editable by the specified group), but that didn't really work out. I suppose it should work by making a module that hooks into PagePermissions::viewable(), but I somehow thought there must be an easier way to do it. Edit: Here is some work in progress: https://gist.github.com/boundaryfunctions/1d32ba61052a0ae32e02 This works great to allow to view the page with the permission. The only thing that is shown in the backend though is a warning: "TemplateFile: You don't have permission". I debugged the code and there is a ProcessControllerPermissionException thrown when ProcessController::hasPermission() is called with an empty $permissionName - so it can only return true for the superuser. I single-stepped through all of it and there is no hookable method on the way to change that, not even a hacky one. This also explains, why it dosn't help to give a non superuser permissions to view/edit pages with the "admin" template. Any idea how I could still work around it and get this done? It would be really nice to allow some editors to translate without making them superusers. How do you approach relatively big multilanguage sites where you don't translate yourself then?

Hello everyone, is it currently possible to allow editors (so all kinds of non-superusers) to edit the translation files in the backend? It doesn't look like it to me, because there are no permissions in the LanguageSupport modules. Or did I overlook something here? And if not: is it possible to work around this somehow? Any help is appreciated. Edit: Should I maybe ask this question more general (not coined to multilanguage) in another subforum?

Hi Soma, thanks for your quick and helpful answer! I'd definitely just patch the core to support a hook where I need it, if I'd know, that this would also be in releases from 2.4 on. I don't really want to bring me into a situation, where I have to patch the core after every upgrade. I just filed a pull request, if Ryan likes it, I hope it could already be in the next release. https://github.com/ryancramerdesign/ProcessWire/pull/259 About the other ways: Thanks for thinking about this. The fallback is also manifested in the toString() method either, so no chance to do this without a hook. It might make sense to refactor this into a (hookable) method on it's own. So, I can't really think of anything else that makes sense, but you never know whether you're just too blind, so I'm asking.

Hello everyone, I was just asking myself, why there are no hooks for the methods in the LanguagesFieldValue class. I was going to improve the multilanguage support with a modul that introduces fallback languages. That would mean that for each language you can declare none or many fallback languages and if there is no translation of the value in the current language, it goes through all fallback languages and looks whether there's a corresponding value defined. It would be easy to implement this by hooking to the toString() method, but it is not hookable. Do you see another simple way to implement what I need or can we get hooks in the class in core? With kind regards, Marc

Hi ceberlin, this plugin is not intended for the use with a RTE editor like TinyMCE. It only works with plain textarea inputs.

I think you're actually right and I'm probably going exactly that route in the next days. When everything goes well, I'm going to publish it to the modules directory afterwards, for sure.

Hey Diogo, thanks for your quick answer! Your approach absolutely makes sense for user images, I already thought about going that route. But if you have something where content is user-generated but afterwards sighted and edited by an editor, it would be great to have everything on one page. And to be able to use already existing modules like apeisa's great and indespensable thumbnails module like they are meant to be used. This practically rules out your approach that will work for a lot of use cases for the things I have in mind. But just from the fact, that you did it yourself, I assume there's no ready to use solution out there already?

Hello everyone, I was just asking myself whether any has already created some kind of ajax file upload in Processwire for a page that is not yet created. As a simple example, think of a user registration form with the usual fields including an avatar image. I'd like to use something like Plupload, Dropzone.js or a similiar Ajax file uploader to upload the file asynchronously already before the rest of the form is processed. That would make it possible to i.e. directly show the user a resized preview of his avatar image, build forms with a lot of file uploads that would otherwise break the file upload limit, and probably a lot more neat features. It would be essential, that it is usable like a standard backend file upload/image field afterwards, it would be even better if files are also located in the id-named folder in assets/ after submitting the leftover form. The way I thought about how to do this would pack the following functionality in a plugin: Use some existing Ajax file uploader to get the file from client to server. There, a module takes care of the request, saves the file to some temporary folder and answers with an (id) reference to the image to work with it later. Ideally - if it's an image - it would already be possible to get a resized version of the image to provide a live preview. When the form finally get's submitted, the request includes the reference to the file. On the server, the image field is constructed as usual and the file itself get's moved to the "default" location. The temporary reference is deleted. One problem I see with this approach, is that after a while you will have a lot of unused files and references but that's no problem that a cron job with some code to get rid of old stuff couldn't solve. Having written all that down: Is there anything that already solves more or less what I described? And if not: do you see any problems with my outline or do you have a more elegant idea to implement this? Any feedback on this is appreciated, for sure. Marc

Yeah, I think you're pretty much right about the hundreds of articles. At least you should have the time to find an even better solution, when you're developing a site with thousands of articles. Also thanks for the MarkupCache example. It's also really nice, but I like the module approach better in this case, because it only affects editor's performance and not page view performance.

Hey Soma, thanks for your response again! ...and it totally makes sense, just something you don't see while thinking about merging differences etc ;-) I still like the idea of a universal module much better, doing it the Processwire way (and giving something back to the incredible community. But what should I say, the list I mentioned before is pretty long and time is rare... hope to do at least some of that stuff in the next holidays. Thanks, that's good to know. I just monkey-like copied that from your snippet. Actually, I also thought about that but decided to go the other way. It should more or less depend on the amount of articles and tags you have. What I expect is quite some tags but a much bigger amount of articles. So, I'm pretty sure, that your solution is a lot quicker for a low number of both because there's only one query instead of [number of tags + 1] query. When there are quite a lot of articles (say tens of thousands or so), your solution will at some point be slower than mine and has a greater risk of eventually breaking memory limits (on cheap shared hosting). That being said... I'll probably throw your great suggestion in for now. I don't really expect this site to have tens of thousands of articles and if it ever does, I'll probably have some quite more serious problems than this, so let's give the editors the benefit of the speed increase until then. Thanks a lot for your really great help, Marc Edit: Tested it, works great! I updated the gist so hopefully anyone can make use of it sometimes.

Took me some time to answer you, Soma, but finally: Actually I didn't mean the usual "cache rendered page content" but only "cache indirect relations to not have to procedurally query for them on every request". Sorry for confusing here. Actually, I tried to repeat the querying and sorting with around 5 articles and 10 tags in a for loop a thousand times and took some three seconds, which is totally ok. Still I like solutions that scale better Well, you're definitely right here and I would probably have went for that route, but I really don't like working my way around the Pw API, so I was looking for a better solution. Thank you so much, this is just a great and I will take that route right now! I already did quite some module programming and also even started, but my approach would have been to check only for changes on saving "articles" and add/remove from the "authors" array with that information. That would have brought up quite some edge cases to think about, which is why I posted. You solution, on the other hand, is just doing the complete query for the "authors" tags on each save of an "article", which makes this whole thing a LOT easier. I just didn't see the wood for trees here, so thank you a lot! Edit: If anyone is interested in this, here is the module code I finally used, very close to what Soma posted. There are still two drawbacks with this solution: The querying for author's tags will still be slow. It is only done if it is necessary and it slows down the editor, not the site user, so it's ok. Might run into problems, when there are thousands of tags and/or articles. Currently, if you delete an author from an article, his tags aren't regenerated. This is ok for my use case (will pretty much never happen) or at least wouldn't justify the work needed to get around this limitation. Since this is a functionality that is probably needed more often, I'll write the implementation of a universal module providing this functionality (without the two problems mentioned above for sure) on the list of "Great Processwire module ideas to do when there's enough time for it".

Thanks for your quick replies! I have a many-to-many relation between "article" and "tag" as well as between "article" and "author". Currently this is realized with two fields for multiple page references in the "article" template. Pages with the template "tag" are indeed something like "health", "obesity", etc., consisting only of a title field. Pages with the template "author" represent a human being that writes articles and have a page showing a picture, the bio, etc.

Hey jtborger, I'm also not quite clear, what you are doing here. Can you please describe how your field "Channel" is set up and what your code does output at the moment? If you always have only a single channel you want to choose, set your "Channel" to "Dereference in API as: Single page (Page) or boolean false when none selected" in the "Details" tab of the field configuration in the API. Then you can get the value of your field just as usual in your template: // get the page object of your "channel" in your template $channel = $page->channel; // get the title of your "channel" in your template $channelTitle = $page->channel->title; The code you posted above should work without problems, as far as I can judge it without seeing more.

Hello everyone, I'm currently trying to find the best way to solve a problem and I'm not really sure, whether there's an easy solution. Consider this example: 1. There is a template for "author", "article" and "tag". 2. The "article" template has a) a pages field for authors on or multiple authors and b) a pages field for on or mutilple authors tags 3. On the "authors" page I want to display a list of all tags, for which this author has articles. The naive approach would be to just get ALL tags, iterate through them, check if there's a page with the given author and this tag and if yes, add them to the list of display tags. Something like this: $authorTags = new PageArray(); $allTags = $pages->find('template=tag'); foreach ($allTags as $tag) { if($pages->count("template=article, tags=$tag")) { $authorTags->add($tag); } } While this works great, there's obviously a big performance problem: it doesn't scale since each additional tag results in one additional query. The cache will have to be cleared on changes of each article, which could happen pretty often, so this is not a solution. My second approach was to have an additonal field for tag in the "author" template and write a module that hooks into page save of "article" pages, checking for changes in the tags field and replicating them in the given author's pages. In the "author" template you can then just display your tags as a "native" field, which shoud be simple and performant. While I think, that this will probably the best and most clean solution, it will also be a lot of work, so I was wondering whether anyone of you maybe knows a) an easier (while still performant) way to archieve this, or b) a finished module that already solves this problem or is at least a good starting point to solve it. Thanks a lot for your answers already, Marc

Thanks for working on this. It works perfectly with PHPStorm and makes writing templates even faster and more precise than before. Please keep up the good work!

Hi Raul, thanks for testing and posting! I'm pretty sure that you are right, but there's currently no ready-to-use fix for it. I doubt it would be too hard to do, but I currently don't have enough time. I already filed an issue on Github for it, though, and I hope that there will be a working fix soon. With kind regards, Marc