Jump to content

yellowled

Members
  • Posts

    284
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by yellowled

  1. Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

    Personally, I would not even consider translating that because ModulesManager is more like a proper name. You usually don't translates proper names. (By the way, Soma is very right considering fragmenting discussion by translations. I have experienced that in a forum for another system. It's very hard to switch. However, it's something you can't really avoid – once a system is translated, people will discuss it in various languages.)

    The issue at hand with this is still if we should put module translations in the “core” language files or not. Personally, I don't think it's a good idea. It would blow up the language packs significantly, which is not ideal for people who don't use many modules. (I, for instance, tend to not use many modules in most of my PW projects.)

    As for keeping all translations for modules in a seperate repository, I don't think that's much better. The repository will grow rather quickly, making it hard to install only the few translations people actually need, especially given the fact that the file names for translation files are kind of clumsy. I think the only option there would be to keep the modules in seperate directories of that repository.

    I don't know if that's feasible, but maybe module translations could get some kind of a “dependency management”? Currently, if you install a translation, you just upload a zip file including all core translations. (At least that's what I do.) It would be very awesome if there was a way to (for each language installed) easily “get all available translations for modules currently installed”. (Might be kind of an overhead, though. Not sure. I'm not a coder.)

    • Like 1
  2. Or do I misunderstand the question?

    That part is already done and working like a charm. Nico's code was (I think) supposed to redirect from e.g. /contact/?id=1 to just /contact/ (while still submitting the 1 to the $session variable) to keep the URL nice and clean. But as I tested it, I noticed it throws an error message in the browser because of the redirect.

  3. and on /a-page/:

    $session->set('redirect', $input->get->link);
    $session->redirect($page->url);
    

    That does bascially work fine, but the redirect doesn't seem to be a good idea. Chrome gives me a warning that the page has a redirect (Duh!) and refuses to load it (after trying to load for quite some time). So it's a dead end with the redirect.

    However, it does work well without the redirect. I'm kind of okay with the extra URL segment there, but of course, if anybody has another idea how to get rid of it …  :)

  4. In a project, I have a lot of links which all lead to the same form. Every link is asscociated with an object which has a unique id. I need to set the value of one field in said form depending on which link has been clicked so that the recipient of the emails sent by the form knows which object they inquiry is related to. Sometimes these objects may be on a single page, sometime multiple links on the same page, so the association needs to be with the link, not with the page.

    I know how to do this using JS and cookies, but I'd rather not use that if possible. Is there a way to maybe use $session for this? If so, how do I set a session variable based on “if a link is clicked”? is that even possible?

  5. 2. If I edit any exiting redirect I get this error, but the redirect does work.

    redirect_from: Error found - please check that it is a valid URL (redirect_from)

    I get the same error message. The funny thing is that the redirect actually works, it is stored despite of the error message etc. It just emits this error message. (If this helps with debugging, I'm redirecting from /frameset.htm to / – very, very old site about to be relaunched.)

    I have used the Redirects module before, but I don't think I ever noticed this – maybe it's related to 2.4? When installing the module, I get a message saying it might not be compatible with PW > 2.2 …

  6. Gave it a short trial run the other day. I'm more of a code-writing, design-in-the-browser kind of guy than a “visual designer”, which basically means that I can't even start a site design in PS or any other graphical tool because I never learned how to do that. That's probably why I didn't really grasp the idea behind Macaw quickly, I'm just not used to working that way. 

    However, I don't even think I'm the target audience for it. I think the target audience are graphical designers who also do web design. To them, it might appeal more. And frankly, anything that makes people still doing fixed width designs in PS realize that it's a new world out there and helps them find their way in it is a good thing.  ;)

    • Like 2
  7. Can I ask about the app for a sec - what's the benefit over a fully functional mobile admin theme?

    I think that's a little different with WP (or almost any other blog system) compared to PW.

    Some people may know that I'm involved in the development of the blog system Serendipity. One of the goals for the upcoming version 2.0 there is a new admin backend, which is also supposed to be responsive. Because given the fact that Serendipity only has very few developers, chances are more than slim that anyone will ever make an app, albeit one for iOS, Android and Windows Phone. So I've spent the past couple of months redesigning the “frontend of the backend” there.

    Man, designing a backend is hard. I have sworn multiple times that I will never ever do that again. It is especially hard because there's lots of features to think about anyway as well as plugins adding functionality to the backend etc. Add the responsive stuff on top of that and you've got a shitload of work on your hands.

    An app can make this easier. Designing a responsive admin theme means you have to account for any backend feature in all resolutions. With a seperate app, it's … “quite okay”, I guess, to leave out stuff which doesn't make sense on mobile devices anyway and focus on the stuff that people are in fact going to want to do with their blog system on a mobile device.

    The beauty of the PW backend is that it's very … hm, “simple” sounds wrong. It very … streamlined, I guess. My point is, I think it is much easier to “get away” with a responsive backend theme in PW that in e.g. WP, just because of the overall structure and organization of the backend. (I hope that makes sense.)

    • Like 3
  8. @WillyC

    In other words, I think it's okay to say...

    "Hey, this field requires a username, not an email address!"

    That is, for the record, exactly my point. Of course I don't want to compromise the security of this process.

    Showing a user who entered data of the wrong type the same message a user who entered the proper type doesn't give them any indication. The only indication that they did something wrong is the fact that they don't get the reset email, and that could have other reasons.

    I didn't post this as a GitHub issue since I think it's rather an enhancement, so I wanted to discuss it here first.

  9. Something I'd never realized myself, but a client of mine stumbled upon it:

    The client's site uses the Forgot Password module. Clicking the link in the login screen opens up a screen with an input field where users are supposed to enter their username. For some reason, the client thought she was supposed to enter her email address. I suppose she read the info text there in a hurry (it does mention that users need to have a registered email address).

    The thing is: if you enter an email address in said input field and hit the send button, it still displays the info message saying that you'll receive an email with further instructions as to how to reset your password, which of course is not being sent since you did not enter a proper user name. I think it would be better if these instruction would only be displayed if the user actually entered a proper user name or something.

  10. If you are using the multi-language page names module native to PW 2.3, then you would have checkboxes on your settings tab that indicate whether the language is active or not.

    I just stumbled upon this catching up on my reading for multi-language sites. For a long-term multi-lang project I'm about to implement, this is pretty much perfect.

    One of the (many) cases where I stumble upon something implemented in PW, and I just go “Wow, Ryan, that's a brillant solution.” It really gives me a warm, fuzzy feeling that this CMS is being developed the way it makes sense.

    Just wanted to note that, even if it's way after the fact.  :)

  11. Oh, I shouldn't have said that! :) One thing I remember was that language packs are installable via modules manager? Just really only 1-2 minor things, I get that's the perspective I have as a PW long time user. 

    Can't remember even talking about the Modules Manager, but I guess talking about the ability to install modules from the backend in 2.4 may have come across as that to a long-time user.  :)

    By the way, the talk led to German web dev/design magazine Screenguide asking me for an article about PW, so more exposure for PW in German(y) coming up. I'm not sure when that issue's coming out. Might be May or June.

    • Like 5
  12. I am hoping that Processwire will allow me to do all this without tripping up on PHP knowledge or the lack thereof. I doubt I will need to build custom modules or blocks of code.

    Whenever someone asks me about the level of PHP needed to work with PW, I usually tell them that my PHP knowledge roughly matches the ability to speak English of a 2-year old chimpanzee. Which is kind of accurate.

    Like you, I never managed to grasp the fundamental concepts of programming. There is a certain point to which I get it (if conditions, foreach loops, the easy things), but after that I just don't understand it. I'm constantly amazed by the ideas people in this forum come up with to solve template issues.

    It's been the same with Javascript back in the day when AJAX was still very new and everyone was jumping on the JS wagon. Then jQuery came along and suddenly, writing JS code became a lot easier. This is where the PW API comes in – it's been designed to work for PHP like jQuery does for JS. And it does.

    I still can't write a contact form script in pure PHP. Well, maybe I could, but it either wouldn't work or be very insecure. And yet, I find myself writing PHP templates using the PW API and actually having fun doing it.  :)

    • Like 10
  13. do you guys use some special deployment tools or do use interesting workflows for deployment you like to talk about? :)

    always start out with a prototype which usually includes 4-6 example pages in plain old HTML, hopefully spanning all the layouts needed in a project. After that, I prefer to work on the actual server which the site will be hosted on, maybe on a subdomain or different folder if it's a relaunch. The reason for this is that in my humble experience, development setups almost never match the setup of the client's server/webspace. There's always some kind of small difference, and I really don't want to waste time on replicating that in a local dev environment.

    The prototype is usually based on a small starter project (I wouldn't call it a framework) I have built over the past couple of months. This includes a Grunt build script (which I love) including a lot of useful helpers like Sass, Bower, various tools to optmize images, Modernizr, jQuery etc. This also takes care of combining and minifying CSS and JS files, and it can even work with the PW templates I create after finishing the prototype.

    As for the actual deployment, I haven't included that in the build script. There are Grunt plugins for that, but I'm not entirely sure that would be very secure. So I still use plain old (S)FTP and ssh (if available on the client's server, which unfortunately still is rarely the case) to deploy the actual templates to the (development) site.

    • Like 3
  14. Yellowled nice talk, some little details were not correct and me as a hardcore noticed of course

    I'd really like to hear/read those so I can improve the talk if I'm ever to hold it again. Feel free to point them out here or drop me an email.  :)

  15. There should be versions of both talks which show both video and slides next to each other. Of course, that makes for two pretty small windows, but I guess it's easier to follow the slides that way.

    I think it was a bit of a bummer that the lecture hall in which I held my talk was, well, huge. It accommodates 500 people. I think that's not even the number of attendees at that conference. That's also why the camera has to zoom in quite a ways in both rooms, but at the same time it's why there actually are videos available – the university records every lecture given for students to Mormon Scientology Dating. I assume showing both speaker and slides in the video is not possible – the screen for the beamer is friggin' huge even in the smaller lecture hall …

  16. Not sure I'm going to be giving this talk again anytime soon, Nico, but of course I'd be open to it.  :)

    Funny thing about the unnecessary $today – I wasn't even aware that it's unnecessary. I've always used a similar $today variable in PW templates. Thanks for pointing that out, diogo. I need to keep reading more in the forums to keep up with PW, but time is scarce and the number of new posts keeps growing every day, it seems.

    • Like 1
  17. Not sure this is appropriate here or placed in the right subforum, but I “have done a nice thing with ProcessWire” – it's just not a web project this time.  :)

    I gave a talk on ProcessWire (in German) at the German web conference Webkongress Erlangen a few days ago. Some folks have been asking if the talk would be available on video later, and thanks to the nice people of the A/V team of the university where the conference was held, it now is available on video in various formats as well as audio only.

    A little info for the people in the forum who don't understand German: the title of my talk roughly translates to “ProcessWire – A CMS offering a lot of freedom”. I gave a very basic introduction, showed off a few sites built with PW, showed off the new 2.4 backend a little (screenshots only; it was my first time speaking in public in a long time, so I didn't want to embarrass myself doing a clumsy live demo) and talked a lot about the API and it's possibillities. Of course, I'm not a skilled PHP coder, so I kind of focussed on the philosophy behind the API and the design of PW in general.

    I hope I “represented” PW well (there were talks about a lot of other CMSs as well). Some people asked questions and showed great interest in it, so maybe we can expect a few new German users in here soon.

    Also thanks to Marc who was also there and helped me out with some of the questions I couldn't answer right off the bat.  :rolleyes: If you understand German you should definitely watch his talk as well.

    • Like 9
  18. So I have an array of pages which all have a datetime field. But it doesn't make sense to sort them by datetime in this case because the date might only be an initial date (for recurring dates).

    I know I can get the day of the week using strftime. Is there also some magic voodoo way to sort the array of pages according to the day of the week given by the datetime field?

  19. As far as I know, there has not been a security issue in PW since I have been using it (which means since 2.2). By that I mean there has never been a “OMG, big issue, everyone upgrade to the new version of PW ASAP!!11” situation. Knowing other CMS out there, that's pretty amazing.

    1. Is this true? Has there never been a security issue (which the public would've known about)?
    2. If so, why is this? Is it because of the way PW is developed or something?

    The reason I'm asking this is that I realized I don't know the answer myself, and of course, this does come up in talking to clients. Also, I will be giving a presentation on PW at a German web conference soon, so a definite answer to this might be nice. :)

    • Like 2
  20. Sorry if this has been covered before, but I was unable to find it using the search. (If so, please just point me to the thread.)

    Given project is for an organization which has local sub-organizations. It's supposed to have “global” editors which should be able to edit (almost) any page in the site (that one I got covered) as well as “local” editors which should only be able to edit pages for their specific local organization. For example:

    * Homepage

    * Page

    * Page

    * Section New York

    * Section Los Angeles

    * Page

    * etc.

    So in this example, there would be a group editors which would be able to edit any page in the tree, but also groups:

    * editors-newyork: able to edit only “Section New York” and child pages of that

    * editors-losangeles: able to edit only “Section Los Angeles” and child pages of that

    Everyone (including me) would use templates like section-newyork and section-losangeles plus template-based access, but there's a twist.

    This is supposed to be expandable by the client, i.e. the client should be able to add a section-boston with a group editors-boston and corresponding permissions. I don't see that working with template-based access since the client is not supposed to create/edit templates.

    Another way to handle it would be the Page Edit Per User module, but I find that a bit cumbersome because it works on a per-user basis instead of a per-role basis. Is there an (easy) way to extend the module to use roles instead? (Disclaimer: I am not a PHP coder, I can't do this myself without help.)

    Or is there a way to implement this I am simply missing?

  21. I was also wondering how other language pack maintainers handle multiple versions corresponding to different PW versions. Manfred tells me he's got lots of 2.4 already translated (which is great, thanks!), but because of changes between 2.3 and 2.4, both language pack version differ greatly.

    I could imagine using GitHub tags or branches for versioning to keep seperate versions for 2.3 and 2.4 available (tags would probably be nicer since GitHub generates the Releases page from those automagically), but I'm not sure if it's actually necessary. Also, the Modules Manager handles language packs as well, which I find very convenient, but I'm not sure if it could handle versioned language packs? Maybe Soma could chime in on this.

    I guess what I'm ultimately wondering is: if the language pack repo contains the latest dev version already, can 2.3 still use these language files? Or should we just wait with the translations until 2.4 is actually released?

×
×
  • Create New...