this is not issue, just review :)
Jimmi08 opened this issue · 11 comments
Hello,
excellent idea, I really like it.
I tested it, it works with default e107 setting, but not with SEF urls.
I run into similar problem before, so maybe you could be able to solve it.
I tested it on gallery plugin (just with your Wowhead example). If you use normal URLs and use gallery.php, it works (just on first page from menu, otherwise there is /gallery/ in path). The same if you use pretty URLs in URL configuration, your url will have path f.e: /gallery/gallery-1 and $currentpath is always index.php (e_PAGE is index.php too).
This variables could help (it's from answer to my issue about this on e107 github):
e_REQUEST_URI - absolute page URL (including GET query)
e_REQUEST_SELF - full URL (including http(s):// ) without GET query
Some suggestions:
- maybe you could add setting display code in header or footer. Maybe more fields/category (universal code/meta tags, javascript and css) and then you could use e107::js(header-inline) and e107::js(footer-inline) - not remember exact syntax - to out them in right place. Now it is displayed at the beginning of code, if it would be code that depends on jquery, it wouldn't be work now. With this plugin you could be able to easy overwrite some css, if you use e107:css. in e_header.php
- to be able add page with parameters (Get query). If my plugin has too many different pages, I want to add script just for some of them. Maybe stupid idea, but my first test with this plugin was to use /content/content.php?cat.list.1 and I got that I couldn't use it this way. (I read directions/readme only when something doesn't work :) )
I hope you understand, English is not my native language. Thank you
Yeah, the plugin (ShowOnPages) was actually written because an old v1 plugin, everypage, had an exploit in it. Instead of tracking down the original author I just wrote my own plugin that did exactly the same thing in a more fluid manner. That's where I stopped. v2 (of e107) came and I updated the code to work, and then I stopped.
There are a few other issues than what you've pointed out. One of your suggestions is actually one of my ideas on how to fix one of the issues. Currently the output is echoed, which isn't the desired usage on e_header.php.
My idea, and it looks like your idea as well, is to just have different fields for different types of code you want on pages. I'll have to research the footer thing. Like you said, it's better to include javascript calls in the footer (if anyone reading this doesn't know why, you should look it up. It will help your page load times).
As for the page issue on SEF URLs, I hadn't realized it was an issue since I don't personally use them (I don't really have a solid e107 page set up for it to matter, to be honest). I'll look into your solution, as you notice the plugin works by pulling the current URL and getting the page (whatever.php) and going by that. I'd need to testing by an external party to make sure things are working as intended when I jump into this adventure however.
Finally, the parameters idea is good, I'll keep it in mind. Out of curiosity, did the code display on the content plugin regardless of your location?
Hi, with page value: content.php the contentwas displayed on the content plugin (because $currentPage was always content.php)- on all pages of this plugin.
If you get this works, can you imagine possibility of this plugin? Now, if you insert script/css in any plugin in e_header.php, you get it includes in all pages. I noticed this with gallery plugin, they solved this already and move everything in gallery.php (there are good example how to use inline js and css).
I want google maps on contact page (not on all pages), only way I was able to do it was in theme.php and with new layout for contact.php (e_PAGE doesn't work in theme.php too, only available variable for different output is THEME_LAYOUT.
Did you see this? http://e107.sk/tutorials/3-solid-include-js-files/
See, my original thinking was that if you wanted custom code to display on, let's say content.php, you would want it to display on all iterations of content.php (content.php?id.1, etc etc). It never occurred to me that you could possibly only want it to display for one "article".
It's a great idea to allow for it to be more complex and I can see how it would be beneficial. What if I took it a step further and allowed for the "page" to go up the dir tree? Maybe more than one plugin uses manage.php, and you only want custom code to display on manage.php that is inside the gallery plugin (I don't know if that's a real page or not). It's currently an "issue" since it just looks for manage.php and spits out the custom code.
To go more in depth on this (I realized it was kind of vague after I reread it): currently you set 'manage.php' as the page. What if you could do the following:
plugins/gallery/manage.php and plugins/showonpages/manage.php, but they both displayed different code? Then if you do one for manage.php it displayed on all versions of manage.php, including the previous two and manage.php?id.16 would only display if that GET was set.
I don't have time to check out the page right now, but I'll take a look as soon as I can.
Your ideas are good, and the more you add the more I understand how to better make it happen. Keep it coming!
Some follow up on this, since I've been putting some small work into splitting off the code into sections so I can both call them correctly and so JS can possibly go in the footer:
The cheap way I was going to do it was just have any JavaScript put into one textarea, and any CSS put into a different textarea. The issue is, when you call something like a remote file (like the Wowhead Tooltip call), it places that text inside another script call.
So you were left with something like:
<script type="text/javascript">
//<![CDATA[
<script type="text/javascript" src="//static.wowhead.com/widgets/power.js"></script><script>var wowhead_tooltips = { "colorlinks": true, "iconizelinks": true, "renamelinks": true }</script>
//]]>
</script>
My solution is to split it up even more. There will be 3 tabs when you create a new Content Code: General, JavaScript, CSS. General will have the page(s) you want the codes to show up on, the description of the code, and the userclass that gets the code. The other two tab will contain similar things in nature: A textbox that you will be able to place URLs, or locations, of remote (or local) javascript or CSS files to include and a textarea for you to insert any code that you want included.
For this change, you'll have to reinstall the entire plugin. I'm not messing with the update script and hoping that it'll make all the changes that need to happen. I'm not saying it isn't possible, I'm just not going to devote the time it would take to research the best/most effect way to make it work.
Finally, I'll probably focus on this bit and get it settled before I move on to the more expanded page selection idea. One bear at a time!
I am sorry I don't let you know sooner, I was 20 hours without net before they fixed it! Bellow is my idea about using e107 to manage everything. Just 3 new fields (type, position and order). I have planned using something like this for theme plugin, so you really don't need to follow it.
My idea was to have 3 different controllers for this (to have different values for meta type in dropdown). Not Tabs (they are not fully working yet), but menu items.
It worked like miracle, just right it occured me to add field active...
I just don't know how to select pages, maybe some regex or %% way... but I saw it somewhere...
Now I am going to look at your changes, I wanted to write this before you influence me :)
values:
That actually gives me some really great ideas, and I think will make things a little easier for the end user to understand.
hi, it seems you did a lot of work. I will be back on Monday, just I hope you will get this message. First time I am answering on notification mail. thanks for great work. jm
Odoslané z iPhonu
Dňa 25. 11. 2015, o 15:33, Patrick Weaver notifications@github.com napísal:
That actually gives me some really great ideas, and I think will make things a little easier for the end user to understand.
—
Reply to this email directly or view it on GitHub.
Yeah, I need to do some more testing. It doesn't quite work as planned yet.
Alright, I need some testing on this. I ironed out the issues I saw. I tested inline and url JS calls, but that's it.
I don't have much time to test anything else, so if anyone reading this wants to test out -- feel free.
Test done, written new issue. Thank you for your work.
seems like this is going to be really nice to use, as i would like to create my marquee and add it to index.php.
I installed this one but have not figured out how to really use it as of yet...maybe add a few pics on how to use as the direction in the read me does not really explain. below is a image of my settings for a marquee which does not work maybe someone can let me know where i went wrong.
http://i874.photobucket.com/albums/ab306/worldwide7477/showonpage_zpstwdrfhkh.jpg