szabesz

I also support these, with the additional idea of turning the labelled buttons into icon only "tools" (supported with tooltips). We need room for the filenames, so the shorter the buttons are the better. Also, we should not forget the case of a single image, confined into a narrow Column Width (mine is 30%). If we take a look at these screenshots, we can see a two glitches in my usecase: Namely #1 proportional grid mode: image extends beyond its column. We can adjust the preview size, however I can imagine a narrow image that cannot be made small enough to fit. #2 list mode: transparency is not handled

You might need to switch to PageTable or something similar. You are hitting the limits of what a Repeater is capable of. People often run into this issue, see for example: https://processwire.com/talk/topic/13089-repeater-field-limits-and-server-timeouts/ Not long ago I even posted a request in the Wishlist topic section: https://processwire.com/talk/topic/13112-the-possibility-to-specify-a-maximum-item-limit-for-a-repeater-field/

That's cool, but please do not forget to publish your Nette Forms module either when the time comes (Just kidding, I'm sure you will not "forget" it.)

Thank you sooooo much! And +1 for Martijn's request

Hello and welcome to the forum, Is it possible that your template files use relative URLs? If so, the simplest fix might be to add the base tag to all pages: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base eg: <base href="<?= $config->urls->templates ?>"> which should resolve to: <base href="/localhost/restaurant/release/site/templates/"> or you can edit all your code to use something like: <link rel="stylesheet" href="<?= $config->urls->templates ?>styles/main.css"/> Hope this helps. EDIT: the example base tag does not include the protocol. EDIT 2: you probably do not use relative URLs So option two should be the way to go....

Thanks for sharing!

That is why I was pointing to the new Variations list as a starting point, which already has thumbnails and some basic info we need. Sure, it would need additional features others have already described above, but just one more: the columns visible might be customizable, so we can fine tune the list to our needs. True, the possibilities are endless, and we should figure out what tools are really missing in the current state. After all, system design precedes implementation

Hi, I have just checked it out. May I suggest changes to the <title>s? Default panel from module config settings to something like: turned on in module's settings "config settings" is sort of word repetition, PW labels the buttons in question "Settings" so it maybe enough. I also tried to use the same point of view in the case of both titles: why one option is turned on or off, so the messages are consistent. Panel status changed once to something like: turned on "Once" or maybe: turned on by "Once" ? I also tried to be short The enlarged icons are a bit easier to recognize and probably about the largest in size we can use. Thank you!

Hi, Or you can just simply Password Protect with htaccess: http://www.htaccesstools.com/articles/password-protection/

Hi, You might be interested in this thread: Create simple forms using API https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ If you need a lot of features that are already supported by the backend, then probably yo want to go that way. If you want to imply that your users are not logged into the backend, you need to implement all the features for the frontend, of course. So it depends on your needs, I suppose. I think it is easy to utilize PW's API, so the more you use it, the less you need to code. After all, that is why we love ProcessWire

As far as know, there is no such feature, at least I have not found it yet. Maybe Soma wants to add this feature to his ClearCacheAdmin Module, if its possible of course https://processwire.com/talk/topic/13042-clearcacheadmin/

One more thing I forgot to ask: how can new "users" figure out the what these icons mean?

I would just use fill="green" for Default, fill="orange" for Once (if you prefer the "PW magenta", why not...). I opened the panel in each of my three browsers (Chrome, Firefox and Safari) and it looks quite similar to yours:

A big thumbs up! You did it again Adrian! One teeny-weeny question though: can we have some color coding for the icons please? You see, they are rather small (we want to save space, so it is expected), however the tick mark is just a thin line, the number one is also "just a thin tick mark" transformed a little bit, so my I eyes+brain are a bit stretched to their limits when differentiating them. Speaking of languages: do not expect me to know too much about Hungarian grammar either... When we (try to) learn a language from books, we are forced to learn some grammar too, however, when growing up with it, we do not need to elaborate too much on the inner workings, so only a few of us do so. BTW: if you have the time, you can speed up your learning process by using this: http://ankisrs.net (you might have already tested it, I am currently in the process of building my very first German cards.)

