As the subject states, I have made some minor CSS updates via one of the LESS files on a Ghost theme but when I refresh I don't see the changes reflected. I'm assuming since I'm new to LESS and node that perhaps I'm missing compiling LESS to convert it and save the CSS output. Is this like a "watch" task I need to add to a gruntfile? I'm trying to understand how is that all these work together.
For those as me new to LESS and facing similar issue, I found this article really helpful http://ericnish.io/blog/compile-less-files-with-grunt/ after some reading I was able to update LESS files and see the results on css styles and the site.
Related
I'm putting together a demo app in which I frequently add content and new React components. I have just added the component react-timeago for showing when the latest changes were made to the site. Now I want to give that component the right timestamp.
At worst, I suppose I could show the last time that the server was started. I am using webpack-dev-server locally. I haven't yet gone live with this site, but it will probably (like webpack-dev-server) be an express-based solution when I do. So one option is perhaps to do a grep on an express-generated logfile for server start entries. Solving that would solve the question to an extent. It's worth noting though that adding content would not require a restart, so this solution is perhaps not ideal. Presumably, I could use some kind of middleware (logger or otherwise) in express for this.
Another possible approach might be some kind of directory watch mechanism that records the last time a change was made. Should I somehow hook this into a redux state, for example? There are so many components available that it's difficult to know which ones to put together (with my limited experience in this area) to achieve this.
My site is a lightweight single pager and I'm loath to add any kind of datastore behind it at this stage as it seems like overkill to me.
I can also mention that I'm using webpack 2. Aside from that it's a really basic React app with a couple of components.
To summarize, I am after some way of looking for added content (eg. mp3 files) or changed code files, and getting that timestamp into my react-timeago component.
As #Joe Clay suggested, I used Webpack.DefinePlugin to fill a constant with the current time at restart. This worked fine, I added the following lines into my webpack.config.js:
var dateString = new Date().toDateString();
...
new webpack.DefinePlugin({
LAST_UPDATED: JSON.stringify(dateString)
})
And was able to access the the constant in my React component:
<div style={{marginTop:120}}>A sinewave440hz demo site.<br/>
This site was updated
<TimeAgo date={LAST_UPDATED} formatter={formatter}/>.
</div>
Recording changes in the assets could also be done at startup if the previous state of the assets was recorded somewhere.
I have deployed a document library hook which includes many jsp files under custom_jsps.
Recently, I wanted to change folder_action.jsp, so I changed it and deployed it normally in document library portlet.
As it was expected, a folder_action.portal.jsp was created containing the original file.
However, I've noticed something strange. After stopping Tomcat both folder_action.jsp and folder_action.portal.jsp are deleted(this is not happening for the other files that come from the hook), and when it is up again a really strange thing happens. The folder_action.portal.jsp contains the changed file and the folder_action.jsp is the original file.
Has anyone met something similar ever? Any help would be appreciated.
You might run into a very nasty issue: You must only override a particular jsp from exactly one hook. If you override the same jsp from two different hooks, the scenario that you describe might happen (on undeploy). Worse: Order is not maintained, you might have some "wrong" files left over.
Find the two hooks that override the same jsp and determine which you like better (or merge the two). Find some more horror in this answer to a similar question
At the moment when you go to select an image inside an entry using the EE default file manager, the default view is 'show files as a list'.
Is there a way to show the thumbnail view as the default?
At this point I would be happy with a core hack.
I don't usually use the file manager for sites (much prefer Assets) but this client had a tight budget
I've wondered about doing this in the past as well - turns out it's pretty simple. Open up ee_filebrowser.js and search for the first instance of a("#dir_choice").val(). Immediately after that add this:
; a("#view_type").val('thumb').change();
Make sure you include the leading ;.
I've only tested this in Safari but I can't see why it wouldn't work everywhere. Incidentally, JS beautifier makes this sort of thing infinitely easier.
I don't recommend hacking core for any reason and I suggest it should be avoided at all cost.
With that said, I will provide what I've found out just the same.
Looks like the following files, in EE 2.5.3, are what you'd want to edit:
/themes/javascript/compressed/jquery/plugins/ee_filebrowser.js
/system/expressionengine/libraries/File_field.php
I found these doing a file search in my text editor for view_type which was from the id of that dropdown. The javascript is minified so you'd probably want to un-minify it and then rewrite the part which handles the switch. I'm not the best JS/jQuery person out there, and un-minified js makes it a bit harder too so, I won't offer any more than what I've found so far.
Consider pulling out the parts parts from the two files if you aren't great with js and maybe start a new post tagged accordingly.
Also note: there might be more to this than just those two files so consider this answer a start and nothing more.
I've made a change to what I thought was the main default template page in a hosted version of Sharepoint 2007, but the search page hasn't picked up the change.
Can someone please either give me a list of all the default page files, or tell me how to identify them? It's really important that I add a JS script call across all pages everywhere on the site.
Thanks!
Point of clarification: for now, I'm just trying to include a jQuery reference. I really don't think I'm trying to do anything complicated or unusual - I just want this include to be be global across all pages by default. I've modified /_catalogs/masterpage/default.master with:
<HEAD runat="server">
<script src="/Global%20Site%20Files/jq1.4.2.js" type="text/javascript"></script>
EDIT
I just did a search of the source code for a statically defined meta-tag and found that the default.master I altered is in fact the only file in the search results!!! This means, as far as I understand, that my jQuery include should have worked! I'm more confused than ever...
Hi What i can see is the way you are refrencing is wrong you should use full Qualified URL for
src attribute in script tag currently you are using relative path that might be a cause of error
Turns out that the issue is not a question of multiple page templates or master files. The search results page (which is the primary page in question) does not use the default.master file. Moreover, even as an administrator, I don't have the ability to edit the search results page.
In the end, it looks as though I was looking for what I thought was a solution, but was really just a red herring. I'm going to repost a more specific question to my problem.
There is some precedent for search-engine-ranking-related questions on StackOverflow, so please don't close this question. It's programming-related to the extent that HTML META tags can be called "programming".
Here's the problem:
We make FogBugz, the software project planning and bug tracking suite.
Either we did a great job with our old documentation or a crummy job with our new documentation, but for most of the popular searches on FogBugz terms, documentation for our old versions comes up.
Here's an example. For context, our current FogBugz version is FogBugz 7. The top two results for that search are for FogBugz 5, which is positively ancient.
As best I can tell, there are several options for getting these results out of the top slots, but each has problems:
A NOINDEX tag, but what happens if someone is actually searching for help on an old version?
Finding the incoming links to the old documentation and placing a NOFOLLOW on them to deprive the old docs of PageRank. Problem here is that it's really fiddly to find the links to the content, rather than changing the content itself.
The unavailable_after tag, which is just a time-delayed NOINDEX, with the same problem of removal rather than demotion.
I just want these old documentation versions to stop competing with our current versions, without being completely unavailable.
An approach I used in the past (3 years ago)
Change the URL to your old documentation, and change your own links to point to the new url. e.g. abc.com/docs/fogzbugz/v5/xyz becomes abc.com/docs/fogzbugz/ancient/v5/xyz
Using the old URLs, implement a 301 redirection to your new v7 content. e.g. a request to abc.com/docs/fogzbugz/v5/GettingStarted.html is redirected to abc.com/docs/fogzbugz/v7/GettingStarted.html
In this way, existing links from external sites will take browsers to the latest documentation, and inform indexing robots that the page has moved.
Google will find the new links to your old documentation by indexing your site, but there will be no external links, thus reducing page rank.
Google will also find the new links to your new documentation, and as more sites link to it, its page rank will increase and so take priority.
This worked for me on a small scale (100 or so pages) site, and visitor attempts to view the old content rapidly dropped off.
If a user does land on a v5 page, how about the MSDN approach of explicitly stating the version that the page describes, and providing links to the equivalent topic in the v6 and v7 docs?
I would suggest that external links to older versions get redirected to the latest version - with some sort of note that if you really needed version 5 the link is here.
I think a lot of the problem deals with the fact that search engines give something a high rank if a lot of people are linking to a specific page. Unless you can get all the people linking to your old documentation, to link to your new documentation, then you are going to have a problem with the older documents being rated artificially high. In order to overcome this, you might need to change the way you handle documentation pages. One good way would be to always show the newest information on a particular topic, and then only by clicking on a link on the page, do you get to the older versions. Optimally, this would be the same page, with a different parameter, to state which version you want to get documentation for.
What about trying the MSDN approach? You assign a version tag to your pages. When this page is displayed, its version number is displayed as well. Users will be able to see immediately that this information is deprecated.
You may need to write some stubs for new version pages like "This problem has been resolved in the current version" so that the users don't have to think you didn't do anything in 5 years. Some writing work, some interlinking but it's doable for a limited number of problematic pages.