Leaderboard

ovis u post.here same thng 3 yrs same ,,bug,, nobodys ever else seen peoples helps u ands u.no replys if u needs help.go back und first reply to peoples.thet helpd u here https://processwire.com/talk/topic/3363-image-field-description-not-saving/ and.here (!) https://processwire.com/talk/topic/11102-image-fields-stop-saving-descriptions-after-a-while/page-2

Some more improvements: Fields List and Values section on the PW Info panel Take a look at the "images" field in the screeshot - much cleaner and more informative. I have populated all the files/images related properties: filename, ext, url, httpUrl, filesize, filesizeStr, width, height, description, etc. Think of it as a cheatsheet with properties and values built right in. I have also added formatted dates and user names in parentheses for reference. Variables Panel I have also recently tweaked the Variables panel to be easier to read and to separate into columns with the variable name, its type, and value: Development Tip One final thing - a bit of a development tip using Tracy - want a quick way to see the results of a PW selector? Try this out in one of your template files: bd($pages->find("template=basic-page")->explode('name')); You will see something like this in your Dumps panel: On a live site in production mode, it pays to do it like this: if($user->isSuperuser()) bd($pages->find("template=basic-page")->explode('name')); This way, even if your selector generates an exception (quite easy to do if you accidentally enter an incorrect field name), no-one but you will see the error.

It is not intended to be set as global / default option sitewide. You definitly need to set it with every request. The default behave is, if you do not explicitly define an outputformat, the outputformat is the same as the inputformat: jpg => jpg jpg => setOutputformat('png') => png So, it is not a bug in the module, but a "bug" in the description here. I will update the description. Thanks for pointing out, @BernhardB.

Try leaving out the leading slash, i.e. echo $page->render('singleimage', 'products/singleimage');

Have you tried turning off (or adjusting) session fingerprinting? Here are the list of options: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/config.php#L195 Obviously add the setting to your site/config.php though.

Now I get (in Diag & Output panel): PDOException: SQLSTATE[HY000] [2002] Nobene povezave ni mogoe vzpostaviti, ker jo ciljni raunalnik aktivno zavraa. in C:\inetpub\wwwroot\site\assets\cache\FileCompiler\site\modules\TracyDebugger\DiagnosticsPanel.inc:287 Stack trace: #0 C:\inetpub\wwwroot\site\assets\cache\FileCompiler\site\modules\TracyDebugger\DiagnosticsPanel.inc(287): PDO->__construct('mysql:host=loca...', 'myusername', 'mypassword') #1 C:\inetpub\wwwroot\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy\src\Tracy\Bar.php(73): DiagnosticsPanel->getPanel() #2 C:\inetpub\wwwroot\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy\src\Tracy\Debugger.php(221): Tracy\Bar->render() #3 [internal function]: Tracy\Debugger::shutdownHandler() #4 {main} It shows user/pass for DB in plain view... A also can't move some panels, see the video.

Still some work needed, but I just pushed the whole new version to GH and renamed it as MarkupCookieConsent. https://github.com/CanRau/MarkupCookieConsent/ (beta) It's now doing everything on it's own, means there are no externals involved. EDIT 1: Added screenshot to repo EDIT 2: Okay, I would say anything works (at least in Chrome on Mac) except the translatable config fields. Both themes are ready having each 2 available positions (top/bottom). Extended screenshots to show all 4 versions Added readme Added to module directory http://modules.processwire.com/modules/markup-cookie-consent/ EDIT 3: Lanaguage fields will work using this patch from Ryan, or you can just wait for the next PW devns release (probably on friday) Changelog 0.0.9 - Changed style injection, now prepends to first <link> in head makes it easier to add custom css tweaks without the need for !important because of the cascading order 0.1.1 - Fixed issue with cookie not being set, two strings wouldn't recognize translation, default cookie expire now 1 year, updated readme 0.1.2 - Added minified CSS & JS 0.1.3 - don't remember what changed in this version 0.1.4 - cookie bar now fully translatable, added devns branch which is meant to be used with PW 3.x devns as it adds namespaces 0.1.5 - fixed issue on single language installations Still have to test some things. For example, you can now select a page from your tree as policy page using InputfieldPageListSelect instead of entering the url, so now the link should work with multiple languages, too. Though I haven't exactly tested it yet! The language fields draw my attention. They look nice but only default language is saving at the moment. So this is how I build the config fields using MarkupCookieConsent.config.php file I kept only settings for one field.. public function getDefaults() { return array( 'messageText' => __("This website uses cookies to ensure you get the best experience on our website"), ); } public function __construct() { $this->add(array( array( 'type' => 'text', 'name' => 'messageText', 'label' => __('The message shown by the plugin'), 'useLanguages' => true, 'columnWidth' => 70 ) ) ); }); I'm not sure if/how I need to define default values for languages, too? I checked some other modules from Ryan but there he still uses the config field building ways getConfigInputfields() for example, so those are not really applicable, are they? So visually everything looks good, even when inspecting the fields the field names seem to be alright.. Or is this approach not yet multi lang capable? Everything else should work already. Ah except for the Default settings button at the bottom. It's more like to-do list for myself ;-) Ah and regarding "dependencies". When "Enable Ajax" checked, the form will be submitting using ajax (magic! haha), anyway..just to let you know it's using plain vanilla js so no jquery or anything else needed. Although it should work well, it's only tested in newest Chrome on Mac and the script is not handling errors. It's actually removing the cookie information right after the click and then making the request. So worst case would be, considering any error, the message popping up again even so the user thinks he already agreed... I figured it's probably not the kind of module which many will use, cause when you're a little into PW you now how to easily include such an information yourself. But for me it's especially practicing PHP.. So I would really love to get some hint on the language fields Side note: For everyone interested in disabling cookies at all to avoid every possible need for this plugin checkout out this blog post from Ryan http://processwire.com/blog/posts/multi-instance-pw3/#more-session-control

