szabesz

This page points to a forum post that is no longer valid (probably because of the Forum update?). Current url: Anyway, it is easier to install a beta version of the profile which is also good for checking out how it was made (blog-site2.zip linked from this post): For a more up-to-date blog profile I recommend:

@Jonathan Lahijani Thaks for the intel Jonathan! OT here, but any chance of releasing you video tutorials soon?

I vote for Disabled Panels for Restricted Users

It is a CSS/JSON like syntax, which is quite familiar to us, so it is easy to deal with in this regard. As you pointed out, the drawback is that solution is not flexible when refactoring field names, but if you want to keep it simple then it is something that is just good enough, I think. This way it will be recommended to setup the columns when the development of the site has reached the level when the field names are unlikely to change. Sooner or later we stop renaming the fields anyway

Sounds good, but what does "enter field names to the existing field's label (title)" exactly mean? How would that actually work?

@adrian At the moment I do not have the time to test these new "tracy-restricted-panels" permission features, however, may I point out this "strange sounding" title? Restricted User Disbled Panels (vs e.g. Disbled Restricted-user Panels ?) English is far from being my mother tongue, nevertheless, if I understand it correctly, then we restrict users to a certain set of panels, and this set of panels can be configured via enabling/disabling them. So it is not the panels that are restricted but the users themselves, because they have restricted access. Or am I mistaken? Sorry for being picky on this one, but I just do not comprehend this title as it sounds ambiguous to me and my proposal is not the best either but I just coud not could up with a better one

+1 Oh, and thanks for this brand new User Bar customization feature!

You can also automate it by using a hooks, however, a repeater is clearly not a straightforward solution to this problem, it can be just be used as a workaround when also implementing those additional hooks.

@LostKobrakai and @pwired Thanks for directions. I'm going to have a busy day this Monday, but will definetally take a closer look of the posts you provided. Note, that I've already adopted @clsource's (Camilo Castro's) wire render pattern thanks to his recently released Processwire Ghost Writer profile which I am currently refactoring to my needs. @tpr Well, there are various reasons for not taking the template engine path, at least not yet. You have almost converted me and I was about to jump the Latte bandwagon, but currently I want to work with the least amount of dependencies and a template engine is just another framework to add to he system which is not really needed for standard, basic websites which I'm currently interested in.

Warning: it's going to be TL;DR so proceed with caution In an effort to come up with an optimized development workflow, I have come up with the idea of implementing most of the required template files in the form of static HTML files first (based on a "CSS framework" which will also serve as the CSS base of the site). Basically I want to implement most of the frontend without touching ProcessWire in the first place. The advantage of this approach is that it is a lot faster to work with only HTML/CSS/JS during the frontend design phase of the project, and the end result of the design phase can be "similar" to a wireframe/mockup which can be presented to a client, but this "mockup" actually represents (say) 80% of the final design, so it is something that is rather good to work with when the backend development with ProcessWire begins. This also means that my ProcessWire template files will be mostly implemented with <?php echo ... ?> and alternative syntax control structures that can be "just injected" into the above mentioned static HTML template files to turn them into ProcessWire template files later on. So far so good, but my ProcessWire template files are going to be separated into "template file partials", and I also want to implement the static HTML template files in the same way, so that they are also separated into "template file partials", and ideally organized in the very same structure. E.g. I will include the site's navigation in the ProcessWire template file like this: <?php echo $navigation ?> So I want to do the same in the corresponding static HTML template file, something like this: <div data-template="partials_navigation"></div> If it can be done recursively, then I can implement the same in both cases. With ProcessWire, I use wireRenderFile() to render partials recursively, so I just had to figure out what to use in the case of the static HTML template files. What else to use if not JavaScript? I started off by googling around, looking for some pre-made solutions... I did not find too much that could help me, the only thing useful I could dig up is "HTML Imports", for example: http://blog.teamtreehouse.com/introduction-html-imports Note, that currently this technique only works in Chrome(-ium), but that is my choice in frontend development anyway. I've read somewhere that other browsers might never implement "HTML Imports", but that is to be seen... I have found a lot of articles explaining the basics of "HTML Imports", but I could not find any libraries or frameworks nor even something similar to what I need, so I implemented a proof of concept version of mine: I'm quite happy with the result so far. The JavaScript code needs some additional error handling, but otherwise it seems to do what I need. Here it is in action (Chrome(-ium) only!!!): [...no longer live...] And here is the source code for those who want to take a closer look: [...old stuff, I removed it to save space...] However, I'm pretty sure that someone must have already come up with this idea, so I'm asking the ProcessWire community if anyone can point me to similar solutions, something that I can study and/or use. So any piece of advice that might help me to take it to the next level, or any objections to this "HTML Imports" technique, any disadvantages? Thank you in advance

