I built a translation system for fun which reads all trans()/Lang::get() calls in my app and presents them along with their current translations in the localisation files in resources/lang, so that an admin user can enter new translations which updates a single localisation file on the fly.
Everything works as intended, but there's one minor annoyance: every time the form is sent and the localisation file is updated, the page reloads (through a redirect()->route() call, not e.g. redirect()->back()), but most of the time, it still displays the old information even though the file has been updated properly.
If I refresh, the changes show up after 0.5-5 seconds, which makes me assume it's a cache issue. So the question is: can I trigger a language cache ignore while I'm in the translation system, or is there another and/or smarter way? I did try sleeping for a couple of seconds, but it made the user experience kind of crappy.
I've got the same issue.
I added in my controller sleep and info to extra refresh the page from js.
sleep(2);
return back()->with("refresh","yes");
and then in my view:
#if (session('refresh'))
<script>
location.reload(true);
</script>
#endif
I know it's a stupid solution but it works. If somebody know a better way to do it, write me a comment please.
Related
I'm writing a Joomla plugin, which is basically just a wrapper around an application written in CakePHP (version 3.3; not in a good position to upgrade this at the current moment). I'm running into various issues with session data.
First problem is that Cake's Request object creates a Session object, which does not allow for the possibility that the PHP session might already have been started; it throws an error in this case. (I see no changes in this area of the code in Cake v3.6.)
My original solution to this was to have my plugin code close the Joomla session before starting up Cake, and let Cake do its own thing with its own cookie and session table. But by doing this I lose any changes that Joomla might make to its session after my code runs, which isn't ideal.
Next attempt was to hack the Session class slightly (proof of concept; a proper implementation to be made without any core changes if it works) to allow setting the _started member to true before starting the dispatcher. This works, in that Cake and Joomla data are now saved together in the Joomla session table.
However, Cake's session data includes Auth.User, the record of the user currently logged in. That record includes objects of type Cake\I18n\FrozenDate. On any page load after this has been written into the session, that class is not yet available (Cake's autoloader hasn't run) when Joomla loads the session. So those fields come in as __PHP_Incomplete_Class, which then breaks other things.
My current solution to this is to reload the entire session at this point (session_reset), first copying any uncommitted changes Joomla has made to $_SESSION, then restoring them after the reset.
In limited testing so far, this seems to be working. But I'm wondering whether I've missed some obvious problem, or obvious easier solution. Any comments, suggestions, or thought-provoking questions much appreciated. :-)
For example, is there some way for me to run Cake's autoloader before Joomla initializes the session, without hacking the Joomla core at all? That could be a simpler solution.
If this turns out well, I'll see what I can do to make the code available.
I have this weird problem with one of our file. It's named Setup.php and stored under protected/components/
This file is mainly for emails, header, footer generating functions etc. We found out few days back that when we changed the footer layout in this file, the old footer would still show, despite doing a lot of debugging and edits (even removing the footer function itself), it still shows the old one. This is a shocker. I'm aware of cache issues but does Yii cache the whole PHP file? Is this even possible? We are positive the footer used the same function from the same file.
I'm again having this issue with another function in the same file. Determined it's a problem with the component file and Yii, I would like to seek assistance from the Yii users.
Please let me know your thoughts. Thanks in advance.
I using CakePHP with Backbone.JS, I set up a controller just to give me a JSON output for getting my data, e.g. client names etc, to pass into each Backbone model.
This was all working, or appeared to be, however, it seems that it now gives me some random 403 errors when the page / from is saved or reloaded. But I have no idea why? If it can access it to start with, and does, then why would it not have access after a save or reload?
I have tried, $this->Auth->allow and it dose appear to fix the problem but this data is or could be important and need it not to be access my everybody who might guest at my access path.
Now I have read a number of articles on her, most point to read/write access on the files your accessing, but in my case its just a path /XXXX/XXXXX/myjson/clients For example.
Now I can post my code, if needed, but I am not sure what the problem is, is this a CakePHP issue or is Backbone not requesting the data right?
Please be aware that I am dyslexic, please be kind about my question, if I have not explained myself right. Then please be me some time to re-word / edit my post.
Thanks,
For any one else looking at this, I had added autoRegenerate to the Configure Write Session. For some reason it looks like CakePHP was taking to long to regenerate a new cookie and request my information at the same time.
I have an ASP.NET MVC web page that has a file upload control. Under rare conditions the file referenced by the user moves or is deleted on the filesystem prior to the user triggering the post to the page. In IE9 the page successfully posts but the ContentLength is zero (expected) and can be handled server-side. However in Firefox I find that the POST action never reaches the server.
Is there anyway to detect that the file reference is still valid prior to posting the page? Or a way to detect that an error occurred client-side during the POST due to the moved/deleted file?
Using just input type="file", you have no access to check whether the file actually exists until an upload attempt is made. There are some emerging functionalities like FileReader which may help as browsers mature (as it's not available in all browsers) that should make the upload process far smoother (and will make detection of this situation more simple).
If you use an Ajax style upload process, you could initiate the upload right away to help prevent the issue from occurring in the first place.
Or, a bit hacky: one idea for Firefox would be to add a setTimeout in the onsubmit event that fires after a second ... and checks to see if the upload started (by querying the server using Ajax to a JsonResult action/function that can quickly see if an upload started, etc.). It's a bit messy though as you'll need to worry about timing issues -- and may be overkill just to handle the cases where this is occurring.
Flash messages in Symfony projects give feedback to website users after an action is performed. They usually only show for one page load after the action is triggered.
Unfortunately, when caching is turned on my messages fail to appear and only the cached version of the page is returned.
In one instance a version of a page with a message was cached, meaning that the message was displayed to everyone.
Is it possible to make the cache aware of the flash messages?
There are two options, the one mentioned by benlumley:
Turn with_layout off, so that the layout is not part of the cached file. This will not prevent your problem is your rendering of the flash is inside the action template though.
Clear selected parts of the cache whenever you set and display the flash (remember to clear it after the display of the cache, otherwise you'll bump into your problem with the flash appearing to other users again. Alternatively you can choose to programmatically disable the cache once on the page that displays the flash (see the symfony docs on 'Configuring the Cache Dynamically). The last option is quite dodgy in my opinion and should be used as a last resort, since for example redirects can screw it all up.
No matter how you do it there is no optimal solution that can make your flash messages magically bypass the cache.
There is not automatic way to make symfony cope with this.
The best/most common solution is to disable with_layout for either all of your cached actions, or else just these particular actions where flash messages have to be displayed. This normally resolves the issue as most people tend to output flash messages from the layout rather than within the cached templates.