MarkupCache is a simple module that enables you to cache any individual parts in a template. I'm working on a site now that has 500+ cities in a select pulldown generated from ProcessWire pages. Loading 500+ pages and creating the select options on every pageview isn't terribly efficient, but I didn't want to cache the whole template because it needed to support dynamic parameters in the URL. The solution was to cache just the code that generated the select options. Here's an example: $cache = $modules->get("MarkupCache"); if(!$data = $cache->get("something")) { // ... generate your markup in $data ... $cache->save($data); } echo $data; I left the markup generation code (the part that gets cached) out of the example above to keep it simple. Below is the same example as above, but filled out with code that finds the pages and generates the markup (the part that gets cached): $cache = $modules->get("MarkupCache"); if(!$data = $cache->get("city_options")) { foreach($pages->find("template=city, sort=name") as $city) { $data .= "<option value='{$city->id}'>{$city->title}</option>"; } $cache->save($data); } echo $data; That was an example of a place where this module might be useful, but of course this module can used to cache any snippets of code. By default, it caches the markup for an hour. If you wanted to cache it for a longer or shorter amount of time, you would just specify the number of seconds as a second parameter in the get() call. For example, this would keep a 60-second cache of the data: $cache->get("city_options", 60) I hope to have it posted to GitHub soon and it will be included in the ProcessWire distribution. If anyone wants it now, just let me know and I'll post it here or email it to you.

don't know how hard that would be to implement but in my case it would be better if it was configurable globally. maybe if it is NOT set it will stay "auto" like it is now, but if it is set to eg "png" it will use this as default? definitely no big issue - just a suggestion for a very very very small improvement

There is something weird happening, I'll start uninstalling plugins to see if something is messing up with that. Thanks adrian for your help.

Firstly, this should be sufficient - you don't want to try logging in more then once. $u = $users->get(4930); if ( $u->id ) { $session->forceLogin($u); } The first part of That error message is coming from: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L520 which shows that it is definitely receiving the $name populated as "guest". I realize that isn't what you are passing to it - so I am definitely confused The second part is coming from: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L488 which checks this: $user->id == $this->wire('config')->guestUserPageID I'd love if you could echo out the contents of $name and $user in that login function (starting here: https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/Session.php#L435) to see what it is receiving and see if you can figure out at what point in that fuinction it is failing.

If it's just a password generator, then why are you assigning $name to its results? $name = self::passwordGen(); I suggest you start by taking the output of $name and $pass (from that echo line) and in a template file try the login command there to make sure it is working. I would also like to know that the new user is definitely being created and the roles you want are being successfully added. I still keep coming back to that initial error - it suggests to me that the user you are trying to login is "guest" which suggests there is something wrong with $name or $user depending on which you try. It also might be related to overwriting $user - have you tried using $u ?

I already started using this feature and no problem so far (without the leading slash, of course). Are you sure "singleimage.php" is in the "products" folder (without any spelling mistakes)? In your screenshot we can see a "singleimage.php" file that is NOT in the "products" folder, but we cannot see the contents of "products".

Well, I don't know what passwordGen() returns so it's a bit hard to tell what's going on. Have you checked the values of $name and $pass right before you try to log them in? Regardless, as I mentioned above, you shouldn't be overwriting $user - try $u or similar. Also, please consider indenting your code here - it's hard to follow like that

It is still tagged as alpha:

Actually I just tested and I can successfully use forceLogin to login a user with just a guest role. The only time I can replicate that error is if I try to login the user named "guest". Keep in mind that: $this->session->forceLogin($user); will try to login the current user in the $user object, which will be the "guest" user. You need to specify the name of the user you are trying to login: $this->session->forceLogin('testuser'); or get the user object first, like: $u = $users->get('testuser'); $this->session->forceLogin($u); Remember it's never a good idea to overwrite $user.

I think you need to give some role to the user you are trying to log-in, otherwise they will just get the guest role (and they can't be logged in). See http://processwire.com/api/variables/user/#examples Also beware of using $user as your own variable, as you risk overwriting the built-in $user object.

The "guest" user can't login - simple as that really That account is just to determine what access all non logged in users have to the site.

With 0.9.8 version problem look like gone. Thanks for quick reply / fix !

Pleas use the <> Code Button in your Forumeditor since i get ophthalmic cancer while reading... regarding the user image thing you could take a read there: https://processwire.com/talk/topic/10662-display-user-image-error-on-frontpage/ and there https://processwire.com/talk/topic/9779-userimage-and-resize-doesnt-work-on-frontend-with-api/ regards mr-fan

Hey @ukyo - sorry about that - please try the latest version and let me know how it goes for you. That was actually some leftover code that wasn't needed anymore

Thanks Horst, but that didn't cure the problem. I have page-path-history installed. First I deleted the relevant entry in the database, then I even uninstalled the modul - no help. But then I tried something other. I was working on a local XAMPP version, getting the problems. I've uploaded a 1:1 copy to my webserver - and here it worked! So obvious the local system behaves differently to the remote server - who knows why.

I use serverpilot for simple sites, it works very well. Forge deploy it's better if you want more advanced features like SSL configured, integration with git for automatic deploys etc.

I've set $config->sessionFingerprint to 0 and it's working perfectly now, thank you Adrian!

Thanks for the new releases! I get used to it recently, updating Tracy when having the morning coffee Adding an "in-panel search as you type" feature would be handy I think. Basically I mean a search input above the panel tables (one per panel), in which if you start typing the table non-matching rows would get hidden. The problem is that not all panels have tables but divs.

No luck with the new version, error is stil there. Hm, it's working now ... don't know what I did...

Sorry about the database connection error. There was a problem with some attributes and the PW $database connection, but I have removed those two problem ones and now use $database. Please let me know if it is working properly again now with the latest version. I know about the panel moving issue - some do that weird resizing before they will move. It is on my list of things to take a look at - not sure if it's maybe a core Tracy issue, but I'll try to sort it out regardless.

Go for it. I'm using for a year I think and not a single problem. Take a look on http://forge.laravel.com/ to handle the setup and admin for you.

Vagrant and Virtualbox on windows would make sense: using both windows and linux on your laptop on the same boot partition and sharing files on a second data partition. For example, you would have the ease of windows and the sudo and ssh command line of linux.

Ok, the PHP 5.3 issue should be fixed in TracyDebugger and a PR has been submitted for Performance panel as well.

@LostKobrakai You were right, the host had php 5.3 configured, but changing it to php 5.4 did not make the problem go straight away. Maybe still some cache somewhere. I had to empty out config.php in the site folder, reload the pages, and put config.php back. Maybe there is a better way for doing this but works for me. After that everything worked. So in the end it was the old php 5.3 on the host like you said.

Is the server running php 5.4? This does suspiciously look like a 5.3 install, which doesn't support short array notation with [].

This is quite a change to current implementation, but I'll have to agree. A split button is widely used and well known pattern, while the delayed dropdown we've got now is pretty much unknown, at least to me.. and probably most regular users.

I agree. And I'd like to suggest "Publish + Add new" to "Publish + Add Another" as it is a bit more clear in suggesting: "Another of the same template". One more thing, maybe it's a good thing to change the button to be like this example attached. Not advanced users may find it easier to understand.

Updated and fixed Russian Language Pack. Completed translation main part of the administrative panel. Add Translation for some popular modules like Markup SEO PW-PW-LanguagePack-ru-RU-master.zip

Nice update, Ryan! My only suggestion would be to change "Publish + Exit" to "Publish + Close" as "Exit" seems a little much, if you know what I mean...

I enthusiastically approve of this feature request

Updated first post (4 screenshots now, readme and code fixes)

I might have found a solution to this problem. On the "Page Edit Link" module, I added a default class for the link (under "attribute option" > "class"). With the new class on the "a" element the page renders fine. Still I think this is something unusual.

How about such a syntax? I think this would be flexible enough for any kind of tagging structure. // Get me the tags, // which start with "Tech_", // are used in the tags field of "templates=posts, date>today" // and sort them by number of occurences (maybe named count) $pages->find("template=tag, title^=Tech_, in.tags=[templates=posts, date>today], sort=occurences"); // Not limiting to upcoming posts or even posts $pages->find("template=tag, title^=Tech_, in.tags=[*], sort=occurences");

Looks amazing. Looking forward to purchasing. Are you looking for any feedback at this stage or would you rather keep developing it? Can we get BETA access?

Description This module adds icons based on the file type uploaded. It also lets you change the columns, etc. You can watch the video for more details or download and install. To make it work (do not know why) you have to change any configuration setting and save. Version Alpha version (0.0.1). Updated: 0.0.2 - Added Json name shorter, icons and columns. Updated 0.0.3 - Config in columns Updated 0.0.4 - Video and Audio extensions added. Updated 0.0.5 - Fixed select files and drag to upload div position. Updated 0.0.6 - Execution of the module only in the administration. What a fail! Github

Ovi, I'm in agreement with Soma here that you need to try out a fresh PW install with no 3rd party modules to see if you can still duplicate the issue. If so, it would point to something with the server, since nobody else has ever reported a similar issue. Sometimes extra Apache modules like mod_security can cause strange stuff in this respect, so that would be something to ask ServInt to look at removing or disabling temporarily. But if you do have a default/unmodified PW installation reproducing the issue, and don't mind providing me access to it, I'd be happy to login and take a look to see what I can find.

No not *. If as custom code for a page select you need to use role id.

Sounds interesting. Here's one way you can do it: $table = $fields->get('your_page_field')->getTable(); $query = $database->query("SELECT data FROM $table GROUP BY data"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $items = $pages->getById($ids); // $items is a PageArray echo $items->implode("\n", "<a href='{url}'>{title}</a>"); If we were to add this to the API, I think I'd want to make it accessible from a regular find() selector, rather than as a separate findSelectedPages method. That way it could be used with things like InputfieldSelector. Perhaps something like this: $pages->find("your_page_field=:selected"); ...where ":selected" is a keyword is would recognize to execute this behavior.

AlternativeGridImages module for Processwire Details Add a slider directly proportional to the size of the images introduced in the input field image. Installation copy AlternativeGridImages folder to /site/modules/ Screenshot https://github.com/LuisSantiago/AlternativeGridImages Updated 1.0.6: - Renamed altGrid as AlternativeGridImages. (Thanks @adrian) - Changed styles. - The slider value is saved in a cookie. (Thanks @Martijn Geerts) Updated 1.0.7: - Limit the number of characters in the file name (all items have the same height) (Thanks @enricob)

There's no fieldtype or module for this, because PW already has all the things you need to do flexible and powerful tagging. Using page reference and the powerful inputfields it offers is the way to do it in PW, it's not an "alternative" way, it IS the way. It is far more flexible and powerful than what you have in MODX and most other CMS'. Everything else that stores tags in a textfield comma separated isn't going to give you the power you usually need with tagging. You won't easily be able to use that in selectors and so on. If you're building a new fieldtype, inputfield for tagging, you don't really understand what PW offers already and you will using the same approach at the end anyway. There was already lots of discussions and people were trying to come up with modules or fieldtype for it, but none of them really is a better solution. You can now install the Autocomplete module that comes with PW and use that to search and create tags on the fly. It has even improved from Ryan's blog profile, to create new tags without saving the page. The interface is simple and clients have no problem with it. As mentioned before, I also mostly use ASM select and the Autocomplete feature. Takes couple minutes to setup and can flexibly be used to later expand and use the tag pages for different stuff like listings,sorting and filtering etc. The page find selectors are there to do powerful stuff with page fieldtype already. Further you can use the tag pages later on to expand it with additional fields for and image or description. Possibilities are endless and a feature I love the most in PW (one of the big reasons I love to use PW).

This is what it currently does. It's all handled by the installer (/install.php on a new installation). The profileImport() function creates these directories: /site/assets/logs/ /site/assets/cache/ /site/assets/sessions/ /site/assets/files/ When the mkdir() function fails, it reports this message in red: "Error creating directory: $dir". The error message(s) would appear on the screen after you've entered your database information and clicked submit. I had an experience with one web host where they had some automated process that came through regularly and changed the permissions of directories, without my knowledge. Of course, such an automated process isn't exactly CMS friendly. Another situation where permissions on those directories could be lost is if you have a site running in one location, and then copy it to another. If you haven't transferred it in a way that retains permissions, you'd have to fix the permissions on those /assets/ directories (and files in them). If you have shell access, you could do something like this: chmod -R og+rw /site/assets Is it possible you've run into something similar, or can you think of any other factors?