@Robin S Of course, a dedicated solution to this problem would be welcome, however, limiting the number of repeater items has its own advantages too. A "limited repeater" can be a tool for more general issues, such as maximum number of slides in a slider, maximum number of widgets in a sidebar, etc... and in the meantime (i.e.: while we are waiting for the above described "grouped fields" ) implementing a limit for the number of repeater items seems to be a lot less work too. It is a valid hack to impose a limit of one item per repeater, and we can probably extend it so that it checks the number of repeater items and removes the button when the limit is reached, but this is still more of a hack than a straightforward solution. So I'm still for a core support for "limited repeaters"

@ryan and @Jonathan Lahijani First of all, thanks for the blog post, I really enjoyed it and learnt a few more things to guide my future ProcessWire based development efforts. Second, a couple of suggestions: An extra "these" should probably be removed: "...making these these dependencies work nicely..." And more importantly: the WORDPRESS VS. PROCESSWIRE chart could be updated with links to the modules in question as well. During our forum support sessions, it will be a very useful chart to point to when dealing with beginners coming with some WordPress background. By including the missing links to the modules the chart can be made more useful in this regard.

At the and of the video, you can see how to setup the database. This is what I found, but you might be able to find better tutorials. I've never used LAMP, but phpMyadmin comes with it, so you can just look for phpMyadmin tutorials.

This issue is not really about ProcessWire, but LAMP+MySQL if I understand it correctly. You can google around, or look it up on youtube, eg:

+1 @bernhard Who is this clever developer you are referring to?

During the installation process ProcessWire needs write access, however, after you have installed PW, it is time to be more strict, and remove as much permission as you can on the server in question. http://processwire.com/docs/security/file-permissions/#securing-writable-directories-and-files "If the installer populates 777 and 666 permissions, this translates to directories and files that are readable and writable to everyone, which is not a good scenario in shared environments. But without knowing more about the hosting environment, they may be the only permissions that we know for certain will enable ProcessWire to run. In either case, please read on for more details. In most cases you can further lock down these permissions with a little more information."

I see. So you gave r/w permission to "other", in other words to anybody, so probably that is why it does not complain.

You mean 600, right? If so, that should be considered to be secure. If others than the owner can manage to write files set to 600 [rw-------], then it does not matter too much if it is 400 or 600, I suppose.

Hi, Have you followed this: http://processwire.com/docs/security/file-permissions/ ?

Well, I know this idea will be against simplifying things, but what if this behavior can be turned on optionally, so it is not completely removed?

I do like (and use solely) the Detect Mode being on, so I'm against of removing it even tough I also see that it can lead to confusion. Tracy has so many options to choose from in a diversity of areas that it has become quite a challenge to familiarize ourselves with it anyway. However, I do not think getting rid of functionality is the way to go, although probably it is the easiest solution sometimes, so it is you who needs to decide in the long run. So we might be able to clear things up a bit by using different terms, not enable/disable. What if we come up with some flowchart like setup-help, something like this: I use yEd to draw things like that and would be happy to do its first version if you think it might help. (You could even build a "setup wizard" based on it, but that might be overkill and a lot of work.) Or, we can just make a table like chart to summarize the various states and results of the settings, something like this "Value of variable" chart in this post: https://www.virendrachandak.com/techtalk/php-isset-vs-empty-vs-is_null/

Besides @kongondo's evergreen post, I also recommend this one:

Yeah, this is what we've been discussing for a while in different topics. And there have been various proposals to move forward in this area, like yours. eg:

Which one is the recommended repo to report issues currently? ryancramerdesign/ProcessWire or processwire/processwire ? Do we have a guideline to choose between the two? I do not remember seeing one.

Definitely! Thank you. I think it also helped a lot in being able to more easily find the panel one needs to spot, the alphabetical order might be the one to keep, and probably there is no need for "arbitrary" grouping (at least I was not able to suggest groups, because of the diversity of the functions the panels represent).