Hi, Maybe you can use Soma's JqueryDataTables module as a starting point: http://modules.processwire.com/modules/jquery-data-tables/

It seems to be covered by the docs: https://processwire.com/api/selectors/#sort

Aha, sorry! So it was part of the same line of thinking and I should not have separated it. "Enabling" is probaly a better word in this context, but I'm just an English learner...

Additional panel? Well, we already have quite a few of them. Isn't it possible to manage all this in the current panel? Maybe I'm missing something, but it would also be a bit confusing to manage related panels. Currently all panels are completely unrelated, which is probably the expected behavior. Sounds OK! Once we can tell those states apart, we will also be able to visualize it

I'm not a hardcore dev either and my only encounter with Laravel was the one and only occasion when I fiddled with it for a few hours. Laravel seems to be a heavyweight campion with all those 20k+ files you need to implement even a Hello World app. Incorporating only about 1800 files, ProcessWire is definitely on the lightweight side. With its friendly community, constantly improving documentation and features I opted for ProcessWire instead of all the others I also checked out. ProcessWire sites are also easy to manage, upgrades are rarely an issue if performed with some very basic care, (say, if you modified your .htaccess, then do not replace it with the default one while upgrading, etc...). Even if you run into issues, our above mentioned friendly community is ready to help right here in the Forum

I always think of ProcessWire as complete PHP framework bundled with integrated browser based content management tools (hundreds of tools, actually). ProcessWire should be listed here: https://en.wikipedia.org/wiki/Comparison_of_web_frameworks#PHP You do not even have to use the CMS if you don't want to, but why reinvent the wheel?

If we keep the Validator panel off and enable it temporarily with the Once option, we get a similar - though not exactly the same - effect, if I'm not mistaken. When we decide to use it more than once, now we can just choose Sticky. When you switch to Sticky, you do not have to click anywhere anymore just to validate the page once more. To me it looks like a good workflow. An on-demand validation would stay on-demand, but what if we are in a long session of fixing some validation issues? In that case we would need another option to switch between on-demand and automatic in order to save some time and clicks. Another issue: The Once and Sticky button features might need some additional polish: currently there is no way to tell apart Sticky and the standard default state, after a while we cannot remember the reason why those checkboxes are on or off. Some sort of color coding might be good to implement to solve this. Say, green is used to indicate the temporary Sticky state. Or maybe an icon (::after selector probably?) An icon is more descriptive, so probably a better solution.

Thank you very much! Now the "Panel Selector" panel looks like just the one on your screenshot and works fine. Implementing it was really cool idea, I also used to switch panels on and off a lot of by going to the PW settings, so it is a real timesaver.

Sorry for not being clear! Version 1.4.9 did not solve the problem of the labels sliding under the checkboxes, so if it is ok, please to add those styles to Tracy. Since you mentioned it, I also tried to fix the issue with "all: initial", but could not figure out anything that cloud work.

Thanks Adrian! Probably this change made the checkboxes clickable. As for the css issue, I could fix the issue of the boxes covering the labels by applying these rules: #tracy-debug input[type="checkbox"], #tracy-debug input[type="radio"] { width: 12px; height: 12px; position: static; } Sure, the radio version is not needed in this particular case, but my css "framework" also define its rules for that selector, so just in case... Position was absolute, so that is why the labels slid underneath the checkboxes, and dimensions were also quite "incompatible", so to speak. I will look into my performance issues as well (when I have the time) and report back. I've also noticed the new version being released in the meantime. Keep up the good work, your fans – including me – love this gem!

Thanks Adrian! I could speed thing up considerably (especially by switching to stable from master, but turning off two additional panel helped too.) However, I cannot use the checkboxes in the Panel Selector panel. Probably my css rules conflict with the ones needed for this panel to work. The checkboxes are situated over their "labels" respectively and the click event is not handled at all, not matter where I click, nothing happens. I did not spend too much time to investigate what causes this, so I don't know it yet, but by turning off all linked styles (by using Chrome's Web Developer extension by Chris Pederick) the layout of the panel is back to normal and the checkboxes work as expected. Isn't there a way to make sure that this panel works whatever css rules the underlaying page